AP2 Trust Mesh Integration

1. The Missing Half of the Receipt

An enterprise procurement agent operating in AP2's "Human Not Present" mode executes a $23,000 purchase at 3:07 AM on a Tuesday. The Intent Mandate is valid: price cap $25,000, category "IT equipment," vendor allowlist active, TTL within window. The mandate signatures verify. The Checkout Receipt confirms the merchant accepted the order. AP2 processed the transaction exactly as designed.

Six weeks later, the CFO reviews the quarterly spend report. The line item reads "cryptocurrency mining hardware." The CFO calls procurement: "We authorized servers. Not mining rigs."

Procurement checks the AP2 mandate. The mandate says "IT equipment under $25,000." Mining rigs are technically IT equipment. The amount was under the cap. The mandate was valid. AP2 did its job.

But nobody can answer the question that matters: why did the agent classify mining rigs as IT equipment, and what alternatives did it evaluate before making that classification?

The mandate proves authorization. It does not record execution. The authorization is half of the receipt. The execution record is the other half. This guide builds the other half.

2. What AP2 Is (and What It Has Already Solved)

The Agent Payments Protocol (AP2) is an open standard that provides cryptographic authorization proof for agent-initiated transactions. Originally created by Google, AP2 was donated to the FIDO Alliance in April 2026, where it is governed under the same neutral, multi-stakeholder model that produced WebAuthn. Mastercard contributed a complementary standard called Verifiable Intent alongside the donation. The partner ecosystem includes over 100 organizations: Mastercard, PayPal, Coinbase, Adyen, American Express, JCB, Etsy, Shopee, Salesforce, Intuit, and Okta, among others.

AP2 made a deliberate architectural choice to build authorization proof directly into the protocol layer. This is a significant investment that changes the compliance conversation for organizations in the AP2 ecosystem.

Mandates: cryptographic authorization proof

The core mechanism is the mandate: a cryptographically signed credential structured as a W3C Verifiable Credential using SD-JWT with key binding (SD-JWT+kb) and ECDSA P-256 signatures. AP2 defines two mandate types, each with an open and closed variant:

Each mandate includes timestamps, nonces, signer public key references, and detached JWS signatures over JSON-canonicalized payloads. The merchant reciprocates with its own merchant_authorization signature, creating bilateral cryptographic verification.

Two operational modes

Human Present (HP): The user is actively interacting with the agent. The user signs the Checkout Mandate via a Trusted Surface (a non-agentic UI component that AP2 requires for capturing user consent). Real-time authorization.

Human Not Present (HNP): The user has pre-authorized the agent with an open Checkout Mandate containing constraints (price cap, category, vendor list, time window). The agent executes autonomously when conditions are met. This is the mode that enables 3 AM procurement purchases, limited-availability item acquisition, and high-frequency automated purchasing.

Receipts and hash binding

AP2 produces two receipt types: the Checkout Receipt (returned by the merchant after accepting or rejecting the mandate) and the Payment Receipt (returned by the payment processor). Each receipt contains a reference field that cryptographically binds it to the corresponding mandate via hash matching. This creates a verifiable chain from authorization to acceptance.

Verifiable Intent (Mastercard)

Contributed alongside AP2 to the FIDO Alliance, Verifiable Intent creates tamper-proof audit trails using selective disclosure. Each transaction participant receives only the minimum information necessary for their role. A merchant sees the authorization scope but not the user's full identity. A payment processor sees the payment details but not the cart contents. This selective disclosure model maps directly to data classification requirements in regulated environments.

Trusted Surface

AP2 requires that user consent is captured via a "Trusted Surface" that must be non-agentic. The mandate signing environment cannot itself be an AI agent. This is a sound architectural constraint: the authorization origin must be demonstrably human-controlled, even when the execution that follows is fully autonomous.

3. The Execution Gap

AP2's authorization proof is a substantial achievement. It is important to recognize what it has solved before discussing what remains. The mandate proves that a specific user authorized a specific scope of spending through a specific agent. That authorization is cryptographically signed, tamper-evident, and independently verifiable. This is more governance infrastructure than most payment protocols provide.

