The Global AI Agent Identity Map 2027: Wallets, Workload IDs, OAuth and Verifiable Credentials
An agent can prove control of a key and still lack permission to do the job. This map explains which identity layer belongs where, and which claims each layer leaves unresolved.
Decentralised News Research · Last verified 30 September 2026 · 2027 planning guide
What Matters
AI agents need identities that survive deployment changes, credentials scoped to the task, and a clear link to the person or organization responsible. Use workload identity for software, OAuth for delegated service access, and wallet controls for payments. Add decentralized identifiers or verifiable credentials when portability matters. No single identifier proves identity, authority, reputation and financial control together.
DN Evidence Block
Review date: 30 September 2026. Evidence window: current SPIFFE specifications, AWS AgentCore Identity documentation, the published MCP authorization specification, W3C DID Core and Verifiable Credentials standards, and A2A documentation. Sample: six identity or access layers, not six competing vendors. Decisive facts: SPIFFE uses SVIDs to authenticate workloads; AgentCore separates agent and user context; MCP requires resource-specific token validation; W3C credentials do not define an authorization framework. Original DN asset: Identity Architecture Selector and the Identity Coverage Matrix below. Method: documentation review; no production deployment or penetration test. Reviewer: DN editorial desk; no independent technical review. Evidence and limitations.
DN Alpha Thesis: identity is a stack of claims
A business should be able to answer four questions about every consequential agent action: which software acted, which person or organization it represented, which policy allowed the action, and which evidence records the result. DN calls this the Four-Claim Identity Test. The concept is an editorial framework, not a new protocol.
The mistake is to collapse those questions into one token. A service key can establish access without explaining the human mandate. A wallet signature can prove key control without identifying the operator. A credential can show that a trusted issuer made a statement without making the holder an authorized purchaser. A signed discovery record can bind metadata to a publisher without demonstrating safe execution.
This map concerns selection and coverage. Authorization evidence, reputation scoring and agent discovery each need separate treatment. Teams can adopt a useful identity architecture without inventing a universal agent passport.
The global identity map: what each layer actually proves
| Layer | What it establishes | Best for | What it does not establish | Cost, access and custody |
|---|---|---|---|---|
| Platform account / service principal | A named identity within a provider's account system. | A single business application or cloud boundary. | Portable trust across unrelated systems; a task-specific human mandate. | Provider account and IAM administration; custody depends on the service, not its login. |
| Workload identity: SPIFFE/SVID | A workload authenticates within a configured trust domain using verifiable identity documents. | Service-to-service agents across infrastructure. | The human business purpose, payment budget or quality of the agent's output. | Open specifications; issuance, attestation and operations have costs. No asset custody inherent in the standard. |
| Managed agent identity: AWS AgentCore | Agent identity can anchor access across IAM, OAuth and API credentials; user context can be bound separately. | Teams building within the AWS agent runtime and identity environment. | A universal identity accepted by every external service; automatic least privilege. | AWS account, regional service availability and usage pricing; credential vault is not a treasury wallet. |
| OAuth delegated access | A client receives defined access from an authorization server, including user-delegated access where configured. | Agents working with a user's calendar, CRM or other protected service. | Permission to perform any possible action just because authentication succeeded. | Provider-supported scopes, consent and token lifecycle; no asset custody inherent in OAuth. |
| Wallet/account key control | A valid signature can demonstrate control under the relevant account and verification rules. | On-chain payment and transaction signing. | Legal identity, benign intent, service reputation or a valid business mandate. | Network fees and key-management overhead; custodial, self-custodial or policy-managed arrangements differ. |
| DIDs and verifiable credentials | Identifiers, verification relationships and issuer-backed claims, subject to the chosen method and verifier policy. | Portable attestations between organizations that agree on issuers and semantics. | Universal trust, current authority, or acceptance by every counterparty. | Method, issuer and resolver infrastructure vary; standards alone neither charge a universal fee nor hold assets. |
Status as of review: the cited standards and documentation are available; AWS AgentCore Identity is documented as a usable managed service, with account and regional restrictions. This is an architecture map, not a “best vendors” ranking. No security scores are assigned.
DN Agent Identity Architecture Selector
Choose the task and confirm the controls you already have. The result recommends layers and lists evidence gaps. It runs locally in the page, collects no keys and performs no infrastructure audit.
Confirmed controls
Recommended architecture
Rule-based design aid. No numerical trust score or security certification. A checked box is a reader assertion and still requires evidence. Export contains only the selected options and recommendations.
Three concrete deployments
A South African SME's CRM assistant
Assign a named service identity to the workflow and use provider-supported OAuth delegation for each employee. Begin with read-only CRM scopes. Record the employee, agent ID and task ID separately. When the employee leaves, revoke delegated access and test the next call. A DID is optional unless an external partner requires portable proof.
A trading agent with a wallet
Bind the wallet or exchange service account to an accountable operator. Enforce asset, counterparty, amount and expiry limits outside the prompt. Keep key control and payment authority distinct in the log. A verified identity cannot make a bad trade profitable or reverse a settled payment.
An enterprise's service mesh
Use workload identity to authenticate agents between services. SPIFFE/SPIRE is one implementation path; managed cloud IAM may be sufficient in a single provider. Apply resource policy after authentication and keep user delegation separate when a service acts on an employee's behalf.
A cross-company agent marketplace
Authenticate the endpoint and operator, then agree on the meaning of any credential claims. Check issuer, expiry and status, plus your own access policy. Keep discovery metadata separate from proof of current authority. Portability is useful only when the receiving organization can validate and interpret it.
MCP and A2A belong beside identity
The published MCP authorization specification requires servers to validate tokens intended for the resource. Passing a token through to the wrong downstream service can undermine the boundary even when the agent is correctly named. For a production MCP integration, test issuer, audience, scope and expiry handling and how user consent maps to the actual tool.
A2A describes agent capabilities and security requirements through Agent Cards. Treat a card as discovery metadata that informs a connection. Authenticate the endpoint and enforce policy separately. Neither a compelling description nor a listing in a directory certifies an agent's performance.
Measure revocation at the last action point
Deleting an agent from a directory can leave sessions, refresh tokens, cached credentials or pending jobs alive elsewhere. DN recommends a Revocation Coverage Record: list every downstream credential and resource, disable the principal or delegation, and attempt the action again at each resource. Record the time and result. The meaningful endpoint is the protected action, not the administration screen.
- Name the operator, workload, user delegation and task identifiers.
- Inventory credentials, issuers, audiences, scopes and expiry.
- Attempt an action outside the scope and record the rejection.
- Revoke authority and retest pending and fresh requests.
- Verify the audit trail connects every consequential action to the responsible principal.
These are proposed acceptance tests, not results from a DN deployment. Do not publish a revocation time or coverage percentage until the tests have actually run.
What would prove DN's approach wrong?
A single identity system would weaken the case for layering if it demonstrated accountable ownership, portable workload authentication, enforceable delegation, payment controls and prompt-independent revocation across the full target workflow. Until then, components should be judged by the claims they cover and the residual gaps. If a simpler managed identity covers every required claim for one internal workflow, adding decentralized identity is unnecessary cost.
Methodology and primary evidence
This edition maps documented capabilities as of 30 September 2026. “Global” refers to architecture across platform, cloud and cross-organization boundaries; it is not a country census, market-share estimate or complete vendor inventory. DN has not tested deployments, pricing, conformance or attack resistance. The selector is a deterministic editorial rule set based on deployment boundary, delegated user access, payment authority and five reader-confirmed controls. It does not verify those assertions.
- SPIFFE identity and SVID specification and working with SVIDs.
- AWS AgentCore workload identities and credential retrieval and agent-user context.
- MCP published authorization specification.
- W3C DID Core and Verifiable Credentials overview.
- A2A specification.
Freshness: review quarterly and after material specification changes. Change log: v1.0, 30 September 2026, initial architecture map and selector. Corrections: send a primary source and the disputed claim through DN Contact. For crypto platform decisions, visit DN Pathfinder.
Frequently asked questions
What is an AI agent identity?
A durable identifier and authentication mechanism for the software acting in a workflow. It should be linked to an accountable operator and evaluated separately from the permissions granted to it.
Is a wallet address enough to identify an agent?
It identifies an account on a network and can be used in a key-control challenge. It does not, by itself, establish the legal operator, deployment provenance or permission to act for another person.
How is authentication different from authorization?
Authentication verifies an asserted identity. Authorization decides which resources and actions that identity may access under a policy.
Does an A2A Agent Card prove trustworthiness?
A card describes an agent and its capabilities and security requirements. Trust depends on authenticating the endpoint, validating relevant proofs and enforcing an independent access policy.
Do agents need decentralized identifiers?
Only when identifier portability or independently verifiable claims solve a concrete interoperability need. Many internal agents can begin with managed workload identities and scoped credentials.
Can a verifiable credential grant payment authority?
A credential can express a claim, but the recipient must still validate its issuer, status and meaning and apply an authorization policy. The W3C credential model does not define that policy for you.
What should happen when an employee leaves?
Disable the user delegation, revoke associated refresh tokens and keys, inspect active jobs, and verify that further downstream actions fail. Do not rely only on deleting a directory entry.
Does this tool audit my infrastructure?
No. It recommends an architecture from your selections and reports unconfirmed controls. It does not connect to accounts, inspect secrets or certify security.
What is the simplest safe starting point?
One named workload identity, narrow read-only access, an accountable operator, short-lived credentials where supported, an action log and a tested revocation path.
About the Author
