The Trust Layer Deep Dive

#Quotable Findings

1. AP2 was launched in September 2025 alongside payments and technology partners as an open protocol for initiating and transacting agent-led payments.^[1]

2. As of mid-2026, that stack has crystallized around three primitives: SD-JWT+KB as defined in IETF RFC 9901,^[2] AP2's Mandate model as published by Google's google-agentic-commerce/AP2,^[3] and the PEP/PDP authorization split popularized by Microsoft, Cordum, and the OPA community.^[4][5]

3. AP2 inherits its credential format from RFC 9901, "Selective Disclosure for JSON Web Tokens," published November 2025.^[2]

4. The IETF working group repository (oauth-wg/oauth-selective-disclosure-jwt) ships reference implementations in Python, Kotlin (two), Swift (two), Rust (two), TypeScript (six), Java, Go (two), and Haskell, with EU Digital Identity Wallet libraries in the Kotlin and Swift sets.^[6]

5. GitHub issue #180 (March 17, 2026) on the AP2 repository proposes restricting IntentMandate visibility to the User ↔ Shopping Agent boundary, partly to bound the blast radius if a Shopping Agent is later found to have been compromised.^[7]

#1. The category, in one sentence

When an autonomous agent buys something, four parties — user, agent, merchant, payment processor — must each be able to prove what they authorized, against whom, and within what scope. The Trust Layer is the cryptographic stack that makes those proofs verifiable without any of them needing to trust the others.

As of mid-2026, that stack has crystallized around three primitives: SD-JWT+KB as defined in IETF RFC 9901,^[2] AP2's Mandate model as published by Google's google-agentic-commerce/AP2,^[3] and the PEP/PDP authorization split popularized by Microsoft, Cordum, and the OPA community.^[4][5]

AP2 was launched in September 2025 alongside payments and technology partners as an open protocol for initiating and transacting agent-led payments.^[1] The broader analyst frame casts it as the "trust and governance layer" of agentic commerce that complements an execution-layer protocol like x402 and a merchant-integration protocol like ACP.^[8]

This paper maps that stack: the cryptographic primitives, the protocol-level constructs, the architectural pattern, and the failure modes Sonnet & Prose have called out as decisive risks.

#2. The Asymmetric Pivot

The single most consequential change in agent-payment cryptography in the past 18 months is what AP2 quietly mandates in §Security and Privacy Considerations: deterministic signature schemes such as Ed25519 are not allowed for the Checkout JWT.^[9] Instead, "the Checkout JWT MUST be signed using a digital signature scheme (e.g., ECDSA) and not a deterministic signature."^[10]

This is the Asymmetric Pivot. The reason is structural, not stylistic. The checkout_hash claim in a Checkout Mandate makes use of the entropy already included in the JWT signature to prevent guessing the Checkout contents.^[9] If a deterministic signature is used, that entropy is gone — and the protocol becomes susceptible to rainbow-table attacks against the hash. The fix in the AP2 spec is explicit: "If a signing algorithm (e.g. deterministic signature scheme such as Ed25519) is used that does not include this then a salt of sufficient entropy MUST be present in the Checkout."^[9]

The practical consequence shows up across every example payload in the spec. Each Checkout and Payment Mandate JWT in ap2-protocol.org's reference uses "alg": "ES256" and "typ": "kb+sd-jwt",^[11] and the embedded cnf claim binds a P-256 public key:

"cnf": {
  "jwk": {
    "crv": "P-256",
    "kty": "EC",
    "x": "QpSyxPQHy38xckypDr54gZ3T42zj9iLtV4koyb5U27c",
    "y": "37HLd7JJinxjJIn8J7HijssoeclbfhdW-gUL7feI9lw"
  }
}