The execution gap is a different problem. It is not about what the user authorized. It is about what the agent did with that authorization.

Gap 1: Authorization constrains outcomes, not process

The mandate proves the user authorized "IT equipment under $25,000." It does not prove what the agent classified as IT equipment, why it chose this vendor over alternatives, or what evaluation criteria it applied. The mandate constrains the outcome. It does not record the process that led to that outcome. In the mining rig scenario, the mandate was technically valid. The classification decision that turned "servers" into "mining rigs" is not in the mandate.

Gap 2: Agent evaluation criteria are outside the mandate

AP2 mandates capture what was authorized, not how the agent decided to exercise that authorization. If the agent evaluated eight vendors, compared prices, checked availability, and selected Vendor D based on a combination of price and shipping speed, that evaluation process is not part of the AP2 evidence chain. For disputes where the user claims the agent made a poor selection within its authorized scope, the mandate alone cannot resolve the question.

Gap 3: All mandate signers are transaction participants

AP2 mandates and receipts are signed by the parties to the transaction. The agent signs. The merchant signs. The credential provider signs. All participants are parties to the transaction with an interest in the outcome. None is an independent witness to the agent's execution process. The mandate chain is self-attested evidence. It is strong evidence (cryptographically signed, tamper-evident), but it is not independent evidence.

Gap 4: Audit retrieval is explicitly out of scope

The AP2 specification acknowledges this directly: "Providing an automated method to retrieve the Checkout Mandate...would provide substantial utility to the ecosystem. The exact details are outside the scope of the current version." The mandate exists, but the infrastructure to query, retrieve, and correlate mandates across transactions at audit time is left to implementers.

Gap 5: Agent-to-agent delegation is not covered

AP2 explicitly notes that delegation between agents is "outside the scope of the current specification." A multi-agent procurement pipeline where a search agent delegates to a comparison agent, which delegates to a compliance agent, which delegates to a checkout agent, has no mandate chain linking those delegation steps. Each agent operates within the scope of the original mandate, but the inter-agent handoffs are unwitnessed.

The economics

AP2's mandate reduces the rate of disputes. Authorization proof means fewer "I never authorized that" claims succeed. But when a dispute does occur within a technically valid mandate scope (the mining rig scenario), the absence of execution evidence means the dispute is unresolvable on its merits. Independent execution evidence reduces the cost of each dispute by making resolution faster and more definitive.

4. Trust Mesh Architecture: Mandate + Execution Record

AP2 is the signed work order. SWT3 is the job site camera. The payment rail is the bank transfer.

The work order proves you authorized the contractor to renovate the kitchen for up to $30,000. The camera records what the contractor actually did: which materials were used, which subcontractors were on site, whether the work matched the scope. When the result does not match the work order, the camera footage is the evidence that resolves the dispute. Neither the work order nor the camera is sufficient alone. Together they provide the complete accountability record.

AP2 proves: "The user authorized this." SWT3 records: "Here is what the agent did with that authorization." Together: the full accountability loop from user intent to agent execution to merchant fulfillment.

SWT3 does not sit between the agent and the AP2 infrastructure. It does not intercept mandates, modify receipts, or delay the checkout flow. It operates alongside the AP2 authorization chain as an independent execution recorder. The agent submits its mandates normally. Before and after key execution steps, the system records what happened, what was evaluated, and whether the agent's behavior matched the mandate's constraints.

5. The Procurement Agent Pipeline

The same four-agent procurement pipeline from the ACP Trust Mesh guide, but with AP2 mandates providing the authorization layer. The critical difference: AP2 already covers authorization (the mandate). SWT3 covers what happens between authorization and checkout.

                    AP2 Mandate Chain                    SWT3 Execution Evidence
                    ================                     =======================

  Intent Mandate ----[ constraints ]                     AI-TOOL.1   (search queries)
  (open Checkout)    price, category,                    NHI-AGENT.1 (agent identity)
                     vendor list                                |
                         |                               AI-EXPL.1   (evaluation criteria)
                         |                               * THE PRIMARY GAP *
                         |                                       |
                         v                               NHI-SCOPE.1 (enforcement record)
  Cart Mandate -----[ specific items ]                   AI-FIN.1    (transaction details)
  (closed Checkout)  vendor D, $23,000                           |
                         |                               AI-CHAIN.1  (lifecycle chain)
                         v                                       |
  Payment Mandate --[ payment auth ]                             v
                         |                               Structure Root (one hash,
                         v                                entire purchase decision)
  Checkout Receipt -[ merchant accepts ]
  Payment Receipt --[ payment settles ]

