Define the overlap plainly: agent impersonation turns one agent's blast radius into the access of whatever identity it can present itself as. If that identity is privileged, the blast radius is the privileged identity's reach. Containing it is a defensive, server-side problem, and the boundary is the connection.
Blast radius is how much one action or one compromised actor can affect before something stops it. For an agent, that radius is set by the access behind its connections. Impersonation matters because it changes which access applies: not the agent's own intended scope, but the scope of the identity it acts under. So the defense is to make sure an agent can only ever act under the identity it genuinely authenticated as, with that identity's access tightly bounded.
Where the overlap bites
If an agent asserts its own identity, or holds a credential it can pass along, then a confused or steered agent can exercise a broader identity than its task warrants. The radius is no longer what this task needs but what the borrowed identity can do. That is the worst version of blast radius, because it is invisible until something acts far outside its lane.
Consider how this differs from ordinary over-provisioning. An over-provisioned agent has a radius set by its own grant: too big, but at least known and reviewable. An agent that can impersonate has a radius set by the most privileged identity it can present as, which is neither known in advance nor visible in the agent's own configuration. You can audit the first by reading the grant. You cannot audit the second the same way, because the dangerous reach is not written down anywhere near the agent. It lives in whatever identity the agent can borrow.
That is why impersonation deserves separate attention from scoping. Tightening the agent's own grant does nothing about a radius that comes from a borrowed identity. The two are different failure modes and they need different controls: scoping for the agent's own access, and identity binding so the agent cannot reach for anyone else's.
Practical containment
- Bind the agent to a verified identity at the connection. If it can only act as the identity it authenticated as, it cannot inherit a larger one.
- Keep credentials out of the agent. An agent that never holds the target credential has nothing to lend and nothing to leak that widens its reach.
- Scope and time-bound access. A narrow, expiring grant means even the identity in use has a small radius and only while the task runs.
- Gate dangerous operations for approval. High-impact commands pause for a human, so the worst actions do not execute on a self-asserted identity.
One boundary that holds the radius
The reason to contain this at the connection is that you cannot trust the agent to limit its own identity or scope. The control has to sit where the agent cannot reconfigure it. hoop.dev is an identity-aware proxy on that boundary. The agent authenticates through your OIDC or SAML provider, hoop.dev verifies the identity and opens the connection under a controlled credential the agent never holds, scopes access just in time, and routes risky commands for approval.
So the blast radius of an agent connected through hoop.dev is the narrow, time-bound access of its verified identity, gated at the dangerous edges, rather than whatever credential it could present. One model lets an agent borrow an identity. The other binds it to the one it proved. See how identity-bound, scoped access is set up and the broader argument in hoop.dev's runtime governance writing.
FAQ
How does agent impersonation change blast radius?
It makes the radius equal to the access of whichever identity the agent can act under, not the agent's intended scope. Borrowing a privileged identity expands the radius dramatically.
What contains it?
Binding the agent to a verified identity at the connection, keeping credentials out of the agent, scoping access just in time, and gating dangerous commands for approval.
Does hoop.dev inspect the agent's reasoning to contain blast radius?
No. It governs the infrastructure connection: identity, scope, approval, and recording. It does not read the model's prompt or output.
The gateway is open source. Read and deploy it from the hoop.dev repository on GitHub to bound what your agents can reach.
