By Nolan Sullivan, Founding Growth Engineercomposite identity
A composite identity for agents is the tuple bound at the start of a session, the person from the directory, the agent workload, the client, and the task. Every later authorization, credential, and audit record is scoped to that resolution. If any part is missing, the session is anonymous and you are back to a shared service account.
The term exists because an agent request collapses several parties into one API call. A person delegated the work, an agent is performing it, a client is hosting the agent, and a task frames what the session is for. Most infrastructure records only the credential the call carried, which for agent traffic has usually meant a shared service account, so those parties are typically invisible to authorization and to audit. Composite identity for AI agents names the alternative, resolving all four at the start of the session, then scoping everything the session does to that resolution.
The concept sits inside the broader discipline of agent identity, and it is what separates an agent with a real identity from the generic machine credentials described in what is NHI. This page covers the tuple itself, what the four parts are, why each one has to be there, and where the resolution surfaces afterward.
What are the four parts of a composite identity for AI agents?
A session that reaches a tool carries four answers, resolved before the first call goes through. A concrete example of a fully resolved tuple:
| Part | Example | What it establishes |
|---|---|---|
| WHO | sarah@acme.org, via Okta SSO | The person from the directory whose authority the session runs on, or a dedicated identity with a named human owner when no person is driving |
| AGENT | forge.bot, owner: sarah | The attested workload doing the work, with an owner of record |
| CLIENT | Claude Code, OAuth 2.1 + PKCE | The harness the agent runs in and how it authenticated |
| TASK | fix-rate-limit | The unit of work the session exists to complete |
Each part earns its place by scoping something downstream. The person is the delegator, so authorization evaluates against their roles and groups, the same ones that already govern their direct access, which is the subject of extending IAM to agents. The agent is a principal with an owner of record, which is the field that connects the session to the agent inventory and makes someone answerable for the workload. The client establishes how the session authenticated. And the task is what credentials get scoped to, so access expires with the work instead of outliving it, the mechanism covered in task-scoped credentials.
The binding happens once, at session start. Individual tool calls do not renegotiate who is acting, and instead inherit the resolution and are evaluated against it.
Why isn’t SSO enough for AI agent identity?
SSO proves exactly one of the four parts. A valid IdP assertion says a person authenticated, but it says nothing about which workload is now acting, in which client, on what work. That gap is why SSO for AI agents on its own cannot carry the same weight it does for human sign-in. Handing that assertion to an agent makes the agent’s actions indistinguishable from the person’s own, which is the wrong answer for authorization, since an agent should not automatically hold everything its operator holds, and the wrong answer for audit, since the record cannot distinguish what Sarah did from what her agent did.
So the two halves are proven separately. The person signs in through the identity provider, and the agent workload is attested through workload attestation, meaning it presents evidence that it is the workload it claims to be. Together the signed-in person and the attested workload form the composite identity.
The attestation itself is a proof layer beneath the tuple. Speakeasy accepts four attestation classes: platform identity, a registered key, your IdP, and SPIFFE. All four terminate in the same token exchange, so nothing downstream branches on which proof was used. Which class fits which deployment is a runtime question, and the agent identity product page covers it. The tuple is the same regardless.
What happens to AI agent audit trails without composite identity?
When any part of the tuple fails to resolve, the session is anonymous, and anonymous agent traffic in practice means a shared service account. That failure mode has a consistent shape:
- Authorization loses its subject. With no person in the tuple, policy cannot evaluate against roles or group memberships, so enforcement degrades to a server-level allowlist that is the same for every caller.
- Credentials lose their scope. With no task and no person to bind to, the credential is a long-lived secret shared by everything that uses the account, and revoking it breaks all of them at once.
- Audit loses its answer. The record says the service account acted. Who drove it, on whose authority, and for what work typically cannot be recovered after the fact.
- Offboarding loses its hook. Nothing connects the account to a directory identity, so a person leaving the organization does not change what their agents can reach.
This is the general weakness of unowned machine credentials, described in what is NHI, showing up in agent traffic specifically. The composite identity is what each of those failures is missing.
How does composite identity appear in the AI agent audit trail?
The resolution is only worth performing if it survives into the record. Each audit event carries five dimensions from the tuple as first-class fields rather than strings inside a log line:
- Actor. The agent that made the call.
- Delegator. The person on whose authority it acted.
- Grant. The rule that allowed or denied the action.
- Attestation class. Which form of proof the workload presented.
- Credential provenance. Where the credential the call used came from.
That set is enough to answer who did what, on whose authority, under which rule, and with what proof. Because the fields are structured dimensions, those are query filters rather than a reconstruction project across raw logs.
How does the Speakeasy AI Control Plane resolve composite identity for AI agents?
On the Speakeasy AI Control Plane, identity resolves first, before policy, credentials, or anything else the session will do. The person signs in through the identity provider the organization already runs, whether Okta, Microsoft Entra ID, Auth0, WorkOS, Google Workspace, Ping Identity, or most SAML or OIDC providers, over OAuth 2.1 with PKCE. The agent workload is attested through one of the four classes above, and both proofs terminate in the same token exchange.
That exchange is the standard RFC 8693 flow. It mints a session whose subject is the person and whose actor is the agent, and the full tuple resolves to exactly one upstream credential or to an error, failing closed rather than falling back to anything shared. How those credentials are minted and expired is covered in task-scoped credentials, and the full runtime model lives on the agent identity product page.
From there the platform holds the resolution steady for the life of the session. Every tool call is authorized against the person’s grants, every credential is bound to the person and the task, and every allow and deny lands in the AI agent audit trail with the actor, delegator, grant, attestation class, and provenance attached. Where the binding holds, deprovisioning the person in the directory ends the agent access that ran on their delegated authority. To see composite identity for AI agents resolved against your own directory, talk to us.