6. Procedure Mapping

7. SDK Implementation

Basic: Witness execution around AP2 mandate submission

The simplest integration records the transaction execution before and after the AP2 mandate submission. This is the minimum viable execution evidence.

from swt3_ai import Witness

witness = Witness(
    endpoint="https://your-tenant.example.com/api/v1/witness",
    api_key="axm_live_...",
    tenant_id="PROCUREMENT_ENCLAVE",
    agent_id="checkout-agent-v2.3",
    flush_interval=5,
    clearing_level=2    # L2: payment data involved
)

# Before AP2 mandate submission: record what the agent is about to do
witness.witness_transaction(
    amount_cents=2300000,
    authorization_type="budget_limit",
    status="authorized",
    currency="USD",
    purpose="it_equipment_servers",
    transaction_ref="PO-2026-11-0293"
)

# ... AP2 mandate submission happens here ...
# ... Agent submits Checkout Mandate + Payment Mandate ...
# ... Merchant returns Checkout Receipt ...

# After AP2 checkout: record the completed execution
witness.witness_transaction(
    amount_cents=2300000,
    authorization_type="budget_limit",
    status="completed",
    currency="USD",
    purpose="it_equipment_servers",
    transaction_ref="PO-2026-11-0293"
)

Full pipeline: Four-agent milestone structure

from swt3_ai import Witness
from swt3_ai.milestone_merkle import MilestoneAccumulator

order_id = "PO-2026-11-0293"
acc = MilestoneAccumulator(structure_id=f"ST-order-{order_id}")

acc.add_phase("PH-procurement", "Procurement Pipeline", sequence=0)

acc.add_milestone(
    "MS-product-search", "PH-procurement", "Product Search",
    required_procedures=["AI-TOOL.1", "NHI-AGENT.1"],
    min_attestation_count=1
)
acc.add_milestone(
    "MS-evaluation", "PH-procurement", "Price Comparison",
    required_procedures=["AI-EXPL.1"],
    min_attestation_count=1
)
acc.add_milestone(
    "MS-compliance", "PH-procurement", "Compliance Check",
    required_procedures=["NHI-SCOPE.1", "AI-FIN.1"],
    min_attestation_count=1
)
acc.add_milestone(
    "MS-checkout", "PH-procurement", "AP2 Checkout",
    required_procedures=["AI-FIN.1", "AI-CHAIN.1"],
    min_attestation_count=1
)

# Phase gate: block AP2 checkout if compliance fails
gate = acc.check_gate("PH-procurement")
if not gate["passed"]:
    # Compliance milestone has a failing attestation
    # The agent CANNOT submit the AP2 mandate
    # The gate block is itself a witnessed event
    pass

TypeScript equivalent (basic)

import { Witness } from "@tenova/swt3-ai";

const witness = new Witness({
  endpoint: "https://your-tenant.example.com/api/v1/witness",
  apiKey: "axm_live_...",
  tenantId: "PROCUREMENT_ENCLAVE",
  agentId: "checkout-agent-v2.3",
  flushInterval: 5,
  clearingLevel: 2,
});

// Before AP2 mandate submission
await witness.witnessTransaction({
  amountCents: 2300000,
  authorizationType: "budget_limit",
  status: "authorized",
  currency: "USD",
  purpose: "it_equipment_servers",
  transactionRef: "PO-2026-11-0293",
});

// ... AP2 mandate submission + receipt collection ...

// After AP2 checkout completes
await witness.witnessTransaction({
  amountCents: 2300000,
  authorizationType: "budget_limit",
  status: "completed",
  currency: "USD",
  purpose: "it_equipment_servers",
  transactionRef: "PO-2026-11-0293",
});