ES256 (ECDSA over P-256 with SHA-256) is required across the AP2 reference; the Universal Commerce Protocol's AP2 Mandates Extension makes this even more explicit: "Algorithms: ES256 (required), ES384, ES512."^[12] HS256 — the symmetric HMAC scheme that, according to one practitioner write-up, remains the default in a large share of legacy SaaS JWT pipelines — is not in the permitted set. The Asymmetric Pivot is the precondition for the rest of the stack.

#3. SD-JWT+KB (RFC 9901): the IETF foundation

AP2 inherits its credential format from RFC 9901, "Selective Disclosure for JSON Web Tokens," published November 2025.^[2] The IETF Datatracker draft history shows the spec moving from draft-12 through draft-22 before standardization.^[13][14][15]

The data shape is deceptively simple. An SD-JWT is composed of an Issuer-signed JWT plus zero or more Disclosures. An SD-JWT+KB is an SD-JWT plus a Key Binding JWT (KB-JWT). Compact serialization concatenates them with ~ separators:^[2]

<Issuer-signed JWT>~<Disclosure 1>~<Disclosure 2>~...~<Disclosure N>~<KB-JWT>

Three properties make this format the right primitive for agent commerce. First, selective disclosure: Disclosures are base64url-encoded JSON arrays containing a salt, a claim name (when applicable), and a claim value, and only the digest appears in the issuer-signed JWT.^[2] A holder presents only the disclosures the verifier needs — a Credential Provider learns the payment instrument but not the line items.^[11]

Second, key binding: when Key Binding is enforced, "a Holder has to prove possession of a private key belonging to a public key contained in the SD-JWT itself."^[2] The KB-JWT carries iat, aud, nonce, and sd_hash — the last being the base64url-encoded hash over the issuer-signed JWT and selected disclosures.^[2] If a verifier replays an SD-JWT against a different audience, the KB-JWT signature fails.

Third, cryptographic chain integrity: the sd_hash value is computed over US-ASCII bytes of the encoded SD-JWT — issuer-signed JWT, tilde, each selected disclosure followed by tilde — and uses the same hash algorithm declared in _sd_alg.^[2] No daisy-chained hash; one stable bind value per presentation.

The IETF working group repository (oauth-wg/oauth-selective-disclosure-jwt) ships reference implementations in Python, Kotlin (two), Swift (two), Rust (two), TypeScript (six), Java, Go (two), and Haskell, with EU Digital Identity Wallet libraries in the Kotlin and Swift sets.^[6] The format is no longer aspirational; it's the credential primitive of the EU eIDAS 2.0 wallet rollout, and AP2 piggybacks on that ecosystem.

#4. AP2 Mandates: Cart, Intent, Payment

AP2's Section 4 ("Trust Anchors: Verifiable Digital Credentials & Mandates")^[16] defines three Verifiable Digital Credentials (VDCs) — Cart Mandate, Intent Mandate, Payment Mandate — secured as SD-JWT+KB credentials. The newer specification documentation collapses two of these into the umbrella term "Checkout Mandate."^[17] Fintech analyst commentary frames the Mandate model as the first rail-agnostic protocol that gives merchants and banks "dispute-grade proof of approval" — a signed packet showing the user approved a specific cart, valid across cards, real-time bank transfers, and stablecoins.^[18] Either way, the protocol distinguishes:

Cart Mandate (Checkout Mandate). Captures the user's authorization for a purchase when the human is present at the time of purchase.^[16] Generated by the Merchant based on the user's request and cryptographically signed by the user, "typically using a hardware-backed key on their device with in-session authentication."^[16]

Intent Mandate. Critical for human-not-present scenarios. The user pre-authorizes a Shopping Agent to act autonomously within stated constraints — a maximum dollar amount, an allowed merchant list, an allowed payment instrument set.^[16] "It serves as the final, non-repudiable authorization to execute a purchase in the user's absence."^[16]

