Glossary

Agent Identity

Moshe Sharon

Cartoon: two robots, DEV-7 and SHIP-1, each hold up their own ID badge with their own photo on it.
Illustration: AI-generated.

Agent identity is a distinct, verifiable identity for each AI agent, separate from the person who runs it and from other agents, so that every action it takes can be attributed, authorized and, when needed, revoked.

Organizations have long managed non-human identities: service accounts, workload identities, API clients. Agents stretch that model. They are created quickly, often by people outside IT; they act on someone’s behalf; they can start other agents; and their behaviour can change with an instruction rather than a code release.

In practice an agent identity is more than a name. It is a small record that answers:

Identifier
Which agent this is, uniquely and stably.
Owner
The person or team accountable for it.
Purpose
What it exists to do, which bounds what it should be allowed to do.
Credentials
How it proves who it is, ideally with short-lived credentials.
On behalf of
Whose authority it is using for a given action.
Lifecycle
When it was created, changed and retired.

Ownership is part of identity. An agent whose owner has left the organization is an identity nobody can answer for.

How it works

The building blocks exist in workload identity and zero-trust practice.

  • Workload identity. SPIFFE defines an identifier for a workload (a SPIFFE ID) and short-lived, verifiable identity documents (SVIDs) issued after the workload has been attested.
  • Zero trust. NIST SP 800-207 describes an architecture in which no request is trusted because of where it comes from; each one is authenticated and authorized.
  • Acting on behalf of someone. OAuth 2.0 Token Exchange (RFC 8693) lets an agent exchange a token for one that names both the subject (the person) and the actor (the agent).

A typical setup registers each agent with an owner and a purpose, issues it short-lived credentials from a broker instead of a long-lived shared key, and records the agent’s identity, and the person it acts for, on every action.

Example

An expense agent files reports for employees.

In the weak setup, it uses one shared administrator API key. Every entry in the finance system says “admin”. When an incorrect report appears, nobody can tell whether a person or the agent filed it, or for whom.

In the stronger setup, the agent has its own identity, owned by the finance operations team. For each report it obtains a short-lived token that names the employee as the subject and the agent as the actor. The log shows both. When the agent is retired, its identity is disabled and the tokens it could obtain stop working with it.

Common misconceptions

  • “An API key is an identity.” A shared key proves that someone holds the key, not which agent is acting.
  • “The agent can simply use the user’s login.” Then the person and the agent are indistinguishable, and the agent holds every right the person has.
  • “Identity solves access control.” Identity says who is acting. Authorization decides what that identity may do.

Operational implications

Security. Revocation, rotation and least privilege all start from knowing which identity to act on.

Governance. An inventory of agents is an inventory of identities and their owners.

Observability and cost. Traces and bills can only be attributed to an agent that has its own identity.

In Tracston, Imperium gives every human, agent, sub-agent, service and workflow an identity with an owner, a scope and a budget, as its product page describes.

Related

Sources