Just in Time Administration
You set up just in time administration by giving engineers short-lived admin roles only when needed. When the work finishes, the system revokes those elevated permissions right away. Many teams start by giving every developer a permanent admin role to fix production bugs fast. Over time, these broad standing permissions create a massive risk if an attacker steals a key. Removing permanent roles and moving to on-demand elevation shrinks that attack surface. How just in time administration works
Just-in-Time Access + Identity Governance & Administration (IGA): the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up just in time administration by giving engineers short-lived admin roles only when needed. When the work finishes, the system revokes those elevated permissions right away. Many teams start by giving every developer a permanent admin role to fix production bugs fast. Over time, these broad standing permissions create a massive risk if an attacker steals a key. Removing permanent roles and moving to on-demand elevation shrinks that attack surface.
How just in time administration works in practice
A working setup starts with your identity provider and your cloud or database roles. First, you remove all standing admin roles from daily user accounts. Next, you define eligible roles that users can request for a short window. When an engineer needs to fix a live system, they ask for the role.
This request goes to a team lead or an on-call manager in chat or email. The manager checks why the engineer needs the role and approves the request. Once approved, the identity system binds the admin role to the user for one hour. When the timer runs out, the system strips the role from the user account.
Teams also tie these requests to ticket numbers so auditors can track every approval. The identity provider writes a log showing who asked, who approved, and when it ended. This basic workflow replaces shared admin keys and static root accounts across your stack.
Why role elevation alone leaves a gap
Time-bound roles solve the problem of standing privileges sitting idle all day and night. An attacker who steals a basic user key cannot drop a production database right away. The audit log also tells you which engineer held the admin role during an incident.
Still, role elevation only controls who can log in during a time window. Once the engineer gets the admin role, they hold full power for that whole hour. The native cloud or database role does not check individual queries or commands in flight. An approved engineer can still run a bad delete query by mistake during their shift.
Just-in-Time Access + Identity Governance & Administration (IGA): architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
They can also read sensitive customer fields like emails, phone numbers, or card numbers. Standard role timers cannot rewrite those fields in query results or pause a single risky command. To stay safe during an active session, teams need controls that work at the command level.
How to scope down risk during active sessions
To make temporary admin work safer, break huge admin roles into smaller task roles. Create one role for reading tables and another role for changing table schemas. Keep the approval timer as short as possible, such as fifteen or thirty minutes. Require a fresh approval if the engineer needs to run a high-risk write command.
You should also mask sensitive data fields in query results whenever possible. When masking rewrites card numbers or national IDs in results, routine checks leak less data. Combining short role timers with tight command checks gives you control before and during the session.
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
What is the difference between standing privileges and just in time administration?
Standing privileges give users permanent admin roles twenty-four hours a day. Just in time administration grants those admin roles only for a short, approved time window.
How long should a temporary admin session last?
Most teams set the timer between fifteen minutes and one hour for routine fixes. Short timers make sure elevated permissions expire right after the engineer finishes the task.
Does temporary role elevation stop accidental data deletion?
No, because an elevated admin role still lets the user run any allowed command. Stopping a bad delete query requires checking individual statements before they run on the database.