Payment Mandate. Provides the Credential Provider, Network, and Merchant Payment Processor cryptographic proof that the Shopping Agent is authorized to pay for a particular Checkout.^[17] The Payment Mandate is bound to a particular Checkout via the cryptographic hash of the Checkout JWT.^[17] Independent commentary describes the Payment Mandate as a "minimal credential derived from the cart or intent" that gives payment networks visibility into agent involvement and the type of approval without exposing more data than needed,^[19] and frames the three-mandate structure as "boring on purpose" because it relies on explicit, signed statements rather than inference about user intent.^[19][20]

The Checkout Mandate's normative claim list is short and load-bearing:^[17]

The Payment Mandate adds transaction_id, payee, pisp (optional Payment Initiation Service Provider), payment_amount, and structured constraint blocks (payment.amount_range, payment.allowed_payees, payment.reference).^[21]

#5. The Open / Closed binding chain

AP2's most important architectural choice is the Open/Closed Mandate split. An open Mandate (mandate.checkout.open.1, mandate.payment.open.1) carries constraints — currency, max amount, allowed payees, conditional transaction ID — but is not bound to any specific transaction.^[17][21] A closed Mandate (mandate.checkout.1, mandate.payment.1) is a Mandate authorized for a particular transaction.^[17]

Closed Mandates MUST contain the sd_hash claim binding them to the open Mandate they were derived from.^[22] Open Mandates MUST contain the agent's key (via the cnf claim) so that only the agent that held the open Mandate could create a closed Mandate with a valid signature.^[22] Together, this produces a delegate-payload chain that's verifiable end-to-end:

User signs open Mandate (with constraints + agent_pk in cnf)
                ↓
Agent signs closed Mandate (with sd_hash binding to open Mandate)
                ↓
Merchant verifies signatures + checks closed conforms to open's constraints

The Flows specification's autonomous case is the canonical sequence:^[23]

1. The Shopping Agent assembles open Mandate Contents and requests user approval via a Trusted Surface.
2. The Trusted Surface uses user_sk to sign and create open Checkout and open Payment Mandates. The hash of the open Checkout is included in the open Payment Mandate to permanently link them.^[23] The agent's public key is included as a cnf claim to sender-constrain Mandate usage.^[23]
3. The user leaves the session.
4. Later, the Shopping Agent autonomously assembles a Cart with the Merchant. The Merchant creates a signed Checkout (the merchant-signed checkout_jwt).
5. The Shopping Agent constructs Payment and Checkout Mandate Contents and signs both closed Mandates using agent_sk.^[23] The checkout_jwt hash is used to permanently link them; the sd_hash property of the kb-sd-jwt is used to bind the closed Mandate to the open one.^[23]
6. The Shopping Agent passes the Payment Mandates (open + closed) to the Credential Provider, who verifies them and creates a payment token.^[23]

The recommendation: "set the exp claim for these Mandates to the smallest value that will allow the Shopping Agent to complete the assigned task."^[17] Time-bounded delegation is the second cryptographic discipline AP2 puts under contract.

#6. The Validation Chasm

The chasm Sonnet & Prose called out — and AP2's verification rules implicitly encode — is between cryptographic proof and business authorization. A signature is verifiable. Authority is not. The cryptographic chain proves what was signed; it does not prove that the signer was allowed to sign it. A January 2026 arXiv red-teaming evaluation makes this concrete by demonstrating "Branded Whisper" and "Vault Whisper" indirect-prompt-injection attacks against an AP2-based shopping agent built on Gemini 2.5 + the Google ADK framework — mandates provided cryptographic guarantees over what was authorized, but the agent's interpretation of conversational context could still be steered to invoke them in unintended ways.^[24] Independent analyst commentary reaches the same conclusion from the security operations side: AP2 is not a "trust by default" switch, and runtime verification, prompt isolation, and explicit delegated-authority controls are mandatory for production-worthy use.^[25]

AP2's Merchant Verification rules make this explicit:^[11]