8. Dispute Resolution: Mandate + Execution Evidence

Without execution evidence

The CFO disputes the $23,000 mining rig purchase. The investigation proceeds:

• The AP2 mandate is retrieved. The Intent Mandate shows: category "IT equipment," price cap $25,000, vendor allowlist active. The mandate is valid.
• The Checkout Receipt confirms the merchant accepted the order. The Payment Receipt confirms settlement.
• The mandate chain is complete and cryptographically sound. Every signature verifies. Every hash matches.
• The question "why did the agent classify mining rigs as IT equipment?" cannot be answered from the mandate chain. The mandate authorized IT equipment. The agent delivered IT equipment (by its own classification). The gap between authorization and execution is undocumented.

With execution evidence

The same dispute. The investigation now has both the mandate chain and the execution evidence:

Query 1: Get the structure. Retrieve the structure root for this purchase order. The AP2 mandate hash is correlated with the execution chain. The compliance gate shows PASSED.

Query 2: Expand the evaluation milestone. The evaluation attestation shows the agent searched 8 vendor catalogs, identified 12 matching products across 5 vendors, and selected Vendor D's product. The evaluation criteria: lowest per-unit cost with in-stock availability and next-day shipping. The product was categorized as "IT equipment" based on the vendor's catalog classification, not on the agent's own analysis of the hardware's intended purpose.

Query 3: Expand the compliance milestone. The scope attestation shows the agent checked the product category against the Intent Mandate constraint. It matched "IT equipment" because the vendor classified the product under "Computing Hardware > Specialized Processing." The agent did not independently verify the product's intended use case.

