Agent Identity and Authentication: The Missing Primitive in Agent Security

A refund gets issued that never should have. You pull the trace and find a payments sub-agent executed it. The refund was legitimate in form, so no guardrail fired. The harder questions come next: which agent actually made the call, and how did it have permission to move money in the first place? If the answer is "it was acting on behalf of a customer-support agent, which was acting on behalf of a user, using that user's token," you have an identity problem, not an access problem.

Discovery tells you an agent exists. Access management tells you what it is allowed to touch. Neither answers the question underneath both: who is this agent, really, and can you prove it? Without a durable, verifiable identity for each agent, credential rotation, impersonation defense, and audit trails all break down. Identity is the primitive that everything else assumes and few teams have actually built.

This post covers why human authentication models break for agents, the three mechanics of agent identity (issue, rotate, verify), the two failure modes that follow when identity is missing, and what good looks like once every agent action is attributable to a specific actor.

Identity is not access management

State the seam clearly before going further, because these two get conflated constantly.

Identity answers who the agent is. Access management answers what that identity may do. They are separate controls that depend on each other. An access policy that says "this actor may write to the refunds database" is meaningless if you cannot prove which actor is making the request. Discovery, covered elsewhere, is the step before both: it finds that an agent exists at all. Identity is what you establish once you have found it and before you decide what it may touch.

This post stays on identity. When an agent's permissions and data access come up, that is the access-management concern sitting on top of identity, not the subject here.

Why human identity models break for agents

Human authentication assumes a session. A person logs in once, proves who they are, and acts within a bounded window under a set of permissions tied to their role. The model works because humans are relatively slow, singular actors who authenticate deliberately.

Agents do not behave that way. An agent spins up on demand, calls other agents, invokes tools, and delegates work continuously and non-deterministically. Treating that actor as "just another service account" or letting it piggyback on a human's OAuth token creates three concrete problems.

• Over-broad inherited scopes. A human's token carries the human's full permissions. An agent borrowing that token gets all of them, not the narrow slice the task needs.
• No attribution. When ten agents share a service account or ride the same user token, an action in the log traces back to the account or the human, not to the specific agent that made the call. You lose the ability to answer "which agent did this?"
• Credentials that outlive the task. A long-lived secret issued to a static service persists by design. An agent's work is often ephemeral. A credential that outlives the task becomes a standing liability with no owner watching it.

The mismatch is structural. Human auth was built for a durable actor doing sequential work. Agents are transient actors doing fan-out, delegated, concurrent work. The primitive has to change with them.

The three mechanics: issue, rotate, verify

A workable agent identity system rests on three operations.

Issue. Each agent gets its own identity rather than sharing one. A credential for an agent should carry enough to answer, at minimum, which agent this is, what it was spun up to do, and how long the credential is valid. The point is that the identity is unique to the agent and distinct from both the human who triggered the work and any other agent in the system. A customer-support agent and the payments sub-agent it delegates to should hold different identities, not the same borrowed token.

Rotate. Prefer short-lived credentials over long-lived secrets. This matters more for agents than for static services because agents multiply the blast radius of a leaked secret. A long-lived credential copied out of one agent's environment can be replayed indefinitely, by anything, as that agent. Short-lived credentials that expire with the task shrink the window in which a stolen secret is useful. Long-lived agent secrets are the most dangerous kind precisely because agents are numerous, ephemeral, and easy to lose track of.

Verify. At call time, a downstream tool or agent has to confirm the caller is who it claims to be, not just that it presented some token. When the payments sub-agent receives a refund request, it should be able to verify the identity of the caller and the scope that caller was actually granted, rather than trusting a bearer token at face value. Verification is what turns an identity claim into something enforceable.

Failure mode one: agents impersonating each other

In a multi-agent system, impersonation is trivial when secrets are shared or copyable. If Agent A can present Agent B's credentials, then A can act as B, and every downstream tool that trusts B will trust A. Once a credential is portable, the identity it represents is no longer a fact, it is a guess.

This compounds the prompt-injection risk covered in Arthur's guardrails work. A hijacked agent is bad. A hijacked agent holding a portable credential is far worse, because the attacker inherits not just the agent's behavior but its identity, and can present that identity to anything that trusts it. Prompt injection gets the agent to misbehave; a copyable credential lets the misbehavior wear a trusted face.

The defense is identity that cannot be trivially copied and reused: per-agent credentials that are short-lived and verifiable, so a stolen secret is both narrow in scope and quick to expire.

Failure mode two: permission inheritance

The second failure is quieter and more common. It is the classic confused-deputy problem, adapted to agents.

An agent acting on behalf of a user inherits the full breadth of that user's permissions rather than the narrow slice the task requires. Take the customer-support agent that delegates a refund to a payments sub-agent. If the sub-agent runs with the user's full token, it can do everything the user can do, not just issue the one refund it was asked to. The task needed a keyhole; the agent got the whole door.

This is how a low-risk agent quietly becomes a high-risk one. Nothing looks wrong. The agent completes its task correctly most of the time. But the gap between what the agent needs and what it can do is pure risk surface, waiting for a prompt injection, a logic error, or a compromised upstream caller to exploit it. Blanket inheritance is convenient to build and expensive to live with.

The alternative is scoped delegation: the sub-agent receives an identity granted only the permissions the delegated task requires, and nothing more.

What good looks like

A production-grade agent identity posture has a few clear properties.

• Per-agent identities that are unique, verifiable, and short-lived. No shared service accounts standing in for many agents, no borrowed human tokens, no long-lived secrets sitting around after the task is done.
• Scoped delegation instead of blanket inheritance. When one agent hands work to another, it passes the narrow slice of permission the task needs, not its entire scope.
• Every action attributable to a specific agent identity in the trace. When something goes wrong, "which agent did this?" has a definitive answer.

That last property is where identity meets a foundation Arthur already has. Thorough instrumentation and centralized telemetry, the practices behind Observability and Governance, mean that once agents carry real identities, every action they take is already captured and attributable in the trace, and inspectable in a governance review. Identity supplies the who; the trace records what that who did. Together they turn an audit question into a lookup.

Agent identity as a first-class, verifiable primitive is where the space is heading, and it is not fully solved anywhere yet. The teams that will get there first are the ones whose agents already emit complete, centralized telemetry, because attribution is only useful once there is a distinct identity to attribute an action to.

Takeaway

Identity is the primitive underneath discovery and access management. Discovery finds the agent, access management scopes it, but neither works if you cannot prove which agent is acting. Issue each agent its own short-lived, verifiable credential, delegate scoped permissions instead of inheriting a human's full token, and make sure every action ties back to a specific agent identity in the trace.

Start with the seam: audit where your agents currently share service accounts or ride user tokens, and treat each of those as an identity you have not yet issued.

Want to see how thorough instrumentation makes agent actions attributable and governance-ready? Book a demo with an AI expert or explore the Agent Development Toolkit.

‍