ACP Trust Mesh Integration

1. What ACP Is (and What It Is Not)

The $47,000 Saturday

A procurement agent running on ChatGPT via ACP purchased $47,000 in premium office furniture at 2:14 AM on a Saturday. The purchase was within the department's quarterly budget. The vendor was on the approved list. The Shared Payment Token was scoped correctly. ACP processed the transaction flawlessly.

On Monday morning, the department head calls finance: "I asked for desk chairs. Not a complete office renovation." Finance calls the merchant. The merchant says: "Your agent placed the order. We fulfilled it. Here is the ACP checkout record."

Finance now needs to answer three questions, and ACP cannot answer any of them:

1. What exactly did the employee authorize the agent to buy?
2. Why did the agent select this merchant and these specific products?
3. Was the agent operating within its authorized scope, or did it interpret "desk chairs" as "furnish the entire office"?

The merchant has a valid ACP transaction record. The employee has a vague recollection of a conversation with a chatbot. There is no independent record of what happened between those two points. That gap is what this guide closes.

The protocol

The Agentic Commerce Protocol (ACP) is an open standard (Apache 2.0) that defines how an AI agent completes a purchase on behalf of a user. Co-developed by OpenAI and Stripe, with Meta as the third steering committee member, the latest specification version is 2026-04-17.

ACP covers five core capabilities:

The merchant remains merchant of record and retains full control over acceptance, fulfillment, tax remittance, and returns. The payment plumbing is sound. ACP does what it set out to do.

What ACP does not solve

ACP made a deliberate architectural choice to focus on commerce semantics and leave accountability to other layers. This is a reasonable design decision: a payment protocol should not also be an audit protocol. But it means the following capabilities must come from somewhere else:

• Authorization proof. ACP assumes the user delegated authority to the agent, but the delegation is outside the protocol. There is no cryptographic proof that the user authorized this specific purchase at this specific amount from this specific merchant.
• Evaluation record. If an agent comparison-shops across five merchants, there is no record of the evaluation criteria, the alternatives considered, or why it chose this merchant.
• Tamper-evident audit trail. ACP requires audit logging but does not specify tamper-evidence. The logs are merchant-side and agent-side. Neither party has an independent witness.
• Regulatory accountability layer. When an AI agent makes a purchase that is later disputed, who produces the compliance evidence? This question falls outside ACP's scope.

2. The Governance Gap

The traditional four-party payment model (cardholder, issuer, acquirer, merchant) assumes human intent at the point of initiation. AI agents introduce a fifth participant that breaks this assumption. When a human clicks "purchase," the click itself is evidence of intent. When an AI agent initiates a checkout, the intent lives somewhere upstream: in a conversation, in a policy configuration, in a delegation chain that may span multiple agents. That upstream intent has no standard evidence format.

The economics of the gap

Industry projections place the agentic commerce market at $3 to $5 trillion globally by 2030. Visa charges merchants approximately $100 per chargeback. Mastercard is comparable. If an enterprise processes 10,000 agent-initiated transactions per month and even 2% are disputed, that is $20,000 per month in chargeback fees alone, before the cost of returns, restocking, and internal investigation hours. At scale, the absence of independent evidence is not an abstract governance concern. It is a line item.

Gap 1: Delegation without proof

A user tells ChatGPT "buy me running shoes under $150." The agent searches, selects, and checks out via ACP. Six months later, the user disputes the charge: "I never authorized that purchase." The merchant has an ACP checkout record showing the agent initiated the transaction. The merchant does not have cryptographic proof that the user authorized the agent to spend up to $150 on running shoes. The merchant bears the chargeback.

Gap 2: Opaque evaluation

The agent evaluated five merchants and selected Merchant C. Why? Was it price? Availability? Sponsored placement? If the agent selected a merchant because of an undisclosed commercial arrangement rather than user preference, that is a consumer protection issue under FTC Section 5. The evaluation criteria and the basis for merchant selection need to be recorded somewhere. ACP, by design, does not include this capability.

