By Nolan Sullivan, Founding Growth Engineeragent identity
Agent identity is the binding of every AI agent session to a real principal in the organization’s directory, the person driving it, or a dedicated identity with a named human owner. The session authenticates through the identity provider, every tool call is authorized against that principal’s grants, and every allow or deny is recorded under a name.
Three parts of the definition are load-bearing:
- The binding runs to the directory. The principal behind an agent is typically one the organization already manages, audits, and offboards.
- Authorization happens per tool call. An agent connected to a Model Context Protocol (MCP) server is checked again each time it reaches for
create_refund, rather than once at connection. - The record carries a name. When security asks who did something, the answer is a person, or an agent whose owner is a person, rather than a token id.
Why does a shared service account fail for AI agent identity?
The common first rollout is a bot token in the MCP config, shared by every agent on the team. Three controls that already work for people stop working at that moment:
- Attribution. The audit reads as the service account. After an agent issues a refund, “the billing bot did it” is usually the only available answer, and it names no one.
- Least privilege. The key is granted the union of every task on the team, so
get_invoiceandcreate_refundtravel on one credential and per-tool policy has no principal to attach to. - Lifecycle. People leave and keys do not. No directory event ends a config file’s access, because the key was never bound to a person.
These are the standard non-human identity failure modes applied to a caller that decides its next action at runtime. The catalog of what breaks, including the OWASP ranking of each failure, is in what is NHI. The full authorization path from an identity provider to a single tool call, with the policy grammar and the audit record, is in From your IdP to a tool call.
What does agent identity bind together in a composite identity?
A session under agent identity resolves to a composite identity with four parts:
- The person, as a directory identity from the identity provider, or a dedicated agent identity with a named human owner when no person is in the loop.
- The agent workload, so the same person driving two different agents produces two distinguishable actors.
- The client, whether Claude, Cursor, or a custom harness.
- The task, so the session’s authority is scoped to the work at hand rather than to everything the person could ever do.
The composite is what makes the audit record complete, this person, through this agent, in this client, for this task. How the four parts compose, and why each one matters on its own, is the subject of agent composite identity.
Credentials follow the same shape. The agent never holds a raw secret for an upstream system. It presents a short-lived credential minted for the task, bound to the identity, and expiring when the task completes, which is covered in task-scoped credentials. The session itself authenticates over OAuth 2.1 with PKCE and dynamic client registration, so modern agent clients complete the flow without custom integration.
How does agent identity differ from non-human identity (NHI)?
Non-human identity (NHI) is the category of digital identities that authenticate and are authorized on behalf of software, covering service accounts, workloads, pipelines, bots, and AI agents. An agent is an NHI, and the vendors who define the category, among them Okta and Oasis, now include AI agents in it alongside service accounts and tokens.
Agent identity is the practice the agent class requires within that category. A service account typically runs a job someone defined in advance. An agent chooses its next call at runtime and usually acts on a person’s behalf, and that difference moves the binding. A workload identity can reasonably resolve to an application, but an agent identity has to resolve to a principal a human stands behind, the person driving the session when one exists, or a dedicated identity with a named human owner when the agent runs on its own. Extending the identity and access management the organization already operates to cover that binding, rather than standing up a parallel system, is covered in extending IAM to agents, along with the harder question of whose permissions a custom agent built by one person and triggered by another should run with.
What happens to AI agent access when a person is deprovisioned?
Under agent identity, offboarding can end agent access through the same directory event that ends everything else. Directory Sync keeps users, groups, and attributes current from the identity provider, so when a person is deprovisioned, every agent session bound to their identity loses access on the same event that disables their login. Where the binding holds, there is no separate list of agent keys to find, because the agent never held a standing key of its own.
Two registers make that binding checkable rather than assumed. The agent inventory records each agent, the identity it runs as, and its human owner of record, which is the field that can surface an autonomous agent whose owner has left so it can be reassigned or revoked. Agent discovery finds the agents that never got an identity at all, the population described in what is shadow AI, so they can be brought under the same binding instead of running outside it.
How does the Speakeasy AI Control Plane implement AI agent identity management?
The Speakeasy AI Control Plane ships the binding described above as one system, on the path agents already take to tools:
- Sessions authenticate through the identity provider the organization runs, whether Okta, Microsoft Entra ID, Auth0, WorkOS, Google Workspace, Ping Identity, or most SAML or OIDC providers, over OAuth 2.1 with PKCE and dynamic client registration.
- The platform holds the identity, never the secret. It records the agent’s name, its owner, its grants, and a rule saying that an assertion from a trusted issuer is that agent. It holds no secret for the agent and cannot reissue one.
- Every tool call is authorized against the principal’s grants. Agents reach tools through the platform’s MCP gateway, so the check fires on the call, and every allow or deny is recorded under a name from the directory.
- Task-scoped credentials are minted per task. Short-lived, identity-bound, and expired when the task completes, so deprovisioning a person in the identity provider ends their agents’ access with them.
Together, these controls replace the shared service account with AI agent identity management the organization can actually audit. The commercial page, with the identity model and the attestation classes behind it, is agent identity. To see a session resolve to a name from your own directory, talk to us.