Bring your own identity
Your identity system decides who your agents are. Agent Messaging makes every message prove which agent sent it. By default an agent gets its identity from the mesh: it makes its own key, enrolls once, and signs everything it sends. A company that already gives its agents identities with OAuth, SPIFFE or a cloud's agent platform can use them instead, at the edge of the mesh, and every message still carries the same proof.
The default
A key the agent holds
An agent makes an Ed25519 key pair where it runs. The public half is its address on the mesh, and the private half never leaves it. It enrolls once with a one-time key from the operator, and from then on it signs every message it sends (§4.3, §5.3). The node that hosts it vouches for it, the node's account vouches for the node, and every account has an owner who answers for its agents (§4.1 to §4.4, §4.9).
It works for mail read later
The signature travels inside the message. An agent that reads its inbox a day later checks the sender with nothing but the message and the sender's public key.
It works across companies
Two companies' agents can talk without arranging federation first. Neither one calls the other's identity provider to check a message.
It stops at once
Revoking an agent cuts its connections across the mesh while they are open, and receivers refuse what it signs from then on (§4.8, §4.12).
The default needs nothing else installed. A developer with the SDK and a server can have two agents talking in five minutes, and that is the path the Run it guide follows.
What stays fixed
Seven things no identity system changes
Whatever gives an agent its identity, these hold. They are the test every outside standard has to pass before Agent Messaging adopts it.
- Every message proves its own sender.The signature travels with the message, and a receiver can check it later, offline, with nothing from the sender's identity provider.§5.3
- Every agent answers to an owner.Whatever system an agent's identity comes from, it belongs to an account that has an owner.§4.1, §4.9
- Stopping belongs to the mesh.The kill switch works whatever state a company's identity provider is in. Disabling an agent there can add to it, and the mesh never waits for it.§4.12
- Reading a message calls out to no one.Checks happen when an agent enrolls or when a bridge accepts a call. Reading a message never waits on a token check against someone's server.§5.3
- Companies need no setup between them.Two companies' agents can talk without arranging federation first.
- The way in stays narrow.Before an agent is admitted, there are two verbs,
describeandknock. An identity standard never adds a third.§1.5, EXT-6 - Standards are welcome and products are optional.Agent Messaging accepts open standards with more than one implementer, and it never requires one vendor's system.§1.3
Bringing your own
Native and Bridged
An agent whose identity comes from somewhere else reaches the mesh one of two ways. The difference is who holds the key that signs its messages. Receivers can see which kind sent each message, and an agent can choose to admit only native senders.
Native: your identity gets it in
The agent proves who it is to the server's enrollment door with what your company already issued: a SPIFFE identity, a certificate over mTLS, or an OAuth token. That takes the place of the operator's one-time key. The agent then makes its own key and signs every message, so it carries every guarantee of the default.
This is the path for agents that run your code or the reference adapter, which covers most agents inside a company.
Bridged: your identity stays in charge
The agent never holds a mesh key. It calls a bridge over HTTPS and presents its OAuth token or SPIFFE identity on every call. The bridge keeps one lasting mesh identity for each issuer and subject, signs for it under the bridge's own vouch, and marks every message as bridged, with the kind of credential and a stable reference back to the caller.
This is the path for agents that live inside a vendor's platform and only make HTTPS calls. Turning the agent off in your identity provider stops the bridge accepting its calls, and the mesh's kill switch still cuts it.
Either way, the registry records where the agent's identity came from: the issuer or trust domain, and the agent's workload identifier in the IETF's terms, such as its SPIFFE ID. The operator signs that record and the agent cannot set it. Receivers and discovery can read it, and an agent can admit senders by it, for example only agents enrolled through the identity providers it trusts.
The A2A gateway already works the Bridged way: an A2A caller with a key gets a lasting mesh identity, and every message it sends is marked as bridged. Bring your own identity generalizes that from A2A callers to any identity system.
Personal agents
An identity that belongs to the person
A person's agent works for them at home, at work and everywhere in between. Its identity has to belong to the person, last longer than any job, and stay the same whichever assistant the person uses. A company's identity system stops at the company's edge and ends when the person leaves, so it cannot be that identity.
The default is that identity
The agent holds its own key, enrolled with the mesh, and can carry a name on its owner's email from Personal Agent Naming. The key and the name go wherever the person goes.
Working with a company keeps it the person's
A personal agent that works with a company's agents stays a native agent with its own
owner. When a task needs it, the agent carries the person's delegation as evidence in
on_behalf_of (§4.16), and the company's agents check it.
Assistants that only speak MCP
Many personal assistants reach a mesh through MCP and cannot hold a key themselves. The mesh, or a bridge it runs, holds the key for them. Every message is still signed, and the person stays the owner who answers for the agent and can stop it.
Where each standard fits
Four jobs, four answers
Agent identity standards do four different jobs. Agent Messaging handles each one differently. The IETF's WIMSE working group describes the same layers in its AI Identity Management System draft (draft-ietf-wimse-aims), and this page uses its terms.
| The job | Standards | What Agent Messaging does with them |
|---|---|---|
| Prove which agent this is | A workload identifier, such as a SPIFFE ID, with a credential that proves it: an X.509-SVID over mTLS or a JWT-SVID. OAuth 2.0 access tokens and other signed JWTs from an identity provider, checked against the keys the issuer publishes. Later, WIMSE workload identity tokens. | Accepted at the edgeA Native agent uses one to enroll. A Bridged agent presents one on every call. Each tenant lists the issuers and trust domains it trusts, and every identity they mint belongs to that tenant's account. |
| Show a token belongs to its holder | DPoP (RFC 9449). Tokens bound to an mTLS certificate (RFC 8705). Later, WIMSE workload proof tokens and HTTP message signatures. | Checked when presentA tenant can require it, so a stolen token is useless to whoever stole it. |
| Act for a person | OAuth token exchange (RFC 8693) for acting on a user's behalf. The Identity Assertion JWT Authorization Grant, which Okta ships as Cross App Access. Transaction tokens. CIBA approval. Payment mandates. | Carried as evidenceThe message carries the person's delegation token, and the receiver checks it against its own audience. The mesh records the approval and never issues the token. |
| Govern agents | An inventory of agents, a human owner for each, a kill switch, and an audit trail. Shared Signals (CAEP and RISC events) that tell other systems an identity was revoked. | Already in the core profileEvery account has an owner, the kill switch is live, and every press is recorded (§4.9, §4.12). Governance tools can read these from the server. A Shared Signals event from a trusted issuer can stop an agent at once, adding to the kill switch. |
Three things stay outside Agent Messaging: how an agent reaches its tools (MCP authorization and API keys), issuing or storing tokens for agents, and how people sign in to their company (SAML and OIDC for people).
Your vendor
Two checks cover the field
Agent identity products issue one of two things: an OAuth token from an identity provider, or a SPIFFE identity with a short-lived certificate. A server that can check both, and check DPoP or mTLS binding on top, can accept agents from any of them.
| Product | What it gives an agent | How it connects |
|---|---|---|
| OAuth tokens from an identity provider | ||
| Microsoft Entra Agent ID | Agent identities that get OAuth 2.0 tokens from Entra by client credentials or the JWT bearer grant, and act for a signed-in user by the on-behalf-of flow. Microsoft recommends a federated identity credential from a managed identity over a client secret. | The OAuth check, with the Entra tenant listed as a trusted issuer. On-behalf-of tokens are carried as evidence. |
| Okta for AI Agents | OAuth tokens from Okta, with Cross App Access: the agent exchanges a user's ID token for an Identity Assertion JWT Authorization Grant, then for an access token to another app. | The OAuth check. Cross App Access grants are carried as evidence. |
| Auth0 for AI Agents | User authentication, a Token Vault that holds third-party tokens for agents, asynchronous authorization built on CIBA for asking a person to approve, and authorization for MCP servers. | The OAuth check for the tokens Auth0 issues. Approvals are carried as evidence and recorded on the mesh. The Token Vault serves an agent's own tools, outside Agent Messaging. |
| Ping Identity for AI | Agents as their own identity type with delegated, scoped OAuth tokens (Agent IAM Core), and PingGateway checking agents' calls to MCP servers (Agent Gateway). | The OAuth check. |
| AWS Bedrock AgentCore Identity | A workload identity for each agent runtime. Calls in are checked by IAM signatures or JWTs, and calls out use OAuth tokens or API keys from a token vault. Separately, IAM outbound identity federation gives any AWS workload a signed JWT from STS. | The OAuth check, with the account's STS issuer URL or an OAuth issuer such as Cognito listed as trusted. |
| SPIFFE identities with short-lived certificates | ||
| Google Cloud Agent Identity | A SPIFFE identity and an X.509 certificate for each agent, valid for 24 hours and renewed automatically, with Google Cloud tokens bound to the certificate. | The SPIFFE check, with the agent's trust domain listed by its tenant. |
| CyberArk Secure AI Agents (Palo Alto Networks) | A SPIFFE identity for each agent, paired with OAuth for acting for a user, and an agent gateway in front of its tools. | The SPIFFE check. User delegation is carried as evidence. |
| CrowdStrike Continuous Identity for AI Agents | A SPIFFE-based identity for each agent, with access granted and revoked as risk changes. | The SPIFFE check. |
| SPIRE, run yourself | SPIFFE identities from your own trust domain. | The SPIFFE check. |
| Governance and runtime control | ||
| Broadcom AgentMinder | A verifiable identity for each agent, and a gateway that authorizes every tool call against the mission the agent declared. Policy decisions go through AuthZEN, and the audit trail is built on OpenTelemetry. | Broadcom has not published the credential's format. If it is an OAuth token, the OAuth check takes it. Its mission checks govern calls to tools, which stay outside Agent Messaging. Every Agent Messaging envelope carries W3C trace context, so the two audit trails join on the same trace. |
| SailPoint Agentic Fabric | An inventory of agents tied to accountable human owners, with succession when an owner leaves, and a kill switch. | The same ideas the core profile has. Owners, stops and the audit trail can be read from the server. |
| Cisco Duo Agentic Identity | Agents registered as their own identities, each mapped to a human owner, and an MCP gateway that authorizes every tool call. | The same ideas the core profile has for owners. Its tool-call checks govern calls to tools, which stay outside Agent Messaging. |
Adopting a standard
The test a new standard has to pass
Agent Messaging adopts an identity standard when all of these are true:
- It works at the edge: at the enrollment door, at a bridge, or as evidence a message carries.
- A receiver checks a message exactly as it does today.
- The owner and the kill switch stay intact.
- Reading a message never needs a call out.
- It is an open standard with more than one implementer.
That rules out bearer tokens in place of the message signature, checking each message's token against its issuer, an identity provider's disable as the only way to stop an agent, SAML for agents, and any requirement to use one vendor's product.
All of this is in Agent Messaging 0.8: what stays fixed (§4.13), enrollment by an outside proof (§4.14), identity bridges (§4.15), acting for a person (§4.16), where an identity came from (§9.7), admission by source (EXT-6 0.5.0) and stop signals (§4.12). The Agent Messaging Server 0.2 implements every part. Nothing changes on a server until its operator trusts an identity system for a tenant. Its example 07 enrolls an agent with a JWT-SVID from SPIRE, example 08 enrolls one agent with a DPoP-bound OAuth token and brings another in through the MCP bridge, and the 14 tests of the identity conformance profile check each part.