Gap 3: No independent witness

ACP checkout logs are produced by the parties to the transaction. The agent logs its own calls. The merchant logs its own receipts. In a dispute, both parties have logs, but neither log is independently verifiable. A log produced by a party to a dispute is an assertion. It is not evidence. The difference matters when a regulator or arbitrator asks for proof.

Gap 4: Liability without evidence

The merchant remains merchant of record under ACP. When an agent hallucination or scope violation causes a bad purchase, the merchant absorbs the chargeback and the return cost. The merchant has no protocol-level mechanism to prove that the agent exceeded its authorized scope, because ACP does not define scope boundaries. Conversely, the agent operator has no protocol-level mechanism to prove the agent stayed within scope. Both parties are exposed.

3. Trust Mesh Architecture

ACP is the highway. SWT3 is the dashcam. The merchant is the destination.

You do not need a dashcam to drive. The highway works without one. But when there is an accident and both parties tell different stories, the dashcam is the only thing that provides an independent record of what actually happened. It does not control the vehicle. It does not choose the route. It records.

That is the relationship between ACP and SWT3. ACP handles the commerce flow. SWT3 provides an independent accountability layer. The merchant handles fulfillment. Three systems, each with a distinct role, none replacing the other.

SWT3 does not sit between the agent and the merchant. It does not intercept, modify, or delay ACP API calls. It operates alongside the commerce flow as an independent recorder. The agent makes its ACP calls normally. Before and after key steps, the agent (or the merchant's backend) records a witness anchor that captures what happened, what was authorized, and whether constraints were respected.

The result: when a dispute arises, neither the agent's logs nor the merchant's logs are the deciding factor. An independent, tamper-evident record exists that both parties can reference and neither party can unilaterally modify. The dispute becomes a question of evidence, not assertions.

4. The Shopping Agent Pipeline

Consider an enterprise deploying a procurement agent that uses ACP to purchase office supplies, SaaS subscriptions, and equipment on behalf of employees. The agent operates as a four-stage pipeline:

  Attestation Fingerprints (individual witness records)
  +----------+ +----------+ +----------+ +----------+ +----------+ +----------+
  |AI-TOOL.1 | |NHI-AGT.1 | |AI-EXPL.1 | |NHI-SCP.1 | |AI-FIN.1  | |AI-CHAIN.1|
  |feed query| |agent id  | |eval crit | |scope chk | |txn auth  | |lifecycle |
  +----+-----+ +----+-----+ +----+-----+ +----+-----+ +----+-----+ +----+-----+
       |             |            |             |            |             |
       +------+------+            |             +------+-----+            |
              v                   v                    v                  v
  +-------------------+  +-------------------+  +------------------+  +------------------+
  | MS-product-search |  | MS-price-compare  |  | MS-compliance    |  | MS-checkout       |
  | Milestone Root    |  | Milestone Root    |  | Milestone Root   |  | Milestone Root    |
  +--------+----------+  +--------+----------+  +--------+---------+  +--------+----------+
           |                      |                       |                     |
           +----------+-----------+-----------+-----------+---------------------+
                                              v
                                  +------------------------+
                                  |  PH-procurement        |
                                  |  Phase Root            |
                                  |  "Purchase Pipeline"   |
                                  +-----------+------------+
                                              |
                                              v
                                  +------------------------+
                                  |  ST-order-2026-11-0847 |
                                  |  Structure Root        |
                                  |  "Purchase Order"      |
                                  +------------------------+

This architecture maps directly from the multi-agent phased witnessing pattern. Replace "loan underwriting agents" with "shopping agents" and the milestone structure is identical. The same SDK, the same phase gates, the same Merkle proof API.

5. Procedure Mapping

6. SDK Implementation

Basic: Wrap an ACP checkout in 20 lines

The simplest integration records the transaction authorization and the checkout completion. This is the minimum viable evidence chain for dispute defense.

from swt3_ai import Witness

witness = Witness(
    endpoint="https://your-tenant.example.com/api/v1/witness",
    api_key="axm_live_...",
    tenant_id="MERCHANT_ENCLAVE",
    agent_id="procurement-agent-v3.1",
    flush_interval=5,
    clearing_level=2    # L2: payment credentials involved
)

# Before ACP checkout: witness the authorization
witness.witness_transaction(
    amount_cents=14999,
    authorization_type="budget_limit",
    status="authorized",
    currency="USD",
    recipient_hash="sha256:merchant-C-id",
    purpose="office_supplies",
    transaction_ref="order-2026-11-0847"
)

# ... ACP checkout happens here (create session, receive SPT, pass to merchant) ...

# After ACP checkout: witness the completion
witness.witness_transaction(
    amount_cents=14999,
    authorization_type="budget_limit",
    status="completed",
    currency="USD",
    recipient_hash="sha256:merchant-C-id",
    purpose="office_supplies",
    transaction_ref="order-2026-11-0847"
)

Full pipeline: Four-agent milestone structure

For the complete multi-agent shopping pipeline with Merkle tree rollup and phase gates:

from swt3_ai import Witness
from swt3_ai.milestone_merkle import MilestoneAccumulator

# --- Step 1: Create the structure for this purchase order ---
order_id = "2026-11-0847"
acc = MilestoneAccumulator(structure_id=f"ST-order-{order_id}")

# One phase: the procurement pipeline
acc.add_phase("PH-procurement", "Procurement Pipeline", sequence=0)

# Four milestones, one per agent
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-price-compare", "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", "Checkout via ACP",
    required_procedures=["AI-FIN.1", "AI-CHAIN.1"],
    min_attestation_count=1
)

