What Is Agent Identity? Why AI Agents Break the Human-vs-Service-Account Model

Get ready, this is a mouthful. Agent identity is a distinct, per-instance identity for each running AI agent, tied to the agent definition that created it, chained to the human or service it is acting on behalf of, carrying a scoped set of claims, inherited by any sub-agents it spawns, and revocable when the task ends. It is needed because the two identity models enterprises already have, human identity and machine service accounts, each solve half the problem and neither solves it at agent speed.

As organizations move from one agent to hundreds to thousands, “which agent did this, on whose behalf, with what authority” becomes the question every security, audit, and operations conversation turns on. This post explains what agent identity is, why existing identity systems do not cover it, and what a workable model looks like.

The two identities enterprises have today, and why neither fits agents

Almost every interaction with a production system today is covered by one of two principal types.

Human identity. A person authenticates with an identity provider and receives a token (typically OIDC). The token carries claims about who they are and what groups they belong to, and downstream systems make authorization decisions against those claims. Human identity assumes a human is present, acting deliberately, at human speed.

Machine identity. A service gets a service account. That account has its own credentials and its own permissions, and the service uses them to call other services: a database, a queue, another API. Machine identity assumes the service is a fixed, long-lived thing whose behavior is determined by the code it was deployed with, and that one identity per service is enough.

An agent is neither, and it is also both.

It acts on behalf of a user, so it needs to carry that user’s authority. But it runs as a workload, often with no human in the loop at the moment of action, so it needs machine credentials. It is not a fixed service: fifty instances of the same agent definition may be running at once, each working on a different task for a different person, and treating them all as one service account means you can no longer say which instance touched which resource. And it moves at machine speed, spawning sub-agents and calling tools faster than any approval workflow built for humans can keep up with.

Try to force an agent into either box and you get a predictable failure. Give it a human’s token and you have a machine impersonating a person with that person’s full permissions, indistinguishable in the logs. Give it a shared service account and you have an identity that is simultaneously over-privileged (it holds the union of everything any instance might need) and unaccountable (you cannot tell instances apart).

What agent identity actually requires

Agent identity brings the two worlds together. A workable model has five properties.

1. One identity per instance. Every running agent gets its own identity, not a shared one for the agent type. When fifty instances are running, there are fifty identities, and the audit log can say precisely which one accessed which resource.
2. Tied to the agent definition. Each instance identity is linked to the agent definition (the code, configuration, and tool catalog) that created it, so you can reason about a class of agents while still distinguishing its members.
3. Chained to the principal it acts for. The agent’s token establishes that it was chartered on behalf of a specific user or service. It inherits a subset of that principal’s claims, scoped to the task. This agent, working for this user, who has access to these resources, may touch this subset of them.
4. Inherited by sub-agents. When an agent spawns a sub-agent, the sub-agent’s identity is chained off the parent’s. It inherits the parent’s claims and policies, and it draws from the parent’s token and tool-call quota. Without this, every spawn is an escape hatch.
5. Revocable and short-lived. The identity exists for the duration of the task and is revoked when the task completes or the budget runs out. Nothing about it is permanent.

The practical consequence is least privilege that is dynamic rather than static. An agent starts with the minimum set of resources for its charter. If it discovers it needs something else, it does not have it; instead it has an endpoint it can call to request that a human approve additional permission, for a bounded duration, to finish the task. The approval is logged against the instance identity, so the audit trail stays intact.

That is a very different shape from “this service account can read these three buckets.” It is identity that is minted, scoped, delegated, inherited, and revoked continuously, at the pace agents operate.

Zero trust, SPIFFE, and why agents finally push enterprises over the line

None of this is new in principle. The industry has been talking about zero trust security for well over a decade. The foundational work was done at Google and captured in SPIFFE, the Secure Production Identity Framework for Everyone, which Joe Beda (Stacklok co-founder, and Craig’s collaborator for the last 15 years) authored. SPIFFE and its reference implementation SPIRE give every workload a cryptographically verifiable identity, issued dynamically, with no static credentials to leak. Many West Coast technology companies run on it today.

Enterprises have wanted to get to that posture for years. What has held them back is not conviction but cost. A bank is running a huge corpus of software, and if you follow the lines far enough there is a mainframe. The curve to justify refitting all of that for a progressive, cloud-native identity model has simply been too steep.