• The Checkout Mandate MUST be verified according to the Merchant Verification rules.
• The hash of the checkout_jwt MUST be independently computed from the included checkout_jwt.
• The Checkout Receipt reference MUST match the hash of the closed Checkout Mandate.
• The Payment Mandate MUST be verified according to the Merchant Payment Processor section using the checkout_hash from the Checkout Mandate.

These are cryptographic checks. None of them establish whether the Shopping Agent was authorized for this user, this amount, this merchant, today. That layer is policy, and policy lives outside the cryptographic chain.

The reference implementation makes the boundary explicit in its trust model: "Closed Mandates MUST contain the sd_hash claim to bind them to the presented open Mandate"^[22] is a cryptographic invariant. "Constraints in these Mandates allow the verifier to verify that the Checkout and Payment match the User's intent"^[11] is a policy check — and the verifier has to evaluate the constraints, not the protocol.

#7. Mandate Policy Engines: PEP / PDP separation

Sources note. PDP/OPA architectural patterns in this section draw heavily from two practitioner blogs (Tianpan Pan; Frank @ AppxLab). Treat the specific operational claims (sub-millisecond OPA latency, "80%+ HS256 default" estimates, OPA-as-sidecar topology) as illustrative architecture from individual practitioners rather than industry-validated consensus.

Outside the LLM, two architectural patterns have settled the policy-decision layer in 2026: in-process middleware and out-of-process policy services. The PEP/PDP split is older than agents — XACML, cloud IAM, Kubernetes admission controllers — but agents made the failure modes acute.

AWS Prescriptive Guidance for multi-tenant SaaS authorization frames OPA as the canonical PDP option (Cedar via Amazon Verified Permissions is the other), and explicitly recommends a centralized PDP with PEPs at every API endpoint as the baseline architecture.^[26] AWS additionally documents both a centralized-PDP and a distributed-PDP-with-policy-sync deployment topology, with the distributed pattern preferred for low-latency or partition-tolerant systems where every PDP must still produce identical decisions for identical inputs.^[27]

Independent definitions of the PDP role converge on the same shape: the PDP returns ALLOW/DENY plus obligations and metadata, and the PEP enforces the decision and any obligations it carries.^[28][29] CapiscIO's RFC-005 PDP Integration Profile formalizes the wire contract between PEPs and external PDPs: the PEP enforces fail-closed if the PDP cannot validate constraint-narrowing, which the RFC names as "the authority escalation guardrail" of the delegation model.^[30]

The shape, as articulated by Microsoft's Authorization Fabric team:^[4]

• Policy Enforcement Point (PEP): Gatekeeper invoked before any tool/action.
• Policy Decision Point (PDP): Evaluates RBAC + ABAC + approval policies.
• Decision output: ALLOW / DENY / REQUIRE_APPROVAL / MASK.

Microsoft's pattern requires the Authorization Fabric be a Microsoft Entra–protected endpoint on Azure Functions/App Service with built-in auth, "implemented as a Microsoft Entra-protected endpoint."^[4] Every agent (Copilot Studio or AI Foundry/Semantic Kernel) calls this fabric before tool execution; tools are invoked only after an ALLOW decision.^[4] Policies live in a central store (Cosmos DB or equivalent), not hardcoded in agents.^[4]

Cordum's analysis of in-process vs out-of-process governance frames the trust-boundary argument:^[5] "Compromise of the agent does not compromise the policy decision because the two live in separate trust boundaries."^[5] In-process governance — Microsoft AGT, Galileo Agent Control, APort's Open Agent Passport, NeMo Guardrails, Guardrails AI, most LangChain callbacks — runs the PEP and PDP in the same Python process as the agent.^[5] Cordum's Safety Kernel runs as a separate gRPC service behind mTLS; the agent calls it before dispatch and never sees the decision being made.^[5]