# --- Step 2: Agent 3 records scope check ---
compliance_witness = Witness(
    endpoint="https://your-tenant.example.com/api/v1/witness",
    api_key="axm_live_...",
    tenant_id="MERCHANT_ENCLAVE",
    agent_id="compliance-agent-v1.4",
    flush_interval=5,
    clearing_level=1
)

scope_result = compliance_witness.witness_nhi_scope(
    credential_id="procurement-agent-v3.1",
    scope="office_supplies:max_15000_usd:vendor_approved_list",
    ttl_seconds=3600
)
acc.add_leaf("MS-compliance", scope_result.fingerprint,
             "NHI-SCOPE.1", verdict="PASS")

# --- Step 3: Phase gate before checkout ---
gate = acc.check_gate("PH-procurement")
if not gate["passed"]:
    # Compliance failed: do NOT proceed to ACP checkout
    print(f"GATE_BLOCKED: {gate['failing_milestones']}")
    # The block is itself a witnessed event
else:
    # All clear: proceed with ACP checkout
    checkout_witness = Witness(
        endpoint="https://your-tenant.example.com/api/v1/witness",
        api_key="axm_live_...",
        tenant_id="MERCHANT_ENCLAVE",
        agent_id="checkout-agent-v2.0",
        flush_interval=5,
        clearing_level=2
    )
    txn_result = checkout_witness.witness_transaction(
        amount_cents=14999,
        authorization_type="budget_limit",
        status="authorized",
        currency="USD",
        purpose="office_supplies"
    )
    acc.add_leaf("MS-checkout", txn_result.fingerprint,
                 "AI-FIN.1", verdict="PASS")

TypeScript equivalent (basic checkout)

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

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

// Before ACP checkout
await witness.witnessTransaction({
  amountCents: 14999,
  authorizationType: "budget_limit",
  status: "authorized",
  currency: "USD",
  recipientHash: "sha256:merchant-C-id",
  purpose: "office_supplies",
  transactionRef: "order-2026-11-0847",
});

// ... ACP checkout flow ...

// After ACP checkout
await witness.witnessTransaction({
  amountCents: 14999,
  authorizationType: "budget_limit",
  status: "completed",
  currency: "USD",
  recipientHash: "sha256:merchant-C-id",
  purpose: "office_supplies",
  transactionRef: "order-2026-11-0847",
});

