Count the standing grants in your environment that exist only because someone needed them once. Now add an AI agent that needs to reach production twice a week for a migration check. The cheap answer is a permanent grant. The expensive answer arrives later, when that permanent grant is the path an attacker or a confused agent uses, and you are paying for it in incident response.
Just-in-time access flips the default. Access does not exist until it is requested, and it disappears when the work is done. This guide configures just-in-time access for an AI agent whose identity is issued by Microsoft Entra, with the actual grant enforced by hoop.dev on the infrastructure connection. Entra is the identity provider here. hoop.dev is the relying party that reads the Entra token and group membership, then grants a time-boxed connection to a database or service. hoop.dev never fronts Entra itself.
Why standing access fails for agents
An AI agent does not get tired, and it does not stop trying. A standing grant attached to an agent is a permanent door. If the agent is prompted into something unexpected, standing access means the blast radius is everything that grant could ever reach. Just-in-time access shrinks that to the minutes the agent actually needed, governed by the Entra identity it presented.
A worked example of just-in-time access
Say the agent must run a schema diff against a production Postgres replica every Tuesday. You do not want it holding that access the other six days.
- In Entra, create a group called
jit-schema-checks and assign the agent's app identity to it. - In hoop.dev, configure Entra as the OIDC provider so the gateway verifies tokens against your tenant.
- Define the connection to the replica with the database credential stored on the connection, not on the agent.
- Attach a just-in-time policy: members of
jit-schema-checks may request access, each grant lasts 30 minutes, and the session is recorded.
policy: jit-schema-checks
connection: prod-replica
grant: on-request
ttl: 30m
record: true
When the agent connects, hoop.dev checks the Entra group, opens a 30 minute window, proxies the queries, and closes the window. The next Tuesday the same cycle runs from zero standing access.
Verify expiry actually happens
Let a grant open, then watch it close. After the TTL, the agent's next query should be refused at the gateway, and the session record should show the window opening and closing tied to the Entra identity. One model leaves access on until someone remembers to remove it. The other ends access on a timer the agent cannot extend. That difference is the whole point.
Pitfalls
- Do not set the TTL so long that just-in-time becomes standing access with extra steps. Match it to the task.
- Do not auto-approve every request silently if the target is sensitive. Pair short TTLs with a review step where it matters.
- Do not give the agent a static database credential as a backup path. That defeats the time box.
Pair short grants with the right Entra group design
The quality of just-in-time access depends on how you cut your Entra groups. One enormous group that every agent belongs to forces every grant to be wide, because the policy cannot tell a reporting agent from a maintenance agent. Cut the groups by task instead. An agent that only diffs schemas belongs in a group that maps to a read-only replica connection, and nothing else. Then a 30 minute grant means 30 minutes of exactly that, not 30 minutes of broad reach.
This also keeps the audit clean. When each grant is bound to a task-specific Entra group, the session record reads as a clear story: this identity, this connection, this window, these queries. You can answer the question of what an agent could do at any moment by looking at one group and one policy, instead of reasoning about a tangle of overlapping grants.
hoop.dev is open source, so the grant logic and expiry are auditable in the codebase rather than asserted in a datasheet. Read the getting started guide for connections and policies and the learn material on just-in-time access to map this to your own targets.
FAQ
Is the agent's access controlled inside Entra?
Entra controls the identity and group membership. The time-boxed grant to infrastructure is enforced by hoop.dev based on that identity.
What happens when the window expires?
The connection is refused at the gateway and the agent must request again. No leftover standing access remains.
Where do I get the gateway?
From the hoop.dev repository on GitHub, where you can run it yourself and inspect how just-in-time access is enforced.
