Can You Trust an Autonomous Agent? The Identity and Delegation Layer Behind MCP, A2A, and AP2

Part 2 of the agentic-web series. Start with Part 1; Part 3 proposes what’s missing, and Part 4 follows the retry problem.

Give an agent a valid OAuth token and it can call an API. For years, that was the whole trust conversation. But an agent that acts on its own, spends money, and hands work to other agents raises four questions a bearer token can’t answer — and each now has its own standard.

Layer 1 — Identity: who is this agent?

TLS proves you fetched a card from acme.ai — but the moment that card is cached, indexed by a registry, or relayed agent-to-agent, the channel proof is gone. That’s why A2A v1.0 made Agent Cards signed artifacts: canonicalize (RFC 8785), sign (JWS, RFC 7515), publish the signature on the card, verify against the publisher’s keys. For identity that outlives any one platform, did:web:acme.ai resolves to /.well-known/did.json — decentralized identity, same discovery substrate.

The Agent Card, up close

The card itself is one JSON file doing three jobs: identity (who signed it), résumé (skills that registries index and LLM routers rank), and API contract (which transport and auth to use). Two field pairs do the heavy lifting: skills[] + supportsAuthenticatedExtendedCard splits your public shingle from your private catalog, and securitySchemes + signatures makes the card enforceable rather than descriptive.

Layer 2 — Authorization: which flow gets the token?

Identity is not authorization — a verified agent still needs a scoped token from the server’s /.well-known/oauth-protected-resource chain. The real design decision is which grant flow, and one question routes it: where is the human relative to the agent at token time?

Two of these five deserve sequence diagrams, because they’re the newest and the most agent-shaped.

CIBA is the standards answer to human-in-the-loop: the agent pushes an approval to your phone mid-task, keeps working, and polls for the token — no browser redirect, no “reply YES to approve” hack. Auth0, Okta, and WSO2 all shipped agent-focused CIBA in the past year; it’s under active MCP-WG discussion.

ID-JAG / Cross-App Access (IETF OAuth WG, draft -04, 2026) lets an enterprise agent swap the user’s existing SSO assertion for tokens to other apps — making the IdP, not each SaaS app, the governance point for agent access.

Whatever the flow, three hardeners are defaults: DPoP (RFC 9449) binds tokens to the agent’s key, RAR (RFC 9396) replaces blunt scopes with authorization_details like “spend ≤ $150 at merchant X,” and PAR (RFC 9126) protects the request itself.

Layer 3 — Delegation: on whose behalf, and how far?

Real agentic work is a chain — user → orchestrator → specialist → merchant MCP — and a single shared token loses whose authority is in play. Token Exchange (RFC 8693) fixes the foundation: every hop re-mints the token, delegation nests inside the act claim, scope shrinks while attribution grows. Delegation, not impersonation. What’s new in 2026 is the control plane around the chain: Identity Chaining carries it across trust domains, Transaction Tokens propagate it inside your domain, AuthZEN’s agent profiles (COAZ, AARP) externalize the per-tool decision, and Shared Signals/CAEP revokes it mid-task. The chain proves, AuthZEN decides, Txn-Tokens propagate, CAEP revokes.

Layer 4 — Accountability: can we prove it later?

“The agent decided to” is not an audit record. AP2’s mandates — each a selectively disclosable SD-JWT credential (RFC 9901) — encode one elegant asymmetry: the riskier the autonomy, the earlier and more detailed the human signature. Human present: the strong signature lands on the final cart. Human absent: the user signs a detailed Intent Mandate up front, and the agent closes within its bounds. Every party ends up holding cryptographic proof instead of logs — and the rails are live: Mastercard Agent Pay ran its first authenticated agentic transaction in Q3 2025, Visa’s Intelligent Commerce Connect hits GA in June 2026, and FIDO is aligning verifiable intent with passkeys.

How it composes

An MCP tool call, an A2A hand-off, and an AP2 purchase are the same motion at different stakes: present a verifiable identity, carry a scoped delegation, leave a provable record — at every hop. A production platform needs six components, each mapped to a standard rather than invented: an agent runtime (workload identity + DPoP keys), a discovery layer (.well-known cards and catalogs), an authorization server speaking the full grant playbook, a policy decision point (AuthZEN/RAR), verifying resource servers, and an evidence store for mandates. If a box in your architecture maps to none of these, ask why it exists.

What’s unsettled, and what to do

Agent identity is the contested layer — enterprise IAM (Entra Agent ID, Okta), DIDs/VCs, and SPIFFE are all claiming it, and consolidation will be messy. Until then, five defaults serve builders well:

• Sign your cards, publish a did:web, regenerate both in CI — never hand-edit a signed card in production.
• Match the grant to the moment; if your agent asks for approvals over chat, you needed CIBA.
• Never share a service account across hops — token exchange with act chains, always.
• DPoP + RAR on every flow — sender-constrained, fine-grained by default.
• Anything that spends gets a signed mandate and a human at the mandate boundary.

---

Part 1 mapped the protocols; this mapped the trust underneath them. The uncomfortable truth: most agent deployments today run on layer 2 alone. The stack above is how “autonomous” stops meaning “unaccountable.”

Correction (2026-08-09): AP2’s mandates are selectively disclosable SD-JWT credentials (RFC 9901) presented over OpenID4VP, not W3C Verifiable Credentials as originally published. The LinkedIn original preserves the earlier text.