---
title: "Glossary: Agent identity"
canonical_url: "https://tokenobserve.com/glossary/agent-identity"
published: 2026-09-02
last_updated: 2026-10-21
---

# Glossary: Agent identity

Agent identity is what establishes which AI agent is making a given call: a credential the agent presents, and a registered record that credential resolves to, carrying the agent’s owner, declared purpose, permissions and lifecycle status. It is a different thing from the identity of the human the agent is acting for and from the identity of the workload the agent runs inside, and treating any two of the three as interchangeable is the most common source of authorisation error in agent systems.

## Also called

- AI agent identity
- non-human identity
- machine identity for AI agents

## In practice

Every agent call carries three identities, and a system that models only one of them will get an authorisation question wrong sooner or later. There is the human, who asked for the work and whose own access ought to bound it. There is the workload (the container, pod or function the code is executing in), which is what an infrastructure platform can attest to. And there is the agent: the durable logical actor with a name, an owner, a purpose and a permission set, which outlives any particular pod and is not the same thing as the person. The agent is the unit governance is scoped to, because it is the only one of the three that has a purpose you can compare behaviour against.

The credential half of an agent identity takes one of three shapes in practice. An opaque high-entropy bearer token, presented in an Authorization header. An OIDC or OAuth 2.1 client-credentials JWT, short-lived and issued by a directory. Or a certificate or signed identity document bound to a workload, in the SPIFFE style. Almost every estate runs the first, for a dull reason: mainstream agent frameworks and SDKs authenticate by putting a string in a header, so anything stronger requires code changes inside the customer’s agent rather than a change of base URL and key. The difference between a config edit and a project decides what gets adopted.

The consequence of a bearer credential should be stated plainly rather than designed around quietly. There is no cryptographic binding to a workload, so any process holding the string is the agent. A leaked token is valid until somebody revokes it. Rotation is a manual administrative act, which means it is rare, which means long-lived credentials accumulate: the standing-privilege pattern that agent governance exists to reduce. What follows from that is not that bearer tokens are unusable, but that the permission set becomes the load-bearing control: whatever the token can reach is whatever the roles name.

Storage and lifecycle are where a bearer identity is either defensible or not. The plaintext should exist exactly once, in the response to the create call; the store should hold a SHA-256 digest and a short display prefix, look the credential up by digest, and compare in constant time so that a store which ever answered a prefix match cannot be turned into a byte-at-a-time oracle. Expiry, revocation and a last-used timestamp are not conveniences: revocation is the whole of the incident response, a dormant key is a finding, and an identity whose revocation takes effect at the next deployment rather than the next call is not revocable.

The record half matters as much as the credential, because an identity that resolves to nothing but a name authorises nothing useful. What makes an agent identity governable is the set of fields the enforcement path reads on every call: a named human owner rather than a team alias, so that accountability for a non-human has somewhere to land; a declared purpose, so behaviour has something to be compared against; a lifecycle status, so suspension is a state rather than a deployment; role grants, budgets and data-handling requirements. Three failure modes recur. One credential shared across several agents destroys both attribution and per-agent revocation. An identity minted per deployment rather than per agent scatters an agent’s history across records nobody joins. And an agent configured with a human’s own provider API key inherits everything that person can do, permanently, while the provider’s records say the person did it.

## Example: One agent, four pods, and a fifth nobody meant to start

A support triage agent runs as four replicas behind a queue. All four present the same credential, which resolves to one registered record: an agent id, a named engineer as owner, a declared purpose of drafting first-response replies for a human to send, a read grant on the order database, one permitted model and a daily spend ceiling. A fifth process started by another team with a copy of the same string is indistinguishable from the other four — same agent, same grants, same attribution in the record. Nothing about the credential can separate them, because a bearer token proves possession and not provenance. The practical consequences are one credential per agent rather than per deployment, an owner who is a person rather than a distribution list, and revocation that bites on the next authenticated call.

## Routinely confused with

Workload identity: Workload identity answers what process is running and where, attested by the platform it runs on. Agent identity answers which governed agent is calling, and survives the workload being replaced. One pod may run several agents and one agent may move between pods, so a system that binds authority to the workload alone cannot express either.

Service account: A service account is a directory principal for a program, and it carries no purpose, no owner accountability and no declared behaviour. An agent identity is a service account plus the governance record — owner, purpose, risk tier, lifecycle — that the enforcement point reads on every call. The distinction is only real if that record is the one being enforced against rather than a copy of it.

On-behalf-of: On-behalf-of names the human an agent is acting for on one request. It does not change which agent is calling; the agent identity is still the authenticated principal. Conflating them produces the worst available design, in which an agent authenticates as the human and every action is recorded as the person’s.