AI agent identity is an identity associated with an AI agent so that it can be distinguished from other agents, users and services, and its actions can be attributed to it. Where the identity is verifiable, it also supports authentication and authorization decisions.
For most of the short history of AI agents, identity was an afterthought. An agent ran with whatever credential was nearest to hand: the developer’s API key, the user’s OAuth token, a shared service account. That is changing quickly. Identity providers and cloud platforms now issue identities to agents as a category of their own, the IETF’s workload identity working group has adopted a draft on identity management for AI agents, and NIST’s National Cybersecurity Center of Excellence published a concept paper in 2026 on the identity and authority of software agents. The question has moved from whether agents need identities to what an agent identity should actually identify.
Three ways an agent can be identified
| Approach | Who appears as the actor | What is lost |
|---|---|---|
| Borrowed identity: the agent uses a user’s token or a shared service account | The user, or the service account | That an agent acted at all, and which one |
| Workload identity: the agent runs as a registered workload, such as a SPIFFE identity issued to the service that hosts it | The deployment that runs the agent | Who the agent was acting for, unless that is carried separately |
| Delegated identity: the agent has its own identity and acts on behalf of a user, with both recorded | The agent, on behalf of the user | Nothing in principle, if the whole chain is carried |
Borrowed identity is still common because it is easy. Its cost appears in the logs of the systems the agent touches: they record that a user or a service account made a change, when the decision was made by an agent. Workload identity fixes that by giving the agent its own principal. Google Cloud, for example, issues each agent a SPIFFE-based identity with a short-lived certificate derived from the resource that hosts it.
Delegated identity is the model the standards are converging on. OAuth 2.0 Token Exchange (RFC 8693) distinguishes impersonation, where one party simply becomes another within the rights of a token, from delegation, where the acting party keeps its own identity separate from the party it acts for. The IETF draft for AI agents builds on the same idea: the agent’s identity is carried as the client, and the user or system it acts for as the subject.
The identifier tracks the deployment, not the behavior
Every one of these schemes identifies an agent by where it runs or how it was registered: a workload path, a hosting resource, a client registration. None of them identifies the agent by what it is configured to do. An identifier can therefore stay the same while the configuration changes: change the model, rewrite the system prompt or add a tool, and the agent keeps its identifier while its capabilities and likely behavior change. It can also change when the configuration does not: Google’s documentation notes that an agent redeployed with an identical name and configuration receives a new principal. Either way, the identifier follows the deployment.
That gap matters as soon as identity is used to decide anything. Logs that attribute two actions to the same agent may be describing two different agents in all but name. A policy chosen by agent identifier will apply yesterday’s rules to today’s configuration unless someone updates it. Identity answers “which deployment acted”; it does not, on its own, answer “acting as what”.
Attribution is not authorization
Identity establishes who acted. Authorization establishes what that actor was allowed to do. The two separate most visibly in delegation chains. A token issued under RFC 8693 carries three kinds of party. Its top-level claims identify the subject: the party on whose behalf the request is made. Its act claim identifies the current actor: the party actually making the request. Earlier actors in a chain of delegation can be recorded as act claims nested inside it. The specification says that access control must consider only the top-level claims and the current actor; earlier actors are informational only. In a system where a user asks an orchestrator, which asks a sub-agent, which calls a tool, the decision considers the user and the sub-agent. The orchestrator in between is in the record, but not in the decision.
An example
A finance team’s reconciliation agent runs under a service account that also belongs to a nightly batch job. The agent’s prompt is updated to let it propose corrections, and it is given a new tool for posting journal entries. A week later an auditor asks who posted a set of entries. The ledger says the service account. The batch job’s logs show it did not run. Working out that the agent posted them, under its new configuration, means reconstructing the answer from the agent framework’s own traces, if they were kept.
Giving the agent its own identity fixes the first half of the problem: the ledger would name the agent. It does not fix the second half: the same identifier now covers an agent that can post entries and the agent that, a week earlier, could not.
Where Sentience fits
Sentience Governor, the free, open-source runtime governance library, attributes every event in its record to an agent identifier and a session. Policy resolution uses that identifier to choose which governance profile applies, once per session, and records which binding was used along with a fingerprint of the profile’s content on each governed event. A reviewer can therefore see not only which agent acted, but exactly which version of its policy was in force. How agents are identified depends on the integration: developers name each agent in the MCP, LangChain and Pydantic AI integrations, while Claude Code sessions are identified per session. Governor records identity; it does not authenticate agents or issue credentials.
The Governor Model, the architecture described in Sentience’s white paper, treats identity, scope, memory and policy as things to be governed together rather than separately, which is where this entry’s argument leads; the paper describes architecture and direction rather than shipped capability. For organizations that need identity to drive what happens at run time, Sentience Runtime Enforcement applies policy at the control points in your own infrastructure, including the gateways and authorization layers that already carry agent identity, so that the agent, the party it acts for and the policy that applies are evaluated together before an action proceeds.
Often confused with
Agent authorization. Identity says who the agent is. Authorization says what it may do. A verifiable identity is what makes authorization decisions about a specific agent possible.
Authentication. Authentication proves an identity, for example with a certificate or token. Identity is what is being proved.
The model. Many agents can run on the same model. An agent identity identifies a deployed agent, not the model behind it.
Where the concept stops
An agent identity makes actions attributable to a deployment and, where it is verifiable, makes authentication and authorization possible. It does not capture the agent’s configuration, so it cannot by itself say what the agent was capable of when it acted. It does not say what the agent was permitted to do, and in a delegation chain it does not ensure that the agents between the subject and the current actor are considered in the access decision. Those depend on recording configuration and policy alongside identity, and on authorization that considers the whole chain.