Outcome: The execution evidence reveals the root cause. The agent relied on the vendor's product classification rather than analyzing the hardware's intended purpose. The mandate was technically valid. The agent's interpretation was reasonable given the vendor classification but failed to account for the difference between "specialized processing hardware" (vendor's term) and "servers" (the CFO's intent). The evidence supports a policy update requiring the agent to verify product use cases, not just vendor categories, for purchases above a threshold.

The reverse: mandate + execution evidence prove compliance

A different procurement agent makes a $19,000 purchase of rack-mount servers. Three months later, an auditor questions the purchase. The AP2 mandate shows "IT equipment under $25,000." The evaluation attestation shows the agent compared 6 vendors, selected the lowest-cost option that met the performance specification, and verified the product was classified as "Server > Rack Mount" in both the vendor catalog and the organization's asset taxonomy. The scope attestation confirms the vendor was on version 8 of the approved list. The lifecycle chain links every step.

Mandate + execution evidence together prove compliance definitively. The auditor's question is answered in minutes.

When the gate blocks the purchase

The compliance agent detects that the selected vendor was removed from the approved list in yesterday's update. The phase gate blocks the checkout agent from submitting the AP2 mandate. The gate block is itself a witnessed event: the structure contains the compliance failure, the specific reason (vendor removed from allowlist v9), and the timestamp. The AP2 mandate was never submitted. The evidence chain proves governance prevented an unauthorized purchase.

  Procedure:     AI-EXPL.1 (Evaluation Criteria Record)
  Verdict:       PASS
  Timestamp:     2026-11-12T03:07:14Z
  Milestone:     MS-evaluation
  Structure:     ST-order-PO-2026-11-0293

  Factors:
    Vendors evaluated:    8
    Products compared:    12
    Selection criteria:   lowest_cost + in_stock + next_day_shipping
    Selected vendor:      Vendor D (catalog category: Computing Hardware)

  Anchor:        SWT3-E-CLOUD-AI-AIEXPL1-PASS-1762855634-c4e8a1f30b72

9. Coverage Matrix: Where AP2 and SWT3 Overlap

AP2 and SWT3 are complementary layers. Some evidence needs are covered by AP2 alone, some by SWT3 alone, and some benefit from both.

The coverage matrix shows that AP2 and SWT3 have minimal overlap and significant complementarity. AP2 excels at authorization proof and bilateral verification. SWT3 excels at execution evidence, independent witnessing, and cross-agent lifecycle chains. Neither layer duplicates the other's primary function.

10. Regulatory Mapping

AP2's mandate structure changes the regulatory evidence picture compared to protocols without authorization proof. The table below shows where AP2 mandates provide evidence, where execution evidence is needed, and which SWT3 procedures fill the remaining gaps.

For detailed regulatory analysis, see the dedicated guides: Agentic Commerce Compliance covers the full regulatory landscape, and Agentic Payment Protocol Crosswalk maps AP2, Visa TAP, Mastercard Agent Pay, and Stripe MPP to SWT3 procedures.

11. Clearing Levels for AP2 Commerce Data

AP2 transactions involve data at varying sensitivity levels. AP2's selective disclosure model (Verifiable Intent) means different participants see different data, which aligns with clearing level classification.

AP2's support for stablecoin settlement via the x402 extension introduces additional clearing considerations. Stablecoin transactions may trigger money transmission and sanctions screening requirements that do not apply to traditional card payments. Attestations touching stablecoin settlement data should use L3 clearing.

12. What SWT3 Does Not Do

Honest scope is essential for trust. SWT3 is an independent witness protocol. It is not a mandate issuer, a payment system, or a security product.

• SWT3 does not issue mandates. AP2 handles mandate creation, signing, and verification. SWT3 records what happened after the mandate was issued.
• SWT3 does not replace AP2. These are complementary layers solving different problems. AP2 provides authorization proof. SWT3 provides execution evidence. Neither is a substitute for the other.
• SWT3 does not enforce spending limits. It records whether the operator's system reported a scope boundary as respected or violated. Enforcement is the deployer's responsibility. SWT3 records the enforcement, it does not perform it.
• SWT3 does not replace the Trusted Surface. AP2's requirement that user consent be captured via a non-agentic Trusted Surface is a sound design decision. SWT3 does not provide or substitute for this consent mechanism.
• SWT3 does not handle PCI compliance. PCI DSS scope, cardholder data handling, and payment security remain the responsibility of the merchant and payment processor.
• SWT3 does not guarantee regulatory approval. Witness anchors provide cryptographic evidence of AI system behavior. They do not replace assessor judgment, legal analysis, or regulatory certification processes.

13. What This Means for Your Organization

AP2 built authorization proof directly into the protocol layer. That is a significant architectural investment, and it changes the compliance conversation for every organization in the AP2 ecosystem. The mandate chain provides cryptographic evidence that the user authorized the agent to act within a defined scope. For authorization disputes ("I never authorized that"), the mandate is the answer.

The next question is different. It is not "was the agent authorized?" It is "what did the agent do with that authorization?"

The mandate proves the user said "buy IT equipment under $25,000." The execution record proves the agent searched 8 vendors, evaluated 12 products, classified mining rigs as IT equipment based on a vendor catalog category, and submitted the checkout at 3:07 AM. When the mandate is technically valid but the execution was flawed, the execution record is the evidence that identifies the root cause and resolves the dispute.

AP2 built the authorization layer. The execution evidence layer is the complementary piece of infrastructure. The mandate is half of the receipt. This guide shows how to build the other half.

14. References

• ACP Trust Mesh Integration Guide -- independent audit trail for OpenAI/Stripe Agentic Commerce Protocol
• Agentic Commerce Compliance Guide -- regulatory landscape for AI agent transactions
• Agentic Payment Protocol Crosswalk -- Visa TAP, Mastercard Agent Pay, Stripe MPP, and AP2 mapped to SWT3 procedures
• Multi-Agent Phased Witnessing Guide -- milestone Merkle tree architecture for multi-agent pipelines
• SR 11-7 Compliance Overlay -- model risk management for AI systems in financial services
• SWT3 SDK Documentation -- full API reference (Python, TypeScript, and 7 additional languages)
• SWT3 UCT Registry -- 294 procedures across 10 namespaces
• AP2 specification -- ap2-protocol.org
• FIDO Alliance: Agentic Authentication and Payments Working Groups -- fidoalliance.org
• Google: "Announcing Agent Payments Protocol (AP2)" -- cloud.google.com/blog