A CI pipeline spawns a short‑lived container that runs a build script. Inside that container an automation bot launches a second process, a nested agent, that needs to pull secrets from a database to complete its job. The bot inherits a static credential that was baked into the image months ago. When the nested agent connects, it does so with the same long‑lived token, and no one can tell which build actually touched the data. Without just-in-time access, that credential remains valid forever, exposing the database to any compromised build.
Current practice leaves nested agents over‑privileged
Most teams treat a nested agent like any other service account: they grant it a permanent secret and allow it to talk directly to the target system. The secret lives in the image, in environment variables, or in a shared vault entry that never expires. Because the connection bypasses any gate, the agent can read, write, or delete data at any time. Auditors see only the static credential, not the individual executions. If a breach occurs, there is no replayable record of which build triggered the offending query.
Why just-in-time access matters for nested agents
Just-in-time access promises that a credential is minted only for the duration of a specific request. Applied to nested agents, it would mean the outer CI job requests a short‑lived token, the inner agent receives a token that expires after the build step finishes, and any deviation from the approved workflow is blocked. The requirement, however, is only half the story: even with a just-in-time token, the request still travels straight to the database, bypassing any point where the request can be inspected, approved, or recorded. Without a data‑path enforcement layer, the system cannot enforce masking of sensitive columns, cannot require a human to approve a destructive command, and cannot capture a session for later review.
hoop.dev as the data‑path gateway for nested agents
hoop.dev provides the missing data‑path. First, the identity layer (OIDC or SAML) authenticates the CI job and any nested agent that presents a token. This setup decides who is allowed to start a request, but it does not enforce what the request can do. The gateway then sits between the agent and the target database, inspecting every wire‑level message.
hoop.dev records each session, so a replayable audit trail exists for every nested‑agent invocation. It masks sensitive fields in query results, ensuring that even a compromised agent never sees raw credit‑card numbers or personal identifiers. When a command matches a policy that requires human review – for example, a DROP TABLE or a bulk delete – hoop.dev pauses the request and routes it to an approval workflow before allowing execution. If a command violates a deny list, hoop.dev blocks it outright. All of these enforcement outcomes happen because hoop.dev occupies the data path; without it, the just-in-time token would be the only control.