Zero Standing Trust
You set up zero standing trust by removing all default, always-on user permissions. You then grant temporary roles only when an engineer needs to fix an issue. Most teams start with static groups in their cloud provider or database. They assign broad admin roles so on-call staff can move fast during an outage. Over time, these permanent roles pile up across dozens of accounts. An attacker who steals one laptop key gains full control over production data. Removing standing permissions shrinks th
Zero Trust Architecture + Zero Standing Privileges: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up zero standing trust by removing all default, always-on user permissions. You then grant temporary roles only when an engineer needs to fix an issue.
Most teams start with static groups in their cloud provider or database. They assign broad admin roles so on-call staff can move fast during an outage. Over time, these permanent roles pile up across dozens of accounts. An attacker who steals one laptop key gains full control over production data. Removing standing permissions shrinks that risk window down to zero during normal hours.
How a zero standing trust workflow operates
A native zero standing trust setup relies on empty default groups and temporary role assumption. In this model, your identity provider holds user profiles, but those profiles lack production permissions. When an engineer logs in on a normal morning, they cannot read or write production data.
To perform work, the engineer submits a request for a specific task role. A manager or an on-call schedule check approves this request for a set window, like one hour. Once approved, the cloud platform or directory assigns the user to that role. When the timer runs out, the system strips the role from the user profile.
You also apply this pattern to database roles and server groups. Instead of keeping permanent keys on engineer laptops, you tie permissions to temporary cloud roles. The engineer assumes the role, runs their commands, and loses the role when the window closes. No permissions remain active overnight or over the weekend.
What native role limits solve and what they miss
Time-bound roles solve the problem of forgotten accounts and idle admin keys. If an engineer leaves the team or loses a device, no permanent production permissions exist to exploit. Audit logs also show who asked for a role and who approved it.
Zero Trust Architecture + Zero Standing Privileges: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Still, native cloud and database roles only check who logs in at the start. Once the one-hour window begins, the engineer holds full power inside that role. Native role assignment cannot inspect individual SQL statements or shell commands while they run.
If a role allows database reads, the user can dump a million rows of customer emails. If a role allows writes, one bad command can drop a critical table. Temporary roles also fail to mask sensitive fields like card numbers or phone numbers in query results. To close this gap, teams must check and filter every command in flight, not just the initial login.
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 sits inline in the protocol beside each supported service as an open-source proxy, a sidecar for your database or API. For every query or command an AI agent or engineer runs against production, hoop.dev decides to pass, mask, block, or hold it for human approval.
First, hoop.dev guardrails block banned queries before they run or hold risky ones for review, and hoop.dev data masking rewrites matched sensitive values in responses in memory. Furthermore, hoop.dev holds SOC 2 Type II and is open source on GitHub.
Frequently asked questions
How is zero standing trust different from least privilege?
Least privilege reduces the permissions a user holds all day. Zero standing trust removes all baseline permissions and grants them only for brief, approved windows.
Does removing standing permissions slow down on-call fixes?
It does not slow down fixes if you link approvals to your on-call schedule. Active on-call staff can get automatic approval for read roles while risky writes require a peer check.
Why do temporary roles still need query-level controls?
A temporary role still gives full permissions while the timer is active. Query controls block destructive commands and rewrite sensitive fields like national IDs in results during that active session.
Teams that document these role rules and review logs each month catch config drift early. Clear ownership for each role keeps live systems simple to run and easy to audit across the whole team.