Skip to content

Transparent Gateway Profile

A deployment pattern for adopting MPCP without requiring SDK integration on either side of a payment.

Motivation

Integrating MPCP natively requires effort on both sides of every payment:

  • Budget owner side: run a Policy Authority server, publish policies, issue PolicyGrants, and integrate the gateway client into the spending agent
  • Merchant side: integrate the merchant-sdk, accept SBA artifacts, and verify the authorization chain

This friction is the right design for deployments that need end-to-end cryptographic verification — fleet vehicles, embedded devices, or AI agents operating across many independent merchants with no pre-existing trust relationship.

But many deployments don't need this from day one. A startup processing AI agent payments, a travel platform delegating spend to an LLM, or an enterprise deploying autonomous purchasing agents may want to:

  • Enforce budget limits and purpose constraints on an AI agent
  • Let humans cancel a delegation mid-flight
  • Get an audit trail of what was spent and why

…without asking every merchant to adopt a new SDK, and without requiring the budget owner to run server infrastructure.

The Transparent Gateway pattern solves this. It sits between the budget owner and the merchant, implementing MPCP internally while exposing simple, familiar interfaces on both sides.

Overview

Budget Owner
  │  authorizes gateway with spending constraints
  │  (no SDK, no PA server — just a configuration call)
  ▼
┌──────────────────────────────────────────────────┐
│             MPCP Transparent Gateway              │
│                                                   │
│   PA server (internal)  →  Wallet Session         │
│   PolicyGrant issuance      per-payment SBAs      │
│   revocation tracking       budget enforcement    │
│   audit log                 purpose filtering     │
└──────────────────────────┬───────────────────────┘
                           │  x402 / standard payment protocol
                           ▼
                        Merchant
                   (no MPCP knowledge required)

The gateway runs the full MPCP stack internally — MPCP v1 settlement is XRPL-only (conforming PolicyGrants use allowedRails: ["xrpl"], authorizedGateway, and velocityLimit). Outward-facing APIs (e.g. x402, card rails) are adapter layers; they do not define alternate MPCP settlement rails. Externally it presents:

  • Inward (budget owner → gateway): a lightweight session configuration API
  • Outward (gateway → merchant): a standard payment protocol such as x402

When to Use This Profile

Use the Transparent Gateway profile when:

  • You want MPCP budget enforcement and audit without requiring merchant SDK integration
  • You are in an early adoption phase and cannot mandate MPCP on both sides simultaneously
  • The budget owner does not want to operate their own PA server (consumer apps, SaaS products delegating to a hosted gateway)
  • You need a migration path toward native MPCP as merchant adoption grows
  • Merchants already accept a standard payment protocol (x402, Stripe, etc.) and must not be disrupted

Do not use this profile when:

  • Merchants must independently verify the full authorization chain without trusting an intermediary
  • The deployment is adversarial (the gateway itself is untrusted by one or both parties)
  • Cryptographic proof of policy compliance must flow unbroken from budget owner to merchant

For those requirements, use native MPCP with the Human-Agent Profile.

Trust Model

The gateway shifts trust compared to native MPCP:

Property Native MPCP Transparent Gateway
Budget ceiling enforced ✓ agent-enforced (SBA independently verifiable) ✓ gateway-enforced internally
Purpose filtering ✓ agent + gateway-enforced (PA-signed allowedPurposes) ✓ gateway-enforced internally
Destination enforcement ✓ agent + gateway-enforced (PA-signed destinationAllowlist + XRPL Credentials) ✓ gateway-enforced internally
Revocation by budget owner ✓ ✓ gateway checks endpoint
Cumulative spend tracking ✓ ✓ inside gateway
Merchant verifies chain independently ✓ ✗ merchant trusts gateway
Merchant needs MPCP SDK required not required
Budget owner needs own PA server required not required (gateway hosts it)
End-to-end cryptographic audit ✓ gateway receipts only

The key trade-off: merchants trust the gateway for payment validity rather than the cryptographic artifact chain. This is the same trust model as traditional payment processors (Visa, Stripe) and is commercially accepted in nearly all existing commerce.

The budget owner retains meaningful control:

  • Spending ceiling is enforced by the gateway before any payment is executed
  • Purposes are filtered by the gateway before any x402 request is sent
  • The budget owner can revoke at any time via the gateway's session API
  • The gateway produces per-payment receipts the budget owner can audit

Interfaces

Budget Owner → Gateway (Session Configuration)

The budget owner creates a gateway session specifying the spending constraints. No PolicyGrant signing, no private key management.

POST /sessions
{
  "budget":    { "amount": "80000", "currency": "USD" },
  "purposes":  ["travel:hotel", "travel:flight", "travel:transport"],
  "expiresAt": "2026-04-13T00:00:00Z",
  "label":     "Alice Paris trip"
}