7. Dispute Resolution Evidence

Without independent evidence

A customer authorized their procurement agent to "buy office chairs under $300 each, from approved vendors only." The agent purchased four chairs at $289 each from Merchant D. Three months later, the customer disputes: "I only authorized one chair, and Merchant D is not on my approved list."

Without independent evidence, the dispute resolution process looks like this:

• The merchant pulls ACP checkout logs showing the transaction was initiated by the agent. The logs confirm the amount and the merchant ID. They say nothing about what the user authorized.
• The agent operator pulls conversation logs. The relevant conversation may have been pruned, summarized, or lost to context window rotation. Even if it exists, it is a text transcript, not cryptographic proof.
• The compliance team attempts to reconstruct the agent's evaluation process from application logs across four microservices. This requires engineering time, cross-team coordination, and weeks of calendar time.
• The outcome is uncertain. Both parties have their own logs. Neither log is independently verifiable. The merchant absorbs the chargeback.

With independent evidence

The same dispute. The dispute resolution team reconstructs the entire chain in four queries, in minutes:

Query 1: Get the structure. Retrieve the structure root for this purchase order. This returns the phase root, all four milestone roots, and the gate status. The structure shows the compliance gate passed before checkout was permitted.

Query 2: Expand the compliance milestone. The scope boundary attestation shows the authorized scope at the time of purchase: "office chairs, up to $30,000 total, vendor list version 7." The transaction attestation shows the total amount ($1,156) and the authorization type (budget limit). Merchant D was on vendor list v7 when the purchase occurred.

Query 3: Expand the evaluation milestone. The explainability attestation shows the agent evaluated Merchants A through E. Merchant D offered the lowest per-unit price with in-stock availability and 2-day shipping. Merchants A and B were cheaper but out of stock. Merchant C was on the approved list but $40/unit more expensive.

Query 4: Verify the agent identity. The agent identity attestation confirms agent version 3.1.0 with a signing key that matches the deployment record. No version change occurred between the purchase and the dispute.

Outcome: the evidence chain proves the purchase was authorized (quantity was within the budget scope), Merchant D was on the approved vendor list at the time of purchase, and the agent selected Merchant D based on documented criteria. The dispute is resolved in minutes. The merchant does not absorb the chargeback.

What an attestation record looks like

For assessors and dispute teams unfamiliar with the evidence format, here is what the scope boundary attestation for the purchase above would look like in the ledger:

  Procedure:     NHI-SCOPE.1 (Scope Boundary Attestation)
  Verdict:       PASS
  Timestamp:     2026-11-09T02:14:07Z
  Milestone:     MS-compliance
  Structure:     ST-order-2026-11-0847

  Factors:
    Credential:  procurement-agent-v3.1
    Scope:       office_chairs:max_30000_usd:vendor_list_v7
    TTL:         3600 seconds (authorization window)

  Anchor:        SWT3-E-CLOUD-NHI-NHISCOPE1-PASS-1762646047-a8f3c21d9e04

Every attestation in the evidence chain follows this structure: a procedure, a verdict, a timestamp, the milestone it belongs to, the computational factors, and a tamper-evident anchor. The anchor can be verified independently without access to the original system.

The reverse: when the agent genuinely violated scope

Now consider the opposite scenario. The same employee authorized "desk chairs under $500 total." The agent purchased $47,000 in premium furniture. With independent evidence, the scope boundary attestation shows the authorized scope was "$500 total, desk chairs only." The transaction attestation shows $47,000. The scope violation is cryptographically provable.

This matters equally for the agent operator. Without independent evidence, the operator has no way to prove the violation was a legitimate agent malfunction rather than an employee attempting to use the agent as a backdoor for unauthorized spending. With scope attestation, the violation is documented, the timeline is clear, and liability can be attributed to the correct party.

When the gate blocks the purchase