Open Policy Agent (OPA) is the CNCF-graduated general-purpose engine, with Rego as its policy language.^[31] Rego is declarative and supports rich data joins via OPAL; one practitioner write-up (Tianpan Pan) reports sub-millisecond decision latencies in colocated-sidecar deployments, though absolute numbers depend heavily on policy complexity and cache state.^[31] Zylos Research's recommended approach for Rust runtimes: compile OPA policies to WASM and execute them via wasmtime, eliminating network round-trips while preserving Rego's expressiveness.^[32]

The crucial discipline both Microsoft and Zylos call out is what they label the LLM-as-advisor-not-judge model:^[33] LLMs can enrich policy decisions with semantic classification (Category C — "must LLM" — for genuine ambiguity), but structured LLM output must always enter a deterministic decision function. The final ALLOW/DENY must always come from deterministic evaluation.^[33]

The settled architecture, per Tianpan Pan's April 2026 essay:^[31] "A user-initiated request enters the agent runtime carrying a session token. The runtime exchanges that token for a task-scoped capability token at the authorization server. The agent loop runs; before each tool call, the runtime calls the PDP (OPA, Cedar, or equivalent) with the principal, actor, tool, and arguments. The PDP returns allow/deny plus a reason... Decision logs from every PDP stream into the SIEM. The capability token expires when the task ends."^[31]

#8. Three decisive failure modes

Sonnet & Prose's review of the AP2 reference implementation surfaced three failure modes that even a correctly-specified protocol can produce in practice. Each maps to a place where the cryptographic chain interacts with the policy chain.

Failure mode 1: Symmetric signing. A naive HS256 implementation of the Checkout JWT — which, as documented by a single OPA-Rego practitioner blog, remains the default in a large share of legacy SaaS JWT pipelines^[31] — collapses the entropy property the AP2 specification depends on for checkout_hash. Anyone who sees the symmetric secret can forge JWTs and rainbow-table the hash. AP2's normative MUST against deterministic signatures^[9] is the cryptographic equivalent of this failure mode; the operational equivalent is failing to migrate existing JWT signing infrastructure when bolting on agent payments. Detection: any production deployment whose Checkout JWT carries "alg": "HS256" is non-conformant.

Failure mode 2: Orphan cart credentials. AP2's binding chain depends on the delegate_payload array linking open and closed Mandates by digest. If an Agent Provider issues a closed Mandate whose sd_hash references an open Mandate the verifier cannot resolve — because the open Mandate was never registered with the verifier or has expired — the closed Mandate becomes an orphan credential: cryptographically valid, but unverifiable. AP2 §Security and Privacy explicitly requires verifiers to reject any closed Mandate whose chain cannot be resolved to a known open Mandate.^[22] Operationally, this means a credential lifecycle management layer is required — not optional.

Failure mode 3: No revocation registry. AP2's normative MUSTs cover signing, hashing, and binding, but the specification does not yet mandate a revocation registry for compromised user keys or revoked Agent Provider attestations. GitHub issue #180 (March 17, 2026) on the AP2 repository proposes restricting IntentMandate visibility to the User ↔ Shopping Agent boundary, partly to bound the blast radius if a Shopping Agent is later found to have been compromised.^[7] Without revocation, a compromised Agent Provider key can sign closed Mandates against open Mandates that pre-date the compromise, and the cryptographic chain still validates. The settled-architecture answer (per the policy-engine literature) is short-lived task-scoped capability tokens that expire when the task ends — but the AP2 spec does not yet require this on its own. Independent practitioner analysis of the AP2 + x402 stack (the Cloud Security Alliance security review and follow-on commentary) reaches a complementary conclusion: AP2's Payment Mandate gives the network a signal that an AI agent acted, but actual chargeback and refund processes still run on existing card-scheme rules, and "there is no settled industry standard yet for how to handle 'the agent ordered the wrong thing.'"^[34]

#9. Compliance posture

The Trust Layer is not just an engineering pattern; it's an audit posture. Three regulatory frameworks now bear on the design.

