Many assume that nesting agents automatically simplifies access reviews, but the reality is far more nuanced.
In most on‑prem environments, engineers still rely on a handful of long‑lived service accounts or shared SSH keys. Those credentials are copied to multiple bastion hosts, then used directly to reach databases, Kubernetes clusters, or internal web services. The result is a web of implicit trust: a single credential can open a chain of connections, and no central point records which user actually initiated the request. When an incident occurs, the audit trail ends at the first hop, leaving security teams to guess which downstream system was accessed and by whom.
Organizations often try to improve the situation by introducing non‑human identities, service accounts scoped to a specific role, or federated identities that map to minimal permissions. These steps reduce the blast radius of any single credential, but they do not change the fundamental flow. In short, the setup creates a better “who can call” boundary but leaves the “what actually happened” question unanswered.
Why nested agents complicate access reviews
A nested agent architecture means that an initial agent authenticates to a gateway, then spawns a second‑level agent that talks to the final target. The second agent often inherits the first agent’s identity, or it may be granted a separate service account. From the perspective of an access‑reviewer, the call stack looks like a black box: a user authenticates, an agent does something, and somewhere downstream a privileged command executes.
Access reviews rely on clear evidence of who accessed which resource, when, and for what purpose. Nested agents obscure that evidence in three ways:
- They introduce an extra hop that is not always logged by the target system.
- Credentials used by the inner agent may be static, making it impossible to distinguish between different callers.
- Approval workflows, if any, are often implemented inside the inner agent’s code, meaning the outer layer cannot enforce or record them.
Because of these gaps, reviewers either over‑grant permissions to compensate for missing visibility, or they spend disproportionate time reconstructing logs from multiple sources. Both outcomes defeat the purpose of a rigorous access‑review process.
The missing enforcement layer
The only reliable way to close the visibility gap is to place a control point on the actual data path, a gateway that every request must traverse, regardless of how many agents are chained together. That gateway can observe the protocol, enforce policies, and produce immutable audit records that tie the outer user to the inner agent and finally to the target resource.
Setup: identity and provisioning
Identity providers such as Okta, Azure AD, or Google Workspace issue short‑lived OIDC tokens. Those tokens are mapped to roles that define which resources a user may request. Provisioning tools create service accounts with the minimum privileges needed for a given job. This setup decides who may start a request, but it does not enforce what the request can do once it reaches the resource.
The data path: where enforcement must happen
hoop.dev sits in the data path, acting as an identity‑aware proxy for every supported target, databases, Kubernetes clusters, SSH hosts, and internal HTTP services. By proxying the connection, hoop.dev can inspect each command, mask sensitive fields in responses, and require just‑in‑time approvals before a dangerous operation proceeds.