An on‑prem team hands a newly hired contractor a service account that runs a CI job, creating a scenario where least privilege is quickly eroded. The job spawns a helper process that talks to a database through an internal SSH tunnel. The contractor’s token is stored in a shared file, and the tunnel remains open long after the job finishes. When the contractor leaves, the credentials stay on the host, the tunnel can be reused by anyone with shell access, and no one knows which commands actually reached the database.
This is the typical unsanitized state. Teams often rely on static service accounts, long‑lived SSH keys, or blanket network routes to let one process invoke another. The result is broad, standing access that bypasses any runtime check. Auditors cannot tell who issued a SELECT, who altered a table, or whether a secret was exposed, because the connection travels directly from the helper to the target without a control point.
Why nested agents break least privilege
Even when an organization adopts modern identity providers, the fix is usually limited to the setup phase. Engineers provision OIDC tokens for the CI job, assign the token to a service account, and configure the helper to use that token. The token proves who started the request, but the request still reaches the database or Kubernetes API directly. No gateway inspects the payload, no policy can block a dangerous command, and no session is recorded. The setup therefore does not enforce least privilege at runtime; it merely authenticates the caller.
Nested agents amplify the problem. One agent (the CI runner) launches a second agent (the SSH tunnel) that then talks to the target. Permissions are often granted to the first agent, and the second inherits them implicitly. Because the second agent runs inside the same trust zone, it can act with the full privileges of the first, even if the original request only needed read‑only access. Without a control point between the two, the chain of trust cannot be broken, and the principle of least privilege evaporates.
How hoop.dev restores control
Placing a Layer 7 gateway in the data path solves the missing enforcement layer. hoop.dev sits between the nested agents and the protected resource. Because all traffic must pass through the gateway, hoop.dev can apply just‑in‑time approvals, mask sensitive fields in responses, and block commands that exceed the granted scope. It records every session, so auditors can replay the exact sequence of queries that were executed.