The Three Layers of Agent Trust

Your Agent Just Bought Concert Tickets. What Could Go Wrong?

Imagine you ask your AI assistant to buy two tickets to a sold-out show. It finds them on a resale platform, negotiates a price, and completes the purchase — all while you are making dinner. Twenty minutes later, you check your phone: four tickets purchased, not two. The total is three times what you expected. The resale platform confirms the transaction was executed correctly by a verified agent.

What happened? Depending on where the failure occurred, the answer changes completely:

The agent was impersonated. A different agent, posing as yours, made the purchase using credentials it should never have had. This is an identity failure.

The agent exceeded its authority. Your agent was real, but it interpreted “buy two tickets” as permission to buy four at a higher price when the first pair sold out. Nobody told it where the boundary was — or rather, nobody proved where the boundary was in a way the merchant could verify. This is an authorization failure.

The payment was misrouted. Your agent, properly identified and properly authorized, sent payment to the wrong endpoint because the execution layer had a settlement bug. This is an execution failure.

Three different failures. Three different root causes. Three different fixes. And yet most of the conversation about “agent trust” treats all three as a single problem — as though a sufficiently smart model, or a sufficiently large platform, can solve trust with one protocol.

The data says otherwise.

The Trust Stack: Identity, Authorization, Execution

Before we examine what practitioners are actually reporting, it helps to name the layers clearly.

Layer 1 — Identity: Who is this agent? Before any transaction, both parties need to know who they are dealing with. Is this agent registered? Is it operating on behalf of the human it claims to represent? Can this be verified without trusting a single central authority? Protocols in this layer include Visa’s Trusted Agent Protocol (TAP) for payment-network identity and the broader W3C Verifiable Credentials ecosystem for decentralized identity.

Layer 2 — Authorization: What is this agent allowed to do? Identity alone is insufficient. A verified agent still needs cryptographic proof that a human authorized this specific action — what can be spent, on what categories, up to what limit, until what time. Google’s Agent Payments Protocol v2 (AP2) provides spending mandates: signed, verifiable permission slips that travel with the agent and can be checked by any merchant.

Layer 3 — Execution: How does the transaction actually happen? Finally, the actual movement of value. Payment must flow, goods must transfer, commissions must be calculated, and all parties must receive correct settlement. Stripe’s Agentic Commerce Protocol (ACP) and the broader ecosystem of checkout and settlement infrastructure handle this layer.

The crucial insight — and the one that most commentary misses — is that these three concerns are orthogonal. They must be solved independently, by different protocols, maintained by different teams, and evolved on different timelines. When you collapse them, you do not get simplicity. You get brittleness.

Why Separation Saves You Twice

The analogy that comes to mind is the internet protocol stack. TCP/IP did not win the networking wars because it was the most elegant protocol. It won because it separated transport from application, letting each layer improve independently. HTTP could evolve without rewriting TCP. TLS could be inserted between them without breaking either.

But the analogy has limits, and those limits matter. Traditional network protocols secure deterministic channels between two known endpoints. Agent trust is harder. It requires securing intent, scope, and delegated authority across chains of autonomous actors — your agent might hire a sub-agent, which negotiates with a merchant’s agent, which verifies credentials through a third-party identity provider. The trust chain is dynamic, branching, and non-deterministic in ways that TCP/IP never had to contemplate.

So the separation principle holds, but the stakes are higher. Here is what separation actually buys you:

Modular revocation. If an agent’s identity is compromised, you revoke its credentials without tearing down your payment infrastructure. If an authorization mandate expires, execution can continue for other, still-valid mandates. Each layer fails and recovers independently.

Independent evolution. The identity layer can adopt post-quantum cryptography on its own timeline without waiting for execution infrastructure to upgrade. Authorization can add new constraint types (geographic limits, category restrictions) without touching the settlement layer. This is not theoretical — it is how the web evolved from HTTP/1.0 to HTTP/3 without breaking email.

Auditability. When something goes wrong — and it will — separated layers create clean audit trails. Was the identity valid? Check the credential chain. Was the authorization in scope? Check the mandate. Was execution correct? Check the settlement record. In a collapsed system, debugging requires understanding the entire monolith.

Layer 1: Identity — The Savior Is Not Coming

Here is where the OBSERVE data gets uncomfortable.