→ { "sessionToken": "gw_sess_abc123...", "sessionId": "...", "revocationUrl": "..." }

The sessionToken is passed to the AI agent or autonomous process. The gateway revokes the session on DELETE /sessions/{id} or when expiresAt is reached.

budget.amount is the spending ceiling expressed in the currency's minor units (e.g. "80000" = $800.00 USD). Note that the per-payment receipt uses the field name amountMinor for the same concept — these are two distinct schema fields at different layers of the gateway API.

Agent → Gateway (forwarding)

The AI agent attaches the sessionToken as a Bearer token and sends its outbound requests through the gateway's forwarding endpoint (POST /proxy and X-Target-Url below are illustrative; implementations may use any endpoint and header scheme):

POST /proxy
Authorization: Bearer gw_sess_abc123...
X-Target-Url: https://hotel.example.com/book
Content-Type: application/json
{ ... booking payload ... }

The gateway makes the outbound request on behalf of the agent, handles any 402 response transparently (checking the session, paying, retrying), and returns the final merchant response to the agent. The agent receives a normal HTTP response and does not observe the payment exchange.

For embedded agents or SDKs, the forwarding step can alternatively be implemented as an HTTP proxy (CONNECT/HTTP_PROXY style), so the agent needs no code changes beyond pointing its HTTP client at the gateway host.

Gateway → Merchant (standard payment protocol)

The gateway speaks x402 on the outbound side by default. When the agent (via the gateway) makes an HTTP request to a merchant endpoint:

1. Agent makes request
2. Merchant returns:
      HTTP 402 Payment Required
      X-Payment: { "amount": "18000", "currency": "USD", "address": "..." }

3. Gateway checks internal MPCP session:
   - purpose allowed? ✓
   - $180 fits within remaining budget? ✓
   - grant not revoked? ✓

4. Gateway executes payment, retries with receipt:
      X-Payment-Receipt: "txid:..."

5. Merchant serves the resource. No MPCP artifact seen.

The gateway may also speak other outbound protocols (Stripe, direct bank transfer, stablecoin rails) depending on what the merchant accepts. x402 is preferred for machine-to-machine flows because its 402 response carries machine-readable payment terms that map directly onto MPCP's authorization model.

Internal Architecture

The gateway implements these MPCP components internally, invisible to both sides:

Policy Authority (internal)

When a budget owner creates a session, the gateway mints a PolicyGrant from the session parameters and stores it internally. No external PA server is required.

PA signing key separation (SHOULD — SECOP 7a): The key that signs PolicyGrants SHOULD be stored in a separate HSM or KMS from (a) the gateway application runtime and (b) the XRPL settlement / escrow key. This limits blast radius if the app tier or settlement tier is compromised.

PA signing audit trail (SHOULD — SECOP 7a): Each PolicyGrant issuance SHOULD append an append-only audit record (who authorized, timestamp, issuerKeyId, grantId, and policy commitment / policyHash) to a log or SIEM independent of mutable application logs, so operators can detect or reconstruct unauthorized grant minting.

Session config  →  internal PolicyGrant
{                    {
  budget: $800         grantId: ...,
  purposes: [...]  →   policyHash: sha256(canonicalize(session config)),
  expiresAt: ...       allowedPurposes: [...],
}                      allowedRails: ["xrpl"],
                       authorizedGateway: <gateway XRPL addr>,
                       velocityLimit: { maxPayments, windowSeconds },
                       expiresAt: ...,
                       activeGrantCredentialIssuer: ... (when using on-chain liveness)
                    }

The gateway derives policyHash by canonicalizing the session config as a policy document and computing its SHA-256. This hash is stored in the internal PolicyGrant and appears in every SBA issued against that session.

Wallet Session

For each active gateway session, the gateway runs a wallet Session that:

  • Issues a per-payment SBA (budgetScope: "SESSION", maxAmountMinor = this payment amount)
  • Tracks cumulative spend against the session ceiling
  • Checks the internal revocation state before signing each SBA
  • Throws MpcpBudgetExceededError or MpcpGrantRevokedError when appropriate — refusing to proceed with the outbound payment

Revocation

Budget owners revoke via the gateway's REST API. The gateway immediately marks the internal grant as revoked. The wallet Session checks this state before signing the next SBA. The next outbound payment attempt is refused before any x402 request is sent.

Audit and Receipts

The gateway produces a signed per-payment receipt for every completed payment:

{
  "receiptId": "rcpt_...",
  "sessionId": "...",
  "purpose":   "travel:hotel",
  "amount":    { "amountMinor": "18000", "currency": "USD" },
  "merchant":  "...",
  "paidAt":    "2026-04-10T15:00:00Z",
  "txRef":     "txid:...",
  "signature": "..."
}