The most important scenario may be the one where nothing was purchased at all. The compliance check agent detects that the selected vendor is not on the approved list. The phase gate blocks the checkout agent from executing. The agent cannot proceed to ACP checkout because the compliance milestone has a failing attestation.

The blocked gate is itself a witnessed event. The structure contains the compliance failure record, the reason for the block, and the timestamp. If the employee later claims "I tried to buy supplies and the system would not let me," the evidence shows exactly what happened: the agent found the right product, the vendor was not approved, and the system correctly prevented the purchase. Governance worked. The proof that it worked is in the evidence chain.

8. Clearing Levels for Commerce Data

ACP transactions involve data at varying sensitivity levels. The clearing level determines what evidence depth is required and how factors are stored.

The Shared Payment Token (SPT) itself is L2 minimum: it is scoped to a specific merchant and cart total, and its existence proves that Stripe authorized a payment delegation for this transaction. Any attestation that references SPT data must use clearing level 2 or higher.

9. Regulatory Mapping

Agentic commerce sits at the intersection of multiple regulatory frameworks. This table maps the key requirements to SWT3 procedures and the milestones in the shopping agent pipeline.

Each row maps to a specific leaf in the Merkle tree. For detailed regulatory analysis, see the dedicated guides: Agentic Commerce Compliance covers the full regulatory landscape, and Agentic Payment Protocol Crosswalk maps Visa TAP, Mastercard Agent Pay, and Stripe MPP to SWT3 procedures.

10. What SWT3 Does Not Do

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

• SWT3 does not process payments. ACP and Stripe handle payment delegation, SPT issuance, and merchant settlement. SWT3 records that these events occurred; it does not participate in the payment flow.
• SWT3 does not replace ACP. This is a Trust Mesh integration. ACP defines the commerce semantics. SWT3 provides the independent accountability layer. 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 witnesses the enforcement, it does not perform it.
• 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 attestations operate at the governance layer, above the payment security layer.
• 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.

11. What This Means for Your Organization

ACP solves a real problem: it gives AI agents a standardized way to buy things. That problem is now solved. The next problem is different.

The next problem is: when something goes wrong with an agent-initiated purchase, who proves what happened?

Today, the answer is "nobody, definitively." The agent has its logs. The merchant has its logs. Neither set of logs is independently verifiable. In a dispute, the party with better lawyers wins, not the party with better evidence, because neither party has evidence in the cryptographic sense of the word.

Independent witnessing changes the nature of that conversation. It does not make disputes impossible. It makes disputes resolvable. The authorization scope is recorded before the purchase. The evaluation criteria are recorded during merchant selection. The scope boundaries are checked before checkout. The lifecycle chain links every step to a single, tamper-evident root.

When a dispute arises, the question is no longer "what do your logs say?" It is "what does the independent record show?"

That single shift, from assertions to evidence, is the difference between an agent commerce program that scales with growing legal exposure and one that scales with growing confidence. ACP built the commerce layer. The accountability layer is the next piece of infrastructure. This guide shows one way to build it.

12. References

• Agentic Commerce Compliance Guide -- regulatory landscape for AI agent transactions (PSD2, SR 11-7, CFPB, EU AI Act)
• AP2 Trust Mesh Integration Guide -- independent execution evidence for FIDO Alliance Agent Payments Protocol
• 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
• Phased Process Witnessing Guide -- hierarchical Merkle trees for physical and digital process integrity
• SR 11-7 Compliance Overlay -- model risk management for AI systems in financial services
• CFPB AI Underwriting Crosswalk -- adverse action and fair lending evidence for AI credit decisions
• SWT3 SDK Documentation -- full API reference (Python, TypeScript, and 7 additional languages)
• SWT3 UCT Registry -- 294 procedures across 10 namespaces
• Agentic Commerce Protocol specification (v2026-04-17) -- github.com/agentic-commerce-protocol
• Stripe: "Stripe and OpenAI introduce instant checkout in ChatGPT" -- stripe.com/newsroom