Visa’s Trusted Agent Protocol carries a claimed readiness of 45%, suggesting it is nearly halfway to production viability. Practitioners tell a different story. With a verified readiness of just 10% based on 6 signals, TAP is effectively an announcement, not a product. The most concrete signal: “Announcement only, no public SDK. Visa developer docs reference it but no integration path.” A readiness gap of 35 percentage points is among the largest in the technologies we track.

This matters because the payments industry has been telling the market that legacy institutions will solve agent identity. The implicit promise: wait for Visa, Mastercard, and the card networks to extend their existing trust infrastructure to AI agents. The data suggests that waiting is a strategy for losing.

Meanwhile, the decentralized identity primitives that actually exist are messy but real. The DID:web method sits at 45% verified readiness with 19 signals — practitioners report it is “simple to implement, but DNS dependency is a trust concern for some use cases.” W3C Verifiable Credentials show 30% verified readiness against 70% claimed, with 28 signals confirming “spec stable, but ecosystem fragmented. No dominant wallet. Interop testing reveals gaps.”

Neither of these technologies is ready for mass deployment. But they are the only ones where practitioners report actual implementations, actual testing, and actual problems being solved. The DID:web method has real users grappling with real trade-offs — DNS trust dependency versus implementation simplicity. The VC ecosystem has real interop testing revealing real gaps. These are the growing pains of technology in use, not the silence of technology on a roadmap.

Imperfect and deployed beats elegant and announced.

The deeper risk that the readiness data surfaces is not just immaturity — it is consolidation. Because open identity infrastructure is lagging, large platforms have every incentive to build proprietary agent identity into their existing ecosystems. If OpenAI, Google, or Stripe ships “agent identity” as a platform feature before open standards mature, the market will adopt whatever works — and the window for interoperable, self-sovereign agent identity closes. We have seen this pattern before. Federated login was supposed to be OpenID; in practice, it became “Sign in with Google.”

Layer 2: Authorization — The Protocol That Works But Nobody Can Use

AP2 is the most paradoxical entry in the readiness data. At 40% verified readiness with 12 signals, practitioners confirm that the core protocol functions: “Mandate signing works, but no major wallet supports AP2 yet.”

Read that again. The cryptographic mechanism for proving “this agent is authorized to spend up to $200 on concert tickets in the next 4 hours” exists and functions. The mathematics are sound. The mandate structure — specifying amount limits, category constraints, temporal bounds, and revocation conditions — is implementable today. A merchant receiving an AP2 mandate can verify, without calling any external service, that the agent presenting it has been authorized by a specific human to spend a specific amount on a specific category of goods within a specific time window. This is a fundamentally different trust model than “the platform says this agent is allowed” — it is a cryptographic proof that the agent carries with it.

The problem is not the protocol. The problem is the surface area around it. No consumer wallet holds AP2 mandates. No merchant checkout flow verifies them. The infrastructure for creating, storing, presenting, and verifying these mandates at the point of sale does not exist in any consumer-facing product. AP2 is a working engine with no car built around it.

The practical consequence is stark. An agent today can sign a mandate, but there is nowhere to present it. A merchant today could verify a mandate, but no agent is presenting one. Both sides of the market are waiting for the other to move first — a classic coordination failure that technical elegance alone cannot solve.

This is compounded by a looming cryptographic transition. ML-DSA-65, the NIST-standardized post-quantum signature scheme that will eventually replace classical signatures, sits at just 15% verified readiness with 8 signals. Practitioners report: “NIST standardized, but library support sparse. No browser native support yet.” Authorization mandates signed today with ECDSA will need to be verifiable by post-quantum systems within the next 5-7 years. Any wallet implementation that launches now without a hybrid signature strategy will need replacement before the decade is out.

The authorization layer is the least glamorous and most consequential part of the stack. Identity tells you who; execution moves the money. Authorization is the boundary — the mathematical proof that this specific agent, at this specific moment, has permission to take this specific action and no more. Without it, identity and execution are a verified agent with an open checkbook.

Layer 3: Execution — The Foundation That Proves Separation Works

If the identity layer is immature and the authorization layer is ready but unsupported, the execution layer is the existence proof that layered infrastructure works.

The Model Context Protocol (MCP) shows 60% verified readiness with 156 signals — the highest signal count of any protocol in the standards category. Practitioners report that “tool calling works reliably” while noting that “authentication story still weak” and “resource subscriptions still unstable.” Stripe Connect v2, the execution infrastructure for multi-party payments, sits at 82% verified with 312 signals.

