Here is the tension. Least privilege is about giving an identity exactly the access it needs and no more. Agent impersonation is about an actor presenting itself as an identity it is not. Put them together and the contradiction is sharp: you can scope an identity perfectly, and it does not matter if something else can act as that identity. Least privilege depends on the grant reaching only its rightful holder, and impersonation breaks exactly that.
This is defensive, server-side framing. The point is where to enforce identity so that careful scoping actually protects you, not how impersonation is performed.
Why scoping alone is not enough
Suppose you do everything right on the scope side. The agent's identity is granted access to one schema, read-only, nothing else. Textbook least privilege. Now suppose the agent's identity is self-asserted, or carried in a credential the agent holds and could pass along. Anything that can act as that agent gets that read-only schema access. The scope held. The identity did not. Your least privilege protected the wrong boundary.
So least privilege for agents is two requirements, not one. The grant must be narrow, and the identity holding the grant must be enforced, not declared.
This is easy to miss because the two requirements feel like one. We are used to thinking of a privilege and the identity that holds it as a single object: the grant is the identity's grant, full stop. With humans that bundling is mostly safe, because a person authenticates with something hard to hand off and does not casually lend their session to another process. With an agent the bundle comes apart. The privilege is real and narrow, but the identity is a claim the software makes, and claims can be copied, replayed, or driven by something other than the intended agent.
Once you see them as two separate things, the design follows. You harden the grant the usual way, with scope and expiry. You harden the identity by making the connection, not the agent, decide who is connecting. Skip either and least privilege has a hole: a perfect grant on a forgeable identity, or a verified identity on an over-broad grant.
Closing the gap
- Authenticate the agent's identity at the connection through your identity provider. The identity is verified there, not asserted.
- Keep the target credential out of the agent, so there is no token to lend and no identity to borrow.
- Scope the access to exactly the resources the task needs, so the verified identity still holds only what it should.
- Time-bound the grant, so even the right identity has access only while the task runs.
The first two close the impersonation gap. The last two are least privilege in the usual sense. Both have to hold at once.
Enforcing identity and scope together
The reason this belongs on the connection is that the same boundary has to prove the identity and apply the scope, or the two can drift apart. hoop.dev is an identity-aware proxy that does both in one place. The agent authenticates through your OIDC or SAML provider, hoop.dev verifies the identity and opens the infrastructure connection under a controlled credential the agent never handles, and it grants just-in-time access scoped to the resource.
So least privilege for an agent connected through hoop.dev means a verified identity holding a narrow, expiring grant, with no credential in the agent to impersonate around. The grant reaches its rightful holder because the boundary, not the agent, decides who that is. See how identity-bound, scoped access is configured and the wider model in hoop.dev's runtime governance writing.
FAQ
Why does impersonation undermine least privilege?
Least privilege scopes an identity's access. If another actor can present itself as that identity, it inherits the scoped access, so the careful scoping protects the wrong actor.
What does least privilege require for an agent specifically?
Two things at once: a narrow, time-bound grant, and an identity that is authenticated at the connection rather than asserted by the agent.
Does keeping credentials out of the agent matter for least privilege?
Yes. If the agent never holds the target credential, there is nothing to pass to another process, so the scoped identity cannot be borrowed.
The gateway is open source. Read and run it from the hoop.dev repository on GitHub to bind identity and scope on the connections your agents use.