EU AI Act. Frank's April 2026 IDP architecture survey identifies the eight requirements that affect platform architecture: documentation of AI system purpose, human oversight mechanisms, audit trail with timestamps, ability to shut down the system, deprovisioning evidence, access controls and least privilege, request-level events to immutable storage, and identity records for human accountability.^[35] Each maps to a specific PEP/PDP architectural decision: agent registration manifest, owner identity field, request-level events to immutable storage, kill switch + circuit breakers, expiry policy, GitOps commit trail.^[35]

NIST AI RMF. The reasoning-trace and decision-log requirements that fall out of the PEP/PDP architecture are the same artifacts NIST AI RMF expects for "manage-trace" controls: every PDP call emits a decision log capturing principal, tool, arguments (redacted appropriately), policy version, decision, and reason.^[31] Those logs stream into the SIEM as structured policy-refusal events distinct from model refusal events — a spike in the former is a prompt-probing signal worth investigating.^[31]

SOC 2 Type II for AI Agents. The forcing function for adoption of out-of-process governance is rarely the engineering team — "it is the audit conversation,"^[31] as Tianpan put it. A regulator or enterprise procurement security review asks: "Can you prove that your AI agent, when handling a Tier-2 customer's request on March 14th, did not access data outside that customer's tenant?"^[31] If the answer involves reading model logs and gesturing at the YAML manifest, it is not an answer. The answer that lands is "here is the policy decision log for every tool call in that session, signed and tamper-evident, showing the policy version evaluated, the inputs, and the deny-or-allow decision."^[31] That answer requires PDP-in-the-loop and structured decision logs streaming to the audit pipeline.

#10. The settled architecture, summarized

Putting the four layers together — Asymmetric Pivot, SD-JWT+KB, Mandate chain, PEP/PDP — produces the architecture B2A is converging on by mid-2026:

1. At enrollment: User provisions a hardware-backed key (user_sk); Agent Provider provisions agent keys (agent_sk). All keys are P-256 / ES256 capable.
2. At delegation (open): User signs open Checkout + open Payment Mandates with constraints, includes agent_pk in cnf claim, sets short exp.
3. At task time (closed): Agent receives merchant-signed checkout_jwt, signs closed Mandates with agent_sk, includes sd_hash and checkout_hash to chain to open Mandate and merchant Checkout.
4. At each tool call: Agent runtime PEP calls out-of-process PDP (OPA / Cedar / Authorization Fabric) with principal + actor + tool + args; PDP returns ALLOW/DENY/REQUIRE_APPROVAL/MASK.
5. At verification: Merchant + Credential Provider + Payment Processor each independently verify cryptographic chain and evaluate constraints.
6. At audit: PDP decision logs stream to SIEM; closed Mandates are stored with their open Mandates and Receipts as a tuple.

The architecture is not new — it borrows from XACML, OAuth2, and decade-old IAM literature — but the agent-payment vertical is the first place where the cryptographic, protocol, and policy layers are all in production at the same time.

#11. What this paper does not cover

This paper deliberately stops short of: the full details of the Universal Commerce Protocol (UCP) extension that places AP2 mandates inside checkout requests;^[12] the BBS+ anonymous-credential proposal in AP2 issue #120 for IntentMandate identity privacy;^[7] the OpenID4VP delegation flow for Agent-to-Agent mandate handoff (the AP2 spec marks Agent-to-Agent Delegation as outside the current spec scope);^[11] hardware-attestation strategies for user_sk key provisioning across iOS Secure Enclave, Android StrongBox, and TPM-backed Windows Hello; and the OWASP-mapped specifics of the 10 agentic AI risks Microsoft AGT addresses.^[35]

The next paper in this thread will dive into the revocation-registry gap — what a production-grade revocation surface would have to look like for AP2 to clear the SOC 2 Type II audit conversation cleanly — because that is the largest remaining cryptographic gap in the protocol as it stands.

#References