Autonomous agents can request just-in-time access to a database exactly when they need it, and the request is granted, recorded, and revoked automatically. The result is a system where no long‑lived credential ever sits idle, every operation is visible to auditors, and sensitive fields are hidden from the agent unless explicitly allowed.
In many organizations, agents are given a service‑account key that never expires. The key is copied into CI pipelines, stored in vaults, and often shared across multiple jobs. Because the credential never changes, any compromise gives an attacker unrestricted, perpetual access to every downstream system the agent can reach. Auditors cannot tell which job actually issued a query, and developers cannot enforce data‑level protection without building custom code into each application.
Switching to Entra as the source of identity solves the first part of the problem. Entra issues a short‑lived OIDC token that proves who the agent is and what groups it belongs to. The token can be scoped to a specific role and revoked centrally. However, the token alone does not stop the agent from connecting directly to the target resource. The request still travels straight to the database, SSH server, or Kubernetes API without any intermediate check, meaning there is still no real‑time approval, no command‑level audit, and no data masking.
Why a data‑path gateway is required for just-in-time access
The missing piece is a place where policy can be enforced before the request reaches the target. The gateway sits on the network, intercepts the protocol, and decides whether to allow, block, or transform each operation. Because the gateway is the only point that sees both the Entra identity and the actual traffic, it can apply fine‑grained controls that no upstream identity provider can enforce.
In this architecture, the setup stage, creating Entra applications, issuing short‑lived tokens, and assigning groups, determines who the request is and whether it may start. That step is necessary, but it does not provide any protection on its own. The enforcement must happen in the data path, and that is where hoop.dev operates.
Implementing just-in-time access with Entra
hoop.dev acts as an identity‑aware proxy for the supported targets. When an autonomous agent initiates a connection, hoop.dev first validates the Entra token, extracts the group membership, and maps it to a policy that defines what actions are allowed. The gateway then keeps the credential needed to talk to the backend resource, so the agent never handles a password or private key.
Once the request is authorized, hoop.dev grants access for the duration of the session only. If a command matches a risky pattern, such as a destructive SQL statement or a privileged kubectl operation, hoop.dev blocks it in real time. For queries that return sensitive columns, hoop.dev masks those fields before they are sent back to the agent. hoop.dev records every command, response, and approval decision in an audit log that can be replayed for forensic analysis.