Run Time Authorization
You set up run time authorization by checking user rules during every live request. This step confirms permissions right when a command or query tries to run. Most engineering teams start by assigning static roles in their cloud or database. They attach broad read or write policies to groups of developers for daily work. When those roles stay too wide, one bad command can drop production tables. Broad permissions also allow anyone on the team to read sensitive customer data. How to set up nati
Just-in-Time Access + Dynamic Authorization: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up run time authorization by checking user rules during every live request. This step confirms permissions right when a command or query tries to run. Most engineering teams start by assigning static roles in their cloud or database. They attach broad read or write policies to groups of developers for daily work. When those roles stay too wide, one bad command can drop production tables. Broad permissions also allow anyone on the team to read sensitive customer data.
How to set up native run time authorization
A native setup relies on identity providers, database roles, and app level rule engines. First, a developer or service logs in through the central identity system. The identity system checks the user group and issues a signed token. That token holds claims about who the user is and what roles they hold.
Next, the user sends a request to a backend service or database host. The host reads the token and looks up the matching role permissions. In a database, the engine checks if the role can read the table. In an internal app, a rule engine evaluates the user attributes against local policies. The system checks the time of day, the user group, and the target resource. If the rule matches, the host runs the request and returns the result. If the rule fails, the host blocks the action and writes an error log. Teams manage these rules by updating policy files or role bindings in source control.
What native role checks solve and what they miss
Native role checks solve the basic problem of who can log into a host. They stop unknown users from reaching internal databases, servers, or cloud admin consoles. They also help teams group users by job title, such as analyst or engineer. This setup works well for simple apps with stable, predictable access patterns.
Still, native role checks leave a major operational gap during live sessions. Most native tools only check permissions when the session starts or at table level. Once an engineer logs into a database, the role stays active for hours. The native setup cannot tell a safe query from a destructive one in flight. If a role allows updates, the user can update one row or every row by default. Native roles also struggle with sensitive fields inside shared tables. When a query runs, the database returns full emails, phone numbers, and card numbers. To fix this natively, teams must build and maintain complex custom views per role. Over time, role sprawl grows and admins grant wide access just to unblock work.
Just-in-Time Access + Dynamic Authorization: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Evaluating commands and data in flight
True control requires checking every single statement, command, and data payload at the moment it runs. Instead of trusting a broad session role, teams need rules on the action itself. For example, a developer might need to read a user table to fix a bug. They do not need to see raw national IDs or card numbers in the output. Rewriting those matched fields in query results keeps data safe during daily debugging. In the same way, a risky delete command should pause for a peer review. Checking the exact command text in flight stops bad changes before they hit disk.
Check database and API queries on the wire
Identity tools, roles, and network rules decide who opens a session. Setup alone cannot check what each query does or mask sensitive values in a response once a session starts. When workflows touch Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, or internal HTTP APIs, hoop.dev sits inline in the wire protocol beside those services as an open-source proxy, a sidecar for your Postgres or API. On every query an AI agent or engineer runs against production, hoop.dev decides to pass, mask, block, or hold it for human review.
Your login details and client tools stay as they are while hoop.dev guardrails refuse bad deletes or drops before they run, and hoop.dev data masking rewrites matched sensitive values in responses in memory. Furthermore, hoop.dev holds SOC 2 Type II, is MIT licensed, and writes every query and decision to an audit trail that generates evidence for HIPAA, GDPR, and PCI DSS. See the source on GitHub.
Frequently asked questions
How is run time authorization different from login checks?
Login checks only verify who you are when you first start a session. Run time authorization checks your permissions on every single command or query you send.
Why do static database roles fail to stop bad queries?
Static roles grant permissions to whole tables or schemas for the entire session. They do not inspect the actual filter or row count of a live query.
How does data masking work during a live query?
Masking rules inspect the query output before it reaches the user screen. The system rewrites matched fields like emails and phone numbers in the results.