Non-Human Identity: Why Your Agents Need Their Own Credentials

When a team wires their first agent into production, identity is almost never the interesting part. The interesting part is the reasoning, the tools, the demo. So the agent gets connected the fast way: it runs under a developer's personal token, or a service account with broad standing access, because that is what was lying around and it makes the demo work today.

However, that single shortcut is the finding that ends the engagement at the security board, and it ends it for a reason that has nothing to do with how good the agent is. An agent that borrows a human's credentials inherits a human's authority, a human's audit ambiguity, and a human's blast radius, while being a probabilistic system that reads adversarial input all day. You have attached a system that can be talked into things to a credential that can do almost anything. No homologation process signs that off, and it should not.

The reframe that unlocks this is simple to state and structural to implement. An agent is not a user, and it must not authenticate as one. It is a workload, and it needs its own identity, scoped to what it does, that lives and dies on a timescale a human credential never could.

A borrowed token is a skeleton key

Be concrete about why the shortcut is disqualifying, because "best practice" is not an argument a risk committee accepts.

A developer's personal token is designed for a human: it is long-lived, broadly scoped, and used across many systems interactively. Those are exactly the wrong properties for an agent. When the agent acts under that token, three things break at once. The audit trail can no longer distinguish the human from the agent, so you cannot say who, or what, took an action. The scope is far wider than the agent's task, so a confused-deputy attack has an enormous surface to exploit. And the credential is long-lived, so if it leaks, it stays valuable for weeks.

That last property is the one that turns a mistake into a breach. A stolen long-lived token with standing production access is a skeleton key. It works from anywhere, for a long time, against many systems. Everything about the way agents are usually connected maximizes the value of that key to whoever steals it.

The goal of workload identity is to make the key worthless.

Short-lived, least-privilege workload identity

The production posture inverts every property of the borrowed token. Each agent runs under its own non-human identity, distinct from any person, issued and rotated by the platform, scoped to exactly the actions its process requires, and short-lived by construction.

The pattern that the wider industry has converged on for this is worth naming, because it gives your security team a known quantity to reason about rather than something bespoke. SPIFFE, the Secure Production Identity Framework for Everyone, defines a standard identity for a workload, and SPIRE, its runtime, issues each workload a cryptographically verifiable identity document that is attested at issue time and expires quickly, often within minutes. The agent does not hold a static secret it could leak. It continuously proves what it is and receives a fresh, short-lived credential, which the platform can stop issuing the instant the workload should no longer run.

Layer least privilege on top of that and the identity carries only the narrow capabilities the process needs. Not "database access," but read_open_invoices. Not "send mail," but submit_decision_for_review. The identity is the thing the credential authenticates, and the capabilities are the thing it authorizes, and both are deliberately small.

Now replay the theft. An attacker who captures an agent credential holds something that expires in minutes, works only for a handful of named actions, and only from an attested workload. There is no static secret to reuse, no standing access to inherit, and no broad scope to pivot through. The key opens almost nothing, and only for almost no time. That is the design target: a stolen agent credential should be worth close to nothing.

Egress is the other half of the identity boundary

Identity controls what an agent may do. It does not, by itself, control where an agent may send data, and for a system that reads regulated content all day, where data can go is as important as what actions can fire.

This is why workload identity is paired with an explicit egress allow-list. The agent may reach only the specific destinations its process requires, named in advance, and every other outbound path is denied by default. Not "the internet, minus a blocklist." The opposite: nothing, plus a short list of permitted endpoints.

The reason this matters is exfiltration, the tenth item on the OWASP agentic risk list. Most of the earlier controls try to stop an agent from being manipulated. The egress allow-list assumes one of them eventually fails and asks a different question: even if the agent is successfully turned, where can it actually send the data? If the only permitted destinations are your own systems, a compromised agent has nowhere to ship what it stole. Least privilege on actions and least privilege on egress are two faces of the same boundary, and a serious homologation looks for both.

This is what actually passes a security homologation

Step back and look at what a homologation, the formal security sign-off a regulated enterprise requires before a system goes live, is really testing. It is not testing whether your agent is clever. It is testing whether a reviewer can reason about what the system can do when things go wrong.

A borrowed human token fails that test on contact, because the honest answer to "what can this credential do if it leaks?" is "almost anything, for weeks, from anywhere." There is no way to dress that up. The reviewer's job is to imagine the credential in an attacker's hands, and the picture is unacceptable.

Workload identity passes because it changes the answer. "What can this credential do if it leaks?" becomes "a handful of named actions, for a few minutes, only from an attested workload, and it can only reach these three internal endpoints." That is a bounded, testable, defensible answer, and a bounded answer is what a sign-off is for. The same shift makes the audit trail honest, because every action now traces to a specific agent identity rather than to an ambiguous shared account. You can finally say what took an action, not just guess.

None of this is exotic infrastructure for its own sake. It is the difference between a system a security board can approve and one it cannot, and that difference is usually the difference between a pilot that ships and one that dies in review.

So the question to bring to your next security board is not "is our agent accurate enough to trust?" It is if this agent's credential were stolen tonight, exactly what could the thief do with it, for how long, and to which destinations? If the answer is anything larger than a short list that expires in minutes, your agent is authenticating as a human, and that is the finding you will be handed back.

If you want to pressure-test how one of your agents authenticates and what its credential is worth to an attacker, book a meeting.