Relying on static service credentials for nested agents invites undetectable breaches, especially when non-human identity is treated as a shared secret.
Why non-human identity is fragile for nested agents
Many teams treat a service account as a shared password. The same token is baked into CI pipelines, copied into scripts, and handed to third‑party bots. When a nested agent, an automation that calls another automation, uses that credential, the chain of trust becomes opaque. If the credential leaks, an attacker can move laterally without ever touching a human login, and no alert fires because the system never knows which automation performed the request.
In practice, the initial state looks like this: a GitHub Action runs a build, which triggers a deployment script that invokes a Kubernetes job, which in turn launches a data‑processing container. All steps use the same service account key stored in a repository secret. No audit trail exists for the inner job, no command‑level visibility, and no way to mask sensitive fields that the job may return.
What a proper non-human identity setup fixes – and what it still leaves open
Moving to a model where each automation receives its own OIDC token or short‑lived service account improves provenance. The outer CI pipeline authenticates to the identity provider, receives a token, and passes it to the nested job. The token is scoped to the exact resources the job needs, and it expires after a few minutes.
This change solves two immediate problems: it eliminates long‑lived static secrets, and it gives the identity provider a clear record of which principal requested access. However, the request still travels directly to the target system. The gateway that carries the traffic sees only an authenticated connection; it does not enforce command‑level policies, mask data, or record the session. In other words, the setup establishes who may start the request, but it does not control what the request does once it reaches the backend.
Why the data‑path gateway is essential for enforcement
The only place to enforce fine‑grained policies is on the data path itself. A gateway positioned between the non-human identity and the target resource can inspect each protocol message, apply just‑in‑time approvals, block dangerous commands, and mask sensitive response fields. Without such a gateway, every enforcement outcome, audit logs, inline masking, JIT approval, session recording, must be built into the target service or the automation code, which is brittle and easy to bypass.
This is where hoop.dev comes in. hoop.dev acts as a Layer 7 identity‑aware proxy that sits in the data path for every nested‑agent connection. It receives the OIDC token issued by the identity provider, validates the token, and then forwards the request to the target system only after applying the configured guardrails.