Agents change the math. You cannot run agents safely without the ability to mint a specific identity for a specific instance with a specific set of claims that can be revoked when the task is done. There is no incremental path from shared service accounts to that. So the thing enterprises were putting off becomes the thing they have to build first.

One caveat worth stating plainly: most existing zero trust work starts from the assumption that the systems driving it are grounded in human identity and operate at human speed. Agents spawn sub-agents, which call services, which crunch data and access tools, all in seconds. Agent identity has to be native to that pace. The SPIFFE model is the right foundation; the delegation and inheritance semantics for agents are the part the industry is still working out, and the part we spend most of our time on.

How Stacklok approaches agent identity

Identity is at the core of how Stacklok’s platform is built, and it is why the platform is self-hosted and Kubernetes-native rather than a SaaS control plane.

Identity at the gateways. ToolHive, our MCP platform, is where the agent-to-data boundary gets identity-aware. MCP servers run in isolated containers, and every tool call carries the identity of the agent instance and the principal it acts for, so authorization and audit happen at the membrane between agents and your systems.

Identity in the harness. Mecatl, our open source cloud-native agent harness, is designed with identity as a first-class concern and the agent loop separated from the execution environment. An agent can act with a user’s or a service’s authority, so the runtime keeps a clear boundary between the loop that reasons and the environment that executes, and stamps interactions with the instance identity. Delegation to sub-agents is part of the harness contract rather than something each application reinvents.

Self-hosted, so identity stays inside your trust domain. The identity provider, the gateways, and the harness all run inside your network perimeter or your VPC, integrated with the authentication and authorization systems you already operate. No regulated organization we work with is willing to route agent identity through a startup’s cloud, and we do not ask them to.

Kubernetes-native, so workload identity is already there. Kubernetes provides service accounts, namespaces, and the workload-identity primitives that SPIFFE/SPIRE build on. A harness that runs as an ordinary Kubernetes workload inherits that foundation instead of bolting identity on afterward.

Mecatl is early and we are building it in the open. The identity model is one of the places where we have chosen to get the bones right before chasing features, because it is the kind of structural decision that is nearly impossible to retrofit in production.

Frequently asked questions

What is agent identity? Agent identity is a distinct, per-instance identity for each running AI agent. It is tied to the agent definition that created it, chained to the user or service the agent acts on behalf of, carries a task-scoped set of claims, is inherited by sub-agents, and is revoked when the task ends.

Why can’t AI agents just use a service account? A shared service account cannot distinguish between instances, so you cannot tell which of fifty running agents touched a resource. It also holds the union of every permission any instance might need, making it over-privileged by design. Agents need one identity per instance with least-privilege claims scoped to the task.

Why can’t AI agents use the user’s token? A machine acting with a human’s full token is indistinguishable from the human in logs and holds all of that person’s permissions, not just those needed for the task. Agent identity should be chained to the user’s identity and inherit a subset of their claims, not impersonate them outright.

How should sub-agent identity work? A sub-agent’s identity is derived from its parent’s. It inherits the parent’s claims, policies, and quotas (tokens, tool calls, runtime). If sub-agents could obtain fresh identities or budgets, spawning one would be a way to escape the parent’s constraints.

What is SPIFFE and how does it relate to agent identity? SPIFFE (Secure Production Identity Framework for Everyone) is an open standard for issuing cryptographically verifiable workload identities dynamically, without static credentials. Authored by Joe Beda and now a CNCF project, it is the foundation for zero trust workload identity. Agent identity builds on SPIFFE-style workload identity and adds delegation from a principal, sub-agent inheritance, and task-scoped revocation.

What is zero trust for AI agents? Zero trust for agents means no agent is trusted by virtue of its network location or a shared credential. Every instance has its own verifiable identity, every request is authorized against task-scoped claims, every interaction is identity-stamped and logged, and privileges are granted for bounded durations and revoked when the task completes.

How does an agent get permissions it was not granted? It should not be able to escalate on its own. A well-designed system gives the agent an endpoint to request additional permission; a human approves it for a bounded duration; the grant is logged against the instance identity; and it expires when the task finishes.