Just-in-time Permissions
You set up just in time permissions by binding temporary roles to user requests. A timer removes those rights once the task is done. Most teams start by granting permanent admin roles to speed up daily work. Over time, these broad roles accumulate across databases, servers, and cloud accounts. If an attacker steals one permanent key, they gain full control right away. How to set up just in time permissions A temporary permission workflow relies on your identity provider and cloud role engine.
Just-in-Time Access + AI Agent Permissions: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up just in time permissions by binding temporary roles to user requests. A timer removes those rights once the task is done. Most teams start by granting permanent admin roles to speed up daily work. Over time, these broad roles accumulate across databases, servers, and cloud accounts. If an attacker steals one permanent key, they gain full control right away.
How to set up just in time permissions
A temporary permission workflow relies on your identity provider and cloud role engine. First, you remove standing admin rights from daily user accounts. Users keep only baseline read rights for non-sensitive resources. When an engineer needs to fix a production issue, they submit a request. That request states the target system, the role needed, and a time limit.
Next, a manager or an on-call peer reviews the request in chat. Once approved, the identity system updates the user group membership or role binding. The target database or cloud account sees this update and grants the role. A background job tracks the clock for that specific grant. When the timer runs out, the system revokes the role binding. The engineer returns to baseline zero-privilege status without manual clean up.
Where temporary role grants fall short
Temporary role workflows solve the problem of permanent standing privileges across your team. They shrink the window where an account holds high-level rights. They also create an approval log showing who asked for a role and why.
Still, role grants only control who logs in during a set time window. Once the role is active, the database or server trusts every command sent. A five-minute admin role still lets a user drop a production table. It also lets them run a bulk export of customer emails and card numbers. Role timers cannot inspect individual SQL statements or shell commands in flight. Also, revoking a group role does not always kill open database sessions. An active session can keeps the session active long after the role timer ends.
Just-in-Time Access + AI Agent Permissions: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Adding command-level controls to temporary grants
To close this gap, teams pair temporary role grants with command-level checks. Instead of granting a broad admin role, you scope approvals to single actions. An engineer can run standard read queries while sensitive fields get rewritten. Masking rewrites matched emails, phone numbers, and national IDs in query results. If the engineer needs to run an update statement, that single statement awaits approval. This shifts control from who holds a role to what each command does.
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 runs beside those services as an open-source proxy, a sidecar for your Postgres or API. It inspects requests coming in and results going back on the wire.
Your login details and client tools stay as they are while hoop.dev guardrails refuse bad deletes or drops before they run. On responses, hoop.dev data masking rewrites matched sensitive values 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 do just in time permissions differ from standing roles?
Standing roles stay attached to a user account day and night. Temporary permissions attach to an account only after approval and expire on a timer.
Do temporary role grants stop bad queries during an active session?
No, native cloud and database roles only check identity when the session starts. While the role is active, the user can run any command that role allows.
What happens to open sessions when a role timer ends?
Many databases check role rights only at login or token refresh. Unless your tooling terminates the session, an open connection can keep running commands.