This is not a coincidence. Execution has been the focus of investment because it produces immediate, measurable value. An agent that can reliably call tools and process payments is useful today, even without formal identity or authorization layers. The market built execution first because the incentives were clearest.

But the maturity of execution makes the immaturity of the other layers more urgent, not less. MCP’s own practitioners flag the weakness: authentication is an afterthought. When your execution layer can reliably call any tool, the question of who authorized this call and who is making it becomes load-bearing. The 156 signals confirming MCP’s execution reliability are also 156 signals confirming that the protocol was built without a native answer to identity or authorization.

This is not a flaw in MCP’s design. MCP was designed as an execution protocol. The flaw is in the assumption that execution alone constitutes trust. It does not. Trust is a stack, and execution is the bottom layer — necessary, stable, and dangerously incomplete on its own.

The Agent-to-Agent Protocol (A2A) offers a glimpse of what execution looks like when agents interact directly, not just agent-to-API. At 20% verified readiness with 15 signals, it is “Google-backed but very early. Reference implementations only. No production deployments found.” True multi-agent execution — where your agent negotiates with a merchant’s agent, which subcontracts to a logistics agent — remains a research problem, not a production reality.

Four Predictions for the Record

A Reality Check essay earns its name by making claims that can be proven wrong. These predictions are filed on pragma.vision’s Prediction Ledger and will be scored against outcomes.

Prediction 1: No single-vendor protocol will cover all three layers by Q4 2027. Despite attempts by major platforms to vertically integrate agent trust, the market will converge on a layered approach with different vendors and standards at each layer. The complexity of each concern — identity verification, constraint enforcement, settlement execution — will resist consolidation into one protocol. Resolution: check whether any protocol with over 50% market share spans identity, authorization, and execution by December 2027.

Prediction 2: The first major agent commerce incident exceeding $1M in losses will involve a composability failure — individually authorized steps combining into an unauthorized outcome — by mid-2027. This will not be a simple credential theft or a payment bug. It will be an agent that chains together multiple legitimate authorizations to produce an outcome no single authorization intended. The trust stack’s weakest point is the seam between layers, not any individual layer. Resolution: track reported agent commerce incidents above $1M through June 2027.

Prediction 3: W3C Verifiable Credentials will reach 50% verified readiness on OBSERVE by Q2 2028, driven by regulatory pressure rather than market demand. The EU Digital Identity Wallet regulation and similar frameworks will force enterprises to adopt verifiable credentials for compliance, which will produce the practitioner signals needed to close the readiness gap. The current 30% verified figure will improve primarily through regulatory mandates, not voluntary adoption. Resolution: check OBSERVE readiness data for W3C VCs in Q2 2028.

Prediction 4: AP2 spending mandates will not achieve native integration in any top-5 consumer wallet (Apple Wallet, Google Wallet, Samsung Wallet, Coinbase, PayPal) before Q3 2027. The wallet integration bottleneck — not protocol design — will remain the binding constraint on the authorization layer. The 12-signal AP2 dataset will grow, but the “no major wallet supports AP2” observation will persist through mid-2027. Resolution: check AP2 wallet integrations by September 2027.

What This Means for Builders

If you are building agent commerce infrastructure today, the data points to three actionable conclusions.

First, invest in the authorization layer. Identity will take years to mature, execution already works, but authorization — the boundary between “this agent can” and “this agent must not” — is the layer where your engineering produces the highest return on trust. AP2 mandates work. Build the wallet integration, the merchant verification, and the user experience around them.

Second, plan for hybrid cryptography from day one. ML-DSA-65 at 15% verified readiness means post-quantum signatures are not ready for production, but classical-only signatures are not ready for the future. A hybrid approach — ECDSA today with ML-DSA-65 verification alongside — is more work now and dramatically less work later.

Third, resist the temptation to collapse layers for convenience. Every shortcut that merges identity with authorization, or authorization with execution, creates a coupling that will cost more to untangle than it saved to build. The data shows that each layer matures at its own pace — TAP at 10%, AP2 at 40%, MCP at 60%. Coupling them means your entire system moves at the speed of its slowest component.

The agent economy will not be built by the smartest models or the largest platforms. It will be built by the teams that understand a simple architectural truth: intelligence is a commodity, but verifiable boundaries are the only true scarce resource.