The budget owner can retrieve the full receipt log at any time via GET /sessions/{id}/receipts. This provides after-the-fact accountability even without a full MPCP artifact chain.

For deployments requiring stronger guarantees, the gateway can include the internal SBA in the receipt payload, allowing the budget owner to independently verify the artifact chain at audit time. This is distinct from the Level 1 passthrough header (see Progressive Trust Path below), which sends the SBA to the merchant in the outbound request.

Progressive Trust Path

The gateway profile is designed as a migration path toward native MPCP, not a permanent ceiling:

Level 0 — Gateway trust only

Merchant sees x402 payment confirmation. No MPCP knowledge. Budget owner audits via gateway receipts.

Level 1 — MPCP passthrough headers

The gateway includes the internal SBA in a custom HTTP header alongside the x402 payment:

X-Mpcp-Sba: base64encodedSBA...

X-Mpcp-Sba is an implementation-defined header; it is not part of the MPCP protocol artifact spec. MPCP-aware merchants can independently verify the authorization chain if they choose. Non-MPCP merchants ignore the header. No merchant-side changes required to proceed.

Level 2 — Native MPCP

Merchant integrates the merchant-sdk. Full end-to-end verification. The gateway is removed from the trust chain. Budget owner runs their own PA server or continues to delegate to the gateway for grant issuance only.

This path lets deployments adopt MPCP gradually, proving value at each level before requiring integration from counterparties.

Comparison with Other Profiles

Human-Agent Profile Gateway Profile
Merchant SDK required ✓ ✗
PA server required ✓ (or gateway) ✗ (hosted by gateway)
Merchant verifies chain ✓ ✗ (trusts gateway)
Budget owner controls spend ✓ ✓
Revocation ✓ ✓ (gateway-mediated)
Adoption friction medium low
Cryptographic audit ✓ gateway receipts
Migration to native MPCP n/a (native) ✓ progressive

Security Considerations

Gateway as single point of trust

Because merchants trust the gateway for payment validity, a compromised or dishonest gateway could approve payments outside the budget owner's constraints. Mitigations:

  • Budget owners should use short-lived sessions with explicit expiry
  • The gateway should publish its enforcement logic and be independently auditable
  • Signed receipts allow budget owners to detect gateway misbehavior after the fact
  • Level 1 passthrough headers allow budget owners to cryptographically verify what the gateway signed

Gateway key protection

For native MPCP deployments, the Trust Gateway holds an XRPL private key that controls escrow and payment transactions. Compromise of this key allows an attacker to drain all active escrows. See Gateway Seed Security for the full threat analysis. Key recommendations:

  • The gateway private key SHOULD be stored in an HSM or cloud KMS — never in plaintext on disk
  • The PA SHOULD issue an XRPL Credential to the gateway account; on compromise, the PA deletes the credential to instantly revoke on-chain authorization
  • Operators SHOULD monitor for on-chain payments without corresponding SBAs in the audit trail

Budget owner session token security

The sessionToken granted to an agent controls spending up to the session ceiling. It should be treated with the same care as a payment credential:

  • Transmit over TLS only
  • Scope to a single agent process; do not share across agents
  • Revoke immediately if the token may be compromised

Optional session proof-of-possession (DPoP-style) (SECOP 7b)

A bearer sessionToken alone can be replayed if exfiltrated. Implementations MAY bind session usage to a session-scoped asymmetric key (Ed25519 RECOMMENDED) held only by the agent:

  1. Registration: At session creation (or first use), the client generates a session key pair and sends the public key to the gateway, which stores it alongside the session record.
  2. Request proof: Each sensitive request (e.g. POST /proxy) sends Authorization: Bearer <sessionToken> and a proof header such as X-Mpcp-Session-Proof: <base64url(signature)>.
  3. Signed payload: The signature MUST be over
    SHA256("MPCP:GatewaySession:1.0:" || canonicalJson({ "sessionId": "<id>", "method": "POST", "path": "/proxy", "bodySha256": "<hex of SHA-256 of raw body>", "ts": "<RFC3339>" }))
    using the session private key (same canonical JSON rules as MPCP canonical JSON).
  4. Verification: The gateway rejects the request if the proof is missing, stale beyond a configured skew, or invalid.

A stolen bearer token is then insufficient without the session private key. Session private keys MUST remain in agent secure storage and MUST NOT be sent to merchants.

Revocation latency

Revocation takes effect before the next payment attempt (the wallet Session checks before signing each SBA). There is no window where a previously-authorized in-flight payment is retroactively cancelled. Payments already completed before revocation are unaffected.

See Also

  • Human-Agent Profile — native MPCP for AI agent delegation
  • Integration Guide — implementation paths for all profiles
  • Trust Bundles — offline key resolution for embedded device deployments
  • x402 — HTTP-native machine payment protocol used on the outbound side