Three agents, one Postgres login, one password in a shared secret. When an audit asks which agent ran the query that exfiltrated a customer table, the honest answer is that you cannot tell. The credential does not know which agent used it, and neither do you. That is the gap between a shared service account and a real non-human identity, and it is where most agent deployments quietly sit today.
Both models let an agent reach infrastructure. The difference is whether the system can attribute, scope, and revoke per agent, or only per credential. This is a decision worth making deliberately, because the cheap option works right up until the moment you need it not to.
What a shared service account gives you
A shared service account is one set of credentials that several workloads use. It is fast to stand up, it is easy to reason about, and for a single-purpose batch job it is genuinely fine. One job, one account, one clear owner.
The model breaks the moment more than one actor shares it. Attribution collapses into the account, not the agent. Rotation means coordinating every consumer at once, so it rarely happens. And the account accretes permissions over time, because it is easier to widen the shared scope than to argue about which consumer actually needs what. The result is a high-privilege credential nobody can safely change and nobody can fully account for.
What a non-human identity gives you
A non-human identity is a distinct identity for each agent or workload, with its own scope and its own lifecycle. It is the same idea you already apply to humans: one principal, one set of permissions, one audit trail. Applied to agents, it means each one carries its own identity into every request, so you can scope it narrowly, attribute its actions precisely, and revoke it without touching anything else.
The cost is that an identity is only useful if something enforces it at the point of access. An identity that exists in a directory but is not checked on the connection is documentation, not a control. This is the part that decides whether the model actually reduces risk.
A decision rule
Use a shared service account when exactly one workload uses the credential, its scope is tight, and you accept that attribution stops at the account. That is a defensible choice for a narrow, single-owner job.
Move to non-human identity the moment any of these is true: more than one agent shares the credential, the data behind it is sensitive or regulated, you need to answer "which agent did this" after the fact, or you need to cut off one agent without breaking the others. For autonomous agents that act continuously and unpredictably, that threshold is crossed on day one. The shared account is enough for a script. It is never enough for a fleet of agents touching production.
Why the identity has to be enforced on the connection
Assigning each agent a non-human identity solves nothing if the agent still authenticates to the database with a shared password it holds in its environment. The identity has to be the thing that authorizes the connection, and that check has to run somewhere the agent cannot bypass. If the agent holds the target credential directly, it can use it however it likes, and your identity model is fiction.
The architectural requirement, then: the agent should never hold the target credential, and authorization should be evaluated per identity at the connection, outside the agent's reach.
hoop.dev is built to that requirement. It is an open-source Layer 7 access gateway sitting between identities and infrastructure. Each agent authenticates to the gateway as its own principal, through your OIDC or SAML provider, and the gateway, not the agent, holds the credential configured on the target connection. The agent never sees the database password. Every query is attributed to the agent's identity, authorization is evaluated per identity before the command reaches the target, and revoking one agent is a single change that leaves the others untouched.
That placement turns a non-human identity from a record in a directory into an enforced boundary. Attribution is per agent because the gateway sets it. Scope is per agent because the gateway checks it. The shared password problem disappears because the agent was never given the password. The same model and the recorded session that proves it are described in the getting started guide.
FAQ
Is a shared service account ever acceptable for an agent?
Yes, for a single workload with a tight scope where you accept that attribution stops at the account. It stops being acceptable as soon as a second consumer shares it or the data behind it is sensitive.
Does non-human identity require giving each agent its own database user?
No. With a gateway in front, agents authenticate as distinct identities while the gateway holds the target credential. You get per-agent attribution and scope without minting and rotating a separate database login for every agent.
How do I revoke one agent without breaking the rest?
Disable that identity at the gateway. Because authorization is evaluated per identity on the connection, the agent loses access immediately and no shared credential needs rotating.
hoop.dev is open source. The gateway, the identity model, and the connection plumbing are on GitHub. Clone it and wire up two agents against one connection to watch attribution split cleanly by identity.
