Project-based Licensing
You set up project based licensing by tying user seats and compute quotas to one workspace. This model bills and grants rights per project instead of across the whole company. Many teams start by linking their identity provider groups to specific project folders. Still, if those project roles are too broad, users gain wide rights across all databases. A single mistake or bad query can then expose data across the entire project. How project based licensing works in practice In a standard enter
Temporary Project-Based Access: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up project based licensing by tying user seats and compute quotas to one workspace. This model bills and grants rights per project instead of across the whole company. Many teams start by linking their identity provider groups to specific project folders. Still, if those project roles are too broad, users gain wide rights across all databases. A single mistake or bad query can then expose data across the entire project.
How project based licensing works in practice
In a standard enterprise setup, an admin buys a big pool of user seats. Every developer gets a seat and can see almost every resource in the account. Project based licensing changes this boundary by making the project the main unit of control. Each project gets its own license tier, usage limits, and list of approved team members.
To set this up, admins first create a dedicated workspace for a specific product or client. Next, they attach a billing plan and feature tier to that single workspace. Then, they map identity groups to local roles inside the project boundary. A developer on Project A gets a writer role there, but zero rights on Project B.
When a user logs in, the platform checks their group tag against the project roster. If the user belongs to the project, the system activates their seat for that workspace. The platform also tracks compute, storage, and API calls against the project budget. When the project ends, admins shut down the workspace and stop the license cost right away.
Why project boundaries do not stop risky commands
This licensing model solves two big problems for growing engineering teams. First, it makes cost tracking simple because every bill maps to one clear deliverable. Second, it limits the blast radius if an outsider steals a developer key. The attacker can only reach the project tied to that key, not the whole company.
Yet a major security gap remains inside the project boundary itself. Project roles decide who can log in, not what their commands do during a session. Once a developer enters the project database, a standard role lets them run any read query. They can pull full tables of customer emails, phone numbers, or card numbers without warning.
Temporary Project-Based Access: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Native project roles also lack fine controls for high-risk actions in live databases. A contributor who needs to fix one row often holds rights to drop the whole table. Also, shared project service keys make audit logs hard to read during an incident. You can see that the project key ran a bad command, but not which person sent it.
Closing the gap with command-level checks
To keep project workspaces safe, teams must pair license boundaries with live session controls. Start by splitting broad project roles into smaller tasks based on daily work. Most developers only need read rights for daily checks, not full admin rights all day.
Next, add a step where peers approve risky write commands before they run. When someone needs to update a production record, another engineer can check the exact statement first. Finally, apply data masking to rewrite sensitive fields like national IDs and card numbers in query results. This keeps raw data safe while letting the project team build and test features at full speed.
Govern statements and responses across databases and APIs
Good config and scoped roles are needed setup. They do not check single queries in flight or mask sensitive fields in returned rows. Across Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, and internal HTTP endpoints, hoop.dev runs beside each supported service as an open-source proxy, a sidecar for your database or API.
First, hoop.dev guardrails block banned queries before they run. Then hoop.dev data masking rewrites matched sensitive values in responses in memory. The audit trail records every statement and verdict per resource. Furthermore, hoop.dev holds SOC 2 Type II and is open source on GitHub.
Frequently asked questions
What is the main benefit of project based licensing?
It aligns software costs and user rights with specific business goals or client work. Teams only pay for the exact seats and tools needed for an active project.
How does project licensing affect database security?
It isolates data so users on one project cannot reach databases in another project. Still, teams still need runtime checks to control what approved users do inside their own project.
How should we handle contractors in a project license model?
Assign contractors to a single project group with an expiration date on their identity profile. Pair their role with data masking so query results rewrite emails and phone numbers during their work.