Identity Breaks Down When the Caller Is an Agent, Not a Person

Every IAM model in production today was designed around a fundamental assumption: the entity making a request is either a human or a static service. A person logs in with credentials. A service authenticates with a certificate or a token bound to a fixed role. The identity is known before the request arrives, and the authorization decision is made against that known identity.

Autonomous agents break this assumption completely.

What changes when the caller is an agent

An agentic AI system does not have a fixed identity in the way a service account does. It has a goal, a set of tools it can invoke, and a runtime context that evolves as it works toward that goal. The same agent instance might call your secrets manager, your Kubernetes API, your CI pipeline trigger, and your cloud provider within a single task execution. Each of those calls carries authorization implications. None of them were planned by a human who could be held accountable at the moment of the call.

The identity problem has three layers that existing IAM does not handle well.

The delegation layer. When a human authorizes an agent to act on their behalf, what exactly are they authorizing? In current systems, delegation is typically coarse: the agent gets a token with a scope, and that scope is either broad enough to cover every possible action the agent might take, or it is too narrow and the agent fails partway through a task. There is no standard mechanism for a human to say "act on my behalf, but only for the specific sequence of actions this task requires, and stop if you encounter something outside that sequence."

The provenance layer. When a request arrives at your API, you can verify who is calling. What you cannot verify with current tooling is why they are calling, what instructed them to call, and whether that instruction chain is intact and untampered. An agent calling your infrastructure API looks identical whether it was triggered by a legitimate orchestration system or by a prompt injection in a document it processed three steps ago. The request is the same. The intent behind it is not.

The scope-creep layer. Static service accounts accumulate permissions over time because it is easier to add a permission than to audit whether it is still needed. Agents make this problem acute. An agent that needs write access to one S3 bucket for one task will, if given a broad token for convenience, have write access to every bucket for every future task. The principle of least privilege requires knowing in advance what a task needs. Agents, by design, determine what they need at runtime.

Why existing patterns fail

The two patterns teams reach for first are both wrong in instructive ways.

The first pattern is giving agents a service account with broad permissions and trusting the agent's own logic to limit what it does. This puts trust in the application layer rather than the infrastructure layer. It assumes the agent will always behave as designed, that its instructions will never be manipulated, and that its reasoning will never produce an unexpected action sequence. These are assumptions you would not accept for a human employee. You should not accept them for an agent.

The second pattern is creating a unique service account per agent task. This is closer to correct in principle but operationally unworkable at scale. If you are running hundreds of agent tasks per hour, you cannot create, scope, audit, and rotate hundreds of service accounts at that rate using existing IAM tooling. The tooling was not built for that lifecycle.

What an identity fabric for agents looks like

The paper I published at ICAISET 2026 proposes thinking about this as an identity fabric rather than a set of static identities. The key properties that fabric needs to provide are these.

Ephemeral identity issuance. An agent task should receive an identity at the moment it begins, scoped to exactly what that task requires, and that identity should expire when the task ends. The issuance should be automated and policy-driven, not manually provisioned. SPIFFE and SPIRE give a reasonable foundation for workload identity that can be extended toward this model.

Delegation chain integrity. Every agent action should carry a verifiable record of the instruction chain that produced it. If a human authorized a task, and that task spawned a subtask, and that subtask is making a call to your API, the call should carry an attestation that can be traced back to the original human authorization. This is not currently standard in any orchestration framework, but it is the property that lets you answer the question: was this action actually authorized?

Behavioral boundary enforcement. Authorization should not just ask "does this identity have permission for this action" but also "is this action consistent with the pattern of behavior expected for this task." An agent retrieving a document does not need to make 400 API calls in 10 seconds. An agent that does that is either broken or compromised, and your infrastructure should be able to recognize the deviation and interrupt the session without waiting for a human to notice.

Where to start

If you are running agentic workloads in production today, three things are worth doing before the identity problem becomes an incident.

First, audit what tokens your agents are carrying and what scopes those tokens have. You will almost certainly find that agents have access to far more than any individual task requires. Narrow the scopes even if you cannot yet automate the issuance.

Second, add provenance logging at every tool call boundary. Before you can enforce delegation chain integrity, you need to be able to reconstruct the chain after the fact. Logging the instruction source alongside every outbound API call costs almost nothing and gives you the forensic foundation you will need later.

Third, treat agent identities as workload identities, not user identities. They should be issued by your workload identity infrastructure, attested by the environment they run in, and rotated on the task lifecycle rather than a calendar one. This is a mindset shift as much as a tooling one, and it is the right frame for everything that follows.

The IAM model that has served infrastructure teams for the past decade was not designed for callers that reason, plan, and act autonomously. Extending it requires thinking carefully about what identity means when the entity holding it was not provisioned by a human but instantiated by a goal.