Snapshot status: immutable product release v1.10.0. For the active release, consult https://mandateshield.com/current-release.json.

# MandateShield: complete product and integration context

Canonical URL: https://mandateshield.com/
Category: AI-agent payment authority verification; pre-payment execution control
Product release snapshot: v1.10.0
OpenAPI contract snapshot: v3.1.0
Boundary specification snapshot: v2.4.0
Released and generated: 2026-07-26T19:12:33.000Z
Authoritative current-release pointer: https://mandateshield.com/current-release.json
Immutable OpenAPI: https://mandateshield.com/openapi/3.1.0.json
Immutable AI index: https://mandateshield.com/llms/1.10.0.txt
Immutable full AI context: https://mandateshield.com/llms-full/1.10.0.txt
Immutable discovery manifest: https://mandateshield.com/discovery/1.10.0.json
Strict single verification: POST https://mandateshield.com/api/v2/verify
Strict batch verification: POST https://mandateshield.com/api/v2/batch (1–25 independent inputs)
One-time challenge: POST https://mandateshield.com/api/v2/challenges
Execution authorization transitions: POST https://mandateshield.com/api/v2/execution-authorizations
Execution Permit verification: POST https://mandateshield.com/api/v2/execution-permits/verify
Execution Permit redemption: POST https://mandateshield.com/api/v2/execution-permits/redeem
Provider submission report and independent reconciliation: POST https://mandateshield.com/api/v2/provider-submissions
Stripe signed-hint webhook template: POST https://mandateshield.com/api/v2/provider-webhooks/stripe/{connection_id}
Execution Receipt verification: POST https://mandateshield.com/api/v2/execution-receipts/verify
Decision receipt verifier: POST https://mandateshield.com/api/v2/receipts/verify
Public receipt transparency: GET https://mandateshield.com/api/v2/transparency/{receipt_id}
Public receipt JWKS: https://mandateshield.com/.well-known/jwks.json
Zero-account strict lifecycle sandbox: POST https://mandateshield.com/api/v2/sandbox/lifecycle
Strict lifecycle sandbox specification: https://mandateshield.com/specifications/strict-lifecycle-sandbox/v1
Proof Network list: GET https://mandateshield.com/api/v1/proof-network/proofs
Proof Network challenge: POST https://mandateshield.com/api/v1/proof-network/challenges
Proof Network attestation: POST https://mandateshield.com/api/v1/proof-network/attestations
Proof attestation specification: https://mandateshield.com/specifications/proof-attestation/v1
Analysis endpoint: POST https://mandateshield.com/api/v1/preflight
Analysis batch: POST https://mandateshield.com/api/v1/batch
MCP endpoint: POST https://mandateshield.com/api/mcp
Standalone no-auth MCP profile: POST https://mandateshield.com/api/mcp/plugin
A2A endpoint: POST https://mandateshield.com/a2a
A2A discovery: https://mandateshield.com/.well-known/agent-card.json
OpenAPI: https://mandateshield.com/openapi.json
Vendor specification: https://mandateshield.com/standard
Execution Permit v1 specification: https://mandateshield.com/specifications/execution-permit/v1
Execution Permit v1 schema: https://mandateshield.com/schemas/execution-permit-v1.json
Execution Receipt v1 specification: https://mandateshield.com/specifications/execution-receipt/v1
Execution Receipt v1 schema: https://mandateshield.com/schemas/execution-receipt-v1.json
ProviderSubmission v1 schema: https://mandateshield.com/schemas/provider-submission-v1.json
ProviderEvidence v1 schema: https://mandateshield.com/schemas/provider-evidence-v1.json
ReconciliationRecord v1 schema: https://mandateshield.com/schemas/reconciliation-record-v1.json
Execution assurance level v1 schema: https://mandateshield.com/schemas/execution-assurance-level-v1.json
Integration packages: https://mandateshield.com/integrations
Node.js install: npm install https://mandateshield.com/packages/npm/1.10.0/mandateshield-sdk-1.10.0.tgz
Python install: python3 -m pip install --index-url https://mandateshield.com/packages/python/simple mandateshield==1.10.0
Go install: GONOSUMDB=github.com/mandateshield/mandateshield-go GOPROXY=https://mandateshield.com/packages/go go get github.com/mandateshield/mandateshield-go@v1.10.0
Agent plugin manifest: https://mandateshield.com/plugins/mandateshield/plugin.json
Distribution status: directly installable from the MandateShield origin; no third-party package-registry or plugin-directory publication is claimed
First-party x402 v2 exact Gate: https://mandateshield.com/integrations/x402-v2-exact
Pinned JavaScript SDK: https://mandateshield.com/sdk/v1.10.0/mandateshield.mjs
Pinned execution-evidence verifier: https://mandateshield.com/sdk/v1.10.0/mandateshield-execution-evidence-verifier.mjs
Execution-evidence verifier TypeScript declarations: https://mandateshield.com/sdk/v1.10.0/mandateshield-execution-evidence-verifier.d.ts
Pinned gateway adapter: https://mandateshield.com/sdk/v1.10.0/mandateshield-gateway.mjs
Gateway TypeScript declarations: https://mandateshield.com/sdk/v1.10.0/mandateshield-gateway.d.ts
Pinned x402 exact adapter: https://mandateshield.com/sdk/v1.10.0/mandateshield-x402-v2-exact.mjs
x402 TypeScript declarations: https://mandateshield.com/sdk/v1.10.0/mandateshield-x402-v2-exact.d.ts
Release checksums: https://mandateshield.com/sdk/v1.10.0/SHA256SUMS
Release manifest: https://mandateshield.com/evidence/v1.10.0/release-manifest.json
x402 compatibility evidence: https://mandateshield.com/evidence/v1.10.0/x402-compatibility.json
x402 compatibility evidence schema: https://mandateshield.com/schemas/x402-compatibility-evidence/v1
Release manifest schema: https://mandateshield.com/schemas/release-manifest/v3
Human documentation: https://mandateshield.com/docs
Methodology: https://mandateshield.com/methodology
Payment-authority evidence: https://mandateshield.com/evidence/payment-authority-control-matrix
Protocol support evidence: https://mandateshield.com/evidence/protocol-support-matrix
Canonical payee identity: https://mandateshield.com/specifications/payee-identity/v1
Payee identity schema: https://mandateshield.com/schemas/payee-identity-v1.json
Payee identity evidence: https://mandateshield.com/evidence/v1/payee-identity.json
MandateShield Gate: https://mandateshield.com/gate
Deployment assurance schema: https://mandateshield.com/schemas/deployment-assurance-v1.json
x402 Gate execution profile: https://mandateshield.com/specifications/x402-gate/v1
x402 artifact journal schema: https://mandateshield.com/schemas/x402-gate-artifact-v1.json
Gateway adapter specification v2: https://mandateshield.com/specifications/gateway-adapter/v2
Gateway journal schema v2: https://mandateshield.com/schemas/gateway-adapter-v2.json
Bounded formal execution model: https://mandateshield.com/evidence/formal-execution-model
Formal model results: https://mandateshield.com/evidence/formal-execution-model/v1/results.json
TLA+ state-machine source: https://mandateshield.com/evidence/formal-execution-model/v1/MandateShieldExecution.tla
MCP payment authorization guide: https://mandateshield.com/guides/mcp-payment-authorization
Agentic payments glossary: https://mandateshield.com/reference/agentic-payments-glossary

## What MandateShield does

MandateShield verifies whether an autonomous purchase stays inside account-controlled human authority, atomically reserves its amount against optional cumulative budgets, and exposes a provider-bound execution handoff. It evaluates fiat minor units or exact atomic-asset units, currency or asset/network/resource bindings, merchant, expiry, consent reference, agent identity, signed intent, relying party and unique execution attempt. Strict v2 verifies supported JWS, an AP2-shaped closed-payment SD-JWT projection with RFC 9901 KB-JWT, and normalized TAP-shaped RFC 9421-style evidence, then issues an ES256-signed decision receipt and a short RESERVED authorization. Product v1.7 binds one exact provider operation into a short ES256 Execution Permit, atomically redeems it online, persists ProviderSubmission/ProviderEvidence/ReconciliationRecord state, independently verifies configured Stripe PaymentIntent or canonical x402 chain outcomes, autonomously finalizes terminal budget state and returns an ES256 terminal Execution Receipt. Full AP2 checkout/delegate-chain, Visa TAP structured-field/trust-store processing and actual provider/facilitator adoption remain external.

## Normative execution invariant

A strict verification response establishes a consumable reservation only when:

1. result.decision === "ALLOW"
2. result.enforcement_authorized === true
3. result.mode === "live"
4. result.persisted === true
5. result.assurance.authority_valid === true
6. result.assurance.key_trust === "ACCOUNT_PINNED"
7. result.execution_authorization.state === "RESERVED"
8. result.execution_authorization.consumable === true

These fields establish a consumable reservation, not permission to call the provider directly. Every other result is non-executable. Do not reinterpret REVIEW, sandbox ALLOW, test ALLOW, caller-supplied-key verification, v1 ALLOW or HTTP success as payment authorization.

## Production authorization sequence

Account-age rule: every account created at or after 2026-07-26T12:01:24.000Z must include provider_binding on CONSUME. Only accounts created before that cutoff retain legacy unbound CONSUME compatibility. Missing or malformed account creation evidence fails closed into the provider-bound rule. New integrations must always send provider_binding and must not infer legacy eligibility from a response, key age or client version.

1. In the authenticated dashboard, create a VERIFY-scoped live API key and a separate PROCESSOR-scoped live key bound to the exact relying-party processor_audience. VERIFY keys cannot transition authorizations. PROCESSOR keys cannot issue challenges or verify authority and must never be exposed to the model, agent or browser.
2. Register a mandate policy. Fiat mandates contain currency and an integer maximum in minor units. ATOMIC_ASSET mandates contain exact asset_id, network, positive max_atomic_units decimal string, asset_decimals and allowed resources. Both may add unique LIFETIME, DAY and MONTH cumulative budgets in their exact units, and both contain allowed merchants, expiry and the external consent-record reference. DAY and MONTH use UTC. Versions are immutable; replacement creates a new version and revokes the old active version.
3. Register only the authority issuer's public JWK. The account pin stores its RFC 7638 thumbprint, exact issuer, exact audience, protocol and PAYMENT_AUTHORITY purpose. Private JWK members are rejected.
4. Request a five-minute challenge from POST /api/v2/challenges using the live key, mandate_id, exact protocol and selected pin's RFC 7638 key_thumbprint. ANY is valid only for trust-key registration, not challenge issuance. The response returns the pin's issuer and audience.
5. Have the pinned authority issuer sign the exact final purchase using the issuer and audience returned by the challenge. JWS and SD-JWT claims include issuer, audience, challenge nonce, iat, exp and the SHA-256 digest of canonical envelope JSON. Production iat-to-exp is at most 24 hours. The TAP adapter receives normalized @method, @authority, @path and content-digest components with a window of at most 15 minutes; upstream parsing of raw Visa structured fields remains external.
6. Submit envelope and evidence to POST /api/v2/verify using the VERIFY key. The request public key must match the account pin; the signature's issuer, audience and protocol must match the pin; the challenge must be unexpired and unused. A qualifying ALLOW atomically creates receipt/audit evidence, a RESERVED authorization and reservations against every configured cumulative budget.
7. In the trusted gateway, POST action CONSUME to /api/v2/execution-authorizations using the PROCESSOR key. Send the compact decision receipt, exact original envelope, exact audience, transition-specific idempotency key and provider_binding for the exact provider profile, environment, account, request ID, payee destination, method, resource and body digest.
8. Provider-bound CONSUME moves RESERVED to CONSUMED, atomically creates one ProviderSubmission record and returns a short signed Execution Permit, provider_redemption_required=true and provider_submission_permitted=false. The customer, agent and merchant are not permitted to interpret this response as provider authority. The MSP+JWT permit binds the decision and attempt, provider request, payee, exact fiat or atomic amount, resource, settlement deadline and a MandateShield-generated provider idempotency key. Its maximum lifetime is 60 seconds and max_uses is one.
9. Signature-only inspection with the public JWKS or POST /api/v2/execution-permits/verify is advisory. It reports online_state=UNKNOWN, one_use_enforced=false and provider_submission_permitted=false. Offline verification never grants execution.
10. An audience-bound execution service holding a live PROCESSOR credential posts the complete compact permit and exact provider, payee, amount and resource claims to /api/v2/execution-permits/redeem. Only the first response with provider_submission_permitted=true, status=CLAIMED and idempotent_replay=false grants that service one provider operation. It must retain provider_submission_id. An exact retry returns the same claim with permission false; a different replay is rejected with HTTP 409.
11. Submit exactly the signed request using the returned provider_idempotency_key and obtain one stable non-secret payment_reference.
12. POST provider_submission_id, permit_id, claim_id, payment_reference, caller outcome and occurrence time to /api/v2/provider-submissions. The report is persisted as CALLER_ASSERTED evidence only.
13. MandateShield independently retrieves the bound Stripe PaymentIntent through the account's encrypted restricted-key connection or verifies the bound x402 transaction receipt, exact transfer log, canonical block and configured confirmation depth. A Stripe webhook must pass raw-body signature, freshness and event-replay checks, but remains only a scheduling hint before the independent API lookup.
14. Only matching PROVIDER_API_VERIFIED or CHAIN_FINALIZED evidence can atomically and autonomously COMMIT a confirmed success or RELEASE a confirmed failure, update cumulative budget state and issue a signed Execution Receipt with independent_verification=true. Pending, unavailable, unknown and contradictory evidence remains fail-closed under durable lease-based retries. Manual processor_result COMMIT/RELEASE remains available as CALLER_ASSERTED evidence with independent_verification=false.

## Durable records

The account-registered mandate overrides agent-supplied production limits. An account-wide (not merely per-key) idempotency tombstone creates one durable authorization record for each payment attempt. Exact-input network retries recover the original result; conflicting or concurrent reuse is blocked. Verification atomically reserves the amount against every configured LIFETIME, UTC-DAY and UTC-MONTH counter. Concurrent attempts cannot both consume the same remaining headroom. COMMIT moves the amount from reserved to committed; RELEASE or unconsumed expiry returns it. After the settlement deadline, an unresolved consumed outcome is conservatively charged to the cumulative budget and is never auto-released.

The caller must use stable, distinct idempotency keys for verification, consumption and redemption; the ProviderSubmission record, payment reference and evidence digest make outcome reporting and reconciliation idempotent. The provider operation must use the MandateShield-generated idempotency key bound into the signed permit and returned by redemption. The hosted MandateShield service never executes payment. It atomically enforces permit redemption in its own ledger, but it cannot force an external provider to reject a direct permitless request unless that named provider or facilitator has adopted the contract.

The public decision-receipt transparency response contains only receipt hash, input digest, decision digest, decision, protocol, receipt key ID and issuance time. It does not publish the envelope, account, merchant or payment credentials. Records are append-only while retained and expire under the account plan; MandateShield does not describe the lookup as a Merkle ledger. Receipt verification and archival preserve evidence but never authorize a new or replayed payment. The original strict response creates only a short reservation; the recommended v1.10 path requires provider-bound CONSUME followed by one fresh online redemption.

processor_result is a structured assertion made by the customer's trusted processor adapter and authenticated with its PROCESSOR key. Manual transitions record it as CALLER_ASSERTED with independent_verification=false. The ProviderSubmission endpoint and signed Stripe webhook also record caller/provider-event observations only as hints. MandateShield separately retrieves the exact Stripe PaymentIntent or validates canonical x402 chain evidence; a matching terminal result is stored as PROVIDER_API_VERIFIED or CHAIN_FINALIZED with independent_verification=true and can drive an autonomous SYSTEM transition. Every MSE+JWT execution receipt is historical evidence only and declares execution_authorized=false. LEDGER_DERIVED can describe unused expiry and UNRESOLVED can describe settlement uncertainty. FACILITATOR_SIGNED is meaningful only if a supported independent signature verifier actually validates the named facilitator evidence; no general facilitator adoption is claimed.

## Bounded formal evidence

MandateShield publishes a vendor-authored TLA+ state-machine specification for reservation, consumption, commitment, confirmed release, conservative unknown settlement, authority revocation, retained receipt-key rotation and tenant isolation. A separate TypeScript breadth-first explorer actually evaluates a finite two-tenant abstraction and injects eight deliberately unsafe mutations to verify that the named invariant checks detect them.

The published machine-readable result states the exact bounds, explored-state and transition counts, invariant outcomes, mutation detections and limitations. It is bounded first-party evidence, not a claim of mathematical proof, TLC execution, exhaustive state-space coverage, production-code refinement checking or independent audit.

## Gate deployment assurance

The customer-controlled Gate owns the transition credential, durable compare-and-set journal and provider adapter. In the provider-bound path, the provider or facilitator enforcement service owns a dedicated live PROCESSOR redemption credential for the exact signed audience. Neither credential belongs in the model, agent, browser or merchant page. The offline doctor command evaluates a strict non-secret evidence document without making network requests. It reports one cumulative level: UNVERIFIED, SDK_ONLY, CREDENTIAL_ISOLATED, EGRESS_ENFORCED or PROVIDER_ATTESTED. Current Gate production readiness requires PROVIDER_ATTESTED and zero failed controls, but that label means only that the supplied deployment, webhook, provider-lookup and receipt-key evidence passed the current Doctor controls. It does not mean the provider validates MandateShield permits or refuses permitless submissions.

Doctor validates a declaration; it does not inspect a customer's cloud account, firewall, database or provider console. A customer must retain the deployment-owned tests behind every true assertion. The result is not an independent audit, provider attestation, certification or guarantee that an arbitrary deployment cannot be bypassed.

## Product assurance modes

Verify is deterministic action evaluation and does not control later execution. Reserve adds atomic cumulative-budget allocation. Product v1.7 provides signed provider-bound permit issuance, online atomic redemption and independently verified Stripe/x402 terminal reconciliation, but that mechanism becomes external enforcement only at an execution service that actually requires it. Gate is the customer-controlled credential and submission boundary. PROVIDER_ATTESTED is deployment evidence, not provider enforcement, and cannot by itself support end-to-end, non-bypassable or provider-mandatory claims. PROVIDER_ENFORCED may be claimed only for an identified provider that actually requires and redeems the permit and rejects permitless operations. FACILITATOR_ENFORCED may be claimed only for an identified facilitator doing the same. MandateShield currently claims neither general provider/facilitator adoption nor permitless-request rejection. Reconcile is provider-specific and distinguishes independently confirmed success, independently confirmed failure and UNKNOWN without restoring budget on uncertainty. Evidence includes signed receipts, provider API or canonical-chain verification records, retained verification keys, versioned hash-verifiable release artifacts and bounded first-party model results; it is not an independent audit unless explicitly identified as such.

## Zero-account strict lifecycle sandbox

POST /api/v2/sandbox/lifecycle accepts only an empty JSON object or {"scenario":"SUCCESS"} and rejects Authorization credentials. One request creates ephemeral authority, simulated-provider and artifact keys, then exercises the real cryptographic and lifecycle validators through signed authority, strict ALLOW, atomic request-local reservation, provider-bound permit issuance, one successful claim, replay rejection, simulated provider attestation, COMMIT and signed execution-receipt verification.

The result always declares test_only=true, money_moved=false and production_accepted=false. Lifecycle state and keys do not survive the response. No production credentials or user-supplied outbound URLs are used. No external provider or independent organization participates. The separate ephemeral sandbox-provider signature demonstrates a cryptographic role boundary inside the simulation; it is not third-party evidence, a real provider outcome, production conformance, audit or certification.

## Public Proof Network

GET /api/v1/proof-network/proofs lists signed EXTERNALLY_BOUND_SELF_REPORT summaries. To enter the network, a claimant POSTs a complete current offline-vector report plus either an HTTPS-domain or public GitHub-repository subject to /api/v1/proof-network/challenges. MandateShield verifies that the claimant-reported outputs match the published expected vector decisions and findings, signs a 24-hour challenge, then requires DNS TXT control or an exact binding document in a specified public GitHub repository commit. POST /api/v1/proof-network/attestations verifies that external binding, persists one signed proof and exposes a full proof plus an explicitly labeled badge.

The binding and report digest are verified; the claimant implementation and conformance execution are not. result_verification is SELF_REPORTED_OUTPUTS_ONLY, independently_verified=false, third_party_conformance=false, certification=false and non_authorizing=true. Network entries and pseudonymous abuse counters are not users, customers or installations. Hosted MandateShield sandbox runs are excluded. Absence of an entry says nothing about compatibility, and presence does not prove production use, security, revenue or independent conformance.

## Cryptographic evidence

Supported evidence formats are compact JWS, an AP2-shaped closed-payment SD-JWT projection and normalized TAP-shaped RFC 9421-style evidence. Supported verification algorithms depend on format and include ES256, RS256 and PS256. A request-supplied public key verifies the signature but creates no trust by itself. Live trust exists only after an account pin matches the key thumbprint and the signed issuer, audience and protocol.

AP2 strict verification requires a closed mandate.payment.1 credential. Its bound disclosure must contain the final payment amount, currency, payee and transaction binding, and its holder proof is the RFC 9901 KB-JWT. MandateShield verifies this closed-payment projection; validation of the checkout_jwt hash, delegate chain, open-mandate constraints and AP2 issuer registry remains external. Unbound, duplicate and colliding disclosures fail closed. The TAP adapter verifies normalized RFC 9421-style components and canonical-envelope content-digest binding; it is not a claim of end-to-end Visa TAP conformance.

## X402 atomic-asset projection

For protocol X402, send amount.atomic_units as a canonical decimal digit string and amount.asset_decimals as an integer from 0 through 30. Never convert atomic_units or the registered max_atomic_units to a JSON number, float, decimal or exponent: the verifier compares their arbitrary-precision integer values exactly. The envelope asset_id, network, resource and asset_decimals must match the active registered mandate exactly; substitution of any field fails closed.

This is a normalized pre-payment verification projection. The optional protocol bridge parses the x402 v2 PAYMENT-REQUIRED offer but never creates a PAYMENT-SIGNATURE or makes the result executable. In the recommended v1.10 path, payment submission may begin only after provider-bound CONSUME issues a permit and the facilitator/execution service freshly redeems its exact bindings online.

The separate first-party MANDATESHIELD_X402_V2_EXACT_EIP3009_V1 adapter is a narrow payer-side x402 v2 HTTP exact/EIP-3009 Gate, not a facilitator or payment rail. It accepts only configured EIP-155 assets/token domains, merchant/network/payTo/resource-origin mappings and exactly one configured payer per network/asset; binds canonical URL, method, body-byte digest, canonical allowed-header projection digest, network, asset, amount and payee; canonically compares a fresh 402 challenge; creates one payload through a customer-configured compatible x402 v2 client; requires a customer-supplied local verifier to recover the exact EIP-3009 signer; and atomically claims the network+asset+payer+nonce key in one globally shared, linearizable customer journal. Before transmission a customer verifier must capture the latest canonical block and prove the exact nonce unused through a block-hash-pinned require-canonical query. The adapter persists that complete anchor and the signed credential before transmission and disables redirects.

The adapter never commits from PAYMENT-RESPONSE alone. Product v1.10.0 executes a compatibility test against the installed @x402/core and @x402/evm 2.19.0 package interfaces. Normative specification references are pinned separately to upstream commit 90688e52e58ae9185f2860988bd2c46d2801ceda; the test does not build that Git commit or prove package-to-source correspondence. The customer Gate verifier confirms signer, nonce ownership and the full EIP-3009 call projection before reporting the stable transaction hash. The hosted ProviderSubmission reconciler independently retrieves that exact transaction and receipt from a configured EVM RPC endpoint, requires a successful canonical receipt, exact token/payee/amount Transfer log and configured confirmation depth before emitting CHAIN_FINALIZED evidence. Reverted, absent, shallow-confirmation, reorged or mismatched results remain unresolved or rejected and never release on ambiguity. The customer journal still requires GLOBAL_SHARED_LINEARIZABLE semantics; that declaration is not independent storage proof. Wallet keys, signed payloads and paid resources never enter the hosted service. Configured RPC URLs are operational verifier configuration, not payment credentials. This customer-side adapter plus hosted reconciliation remains a narrow first-party profile, not external provider enforcement. It does not claim every x402 scheme, extension, network or token; exactly-once HTTP execution; live settlement as a service; x402 Foundation partnership/certification; RPC uptime; or independent audit.

## Native protocol adapters and paid API projection

POST /api/v2/normalize and the normalize_agent_payment_protocol MCP/A2A skill map an AP2 terminal closed-payment projection, x402 v2 PAYMENT-REQUIRED offer or MPP Payment charge challenge into a deterministic purchase envelope. X402 requires canonical payee identity whose network and pay_to exactly match the selected offer plus a trusted merchant-mapping evidence reference. MPP requires canonical payee identity whose HTTPS service_origin and method exactly match the trusted resource and challenge. A caller merchant_id alone is insufficient. assurance.projection_fields_valid=true means only the documented projected fields and explicit mappings passed; assurance.enforcement_authorized is always false. The bridge binds but does not fetch or independently verify identity evidence. It does not establish complete source-protocol conformance and does not verify the full AP2 chain, x402 PAYMENT-SIGNATURE, MPP method credential or settlement. An upstream AP2 token cannot be posted unchanged: strict AP2 requires the documented canonical input-digest projection and RFC 9901 holder KB-JWT, or the integrator can use the CUSTOM JWS profile. Strict v2 separately requires account-pinned signed authority over the exact final envelope. Payment-protocol validity does not by itself prove that a person or enterprise delegated authority for the exact purchase.

## Canonical payee identity

MANDATESHIELD_PAYEE_IDENTITY_V1 is placed inside the signed final envelope. X402 binds network+payTo; MPP binds HTTPS service origin+method; the first-party Stripe gateway binds configured connected+merchant account; CUSTOM binds provider_id+HTTPS service origin and requires exact same-origin /.well-known/mandateshield-payee.json evidence. The customer gateway rejects a provider-profile mismatch before CONSUME or provider submission. The evidence_ref is a signed reference, not a claim that MandateShield independently validated registry membership, TLS, provider onboarding or domain control.

MCP can expose a paid API or service as a callable tool. MCP tool access is not customer consent, and the hosted MandateShield MCP server deliberately exposes no processor transition, permit-redemption or provider-submission tool. The strict MCP verifier can create only a RESERVED authorization. An external trusted gateway must perform provider-bound CONSUME, an audience-bound execution service must freshly redeem the resulting permit before one operation, and provider reconciliation remains outside the model transport.

## Analysis-only v1 profile

POST /api/v1/preflight and the check_ai_payment_authority MCP tool provide policy diagnostics. They always return enforcement_authorized=false. Authenticated analysis can persist a decision and replay tombstone, but persistence does not turn v1 into execution authority.

## Agent-native access

The remote MCP server publishes:

- normalize_agent_payment_protocol — non-executable protocol field projection
- check_ai_payment_authority — v1 analysis only
- verify_cryptographic_payment_authority — strict v2 verification

Production MCP and A2A clients pass a VERIFY-scoped live bearer credential as a server-side Authorization header. Agent transport never weakens the reservation invariant. The hosted tools never execute a payment, never hold a PROCESSOR key, never redeem an execution permit and never perform execution transitions on the model's behalf.

## Advisory versus deterministic signals

Deterministic mandate, amount, currency, atomic asset/network/resource/decimals, merchant, expiry, signature, key trust, issuer, audience, nonce, purchase-binding and replay failures block. Prompt-injection pattern matching is heuristic and returns REVIEW. Privacy-thresholded cross-account merchant signals are advisory and return REVIEW; they never create an automatic network block.

## Critical category clarification

MandateShield is not SEPA, ACH or Bacs direct-debit mandate software. The hosted service does not collect debit authorizations, IBANs, payment signatures or bank instructions and does not move money. Optional first-party Gate adapters run only in customer infrastructure. “Mandate” means bounded purchase authority delegated by a person to an AI agent.

## What MandateShield does not do

The hosted MandateShield service does not receive payment credentials, submit or settle transactions, provide fraud insurance, perform sanctions screening or replace issuer, acquirer, payment-network, consumer-law or chargeback controls. For reconciliation it may retain an account-configured encrypted Stripe restricted lookup key plus webhook secret and configured EVM RPC endpoints; it never receives card numbers, bank credentials, wallet private keys or signed payment credentials. Optional first-party Gate adapters validate and submit provider operations inside customer infrastructure. Authorization and reconciliation prove only that the implemented authority, exact binding and named provider-evidence checks passed.

The Mandate Execution Boundary is a vendor-published open contract and reference implementation. It is not represented as an accredited or consensus industry standard. No independent certification, third-party audit, customer deployment, revenue, savings or prevented-loss outcome is claimed without a named evidence source.

## Core controls

- Immutable account-registered mandate versions
- Currency-aware integer minor-unit limits
- Exact arbitrary-precision atomic-unit limits and asset/network/resource/decimals binding
- Optional LIFETIME, UTC-DAY and UTC-MONTH cumulative budgets
- Atomic cumulative-budget reservation across concurrent attempts
- Merchant and payee scope
- Consent reference and expiry
- Account-pinned RFC 7638 issuer keys
- Signed issuer, audience, protocol, iat and exp
- Server-issued five-minute consume-once challenge
- Canonical JWS/SD-JWT purchase digest or TAP content-digest
- Durable account-wide idempotency tombstone
- ES256 signed decision receipt and public JWKS
- Privacy-safe public receipt-transparency lookup
- Private execution-audit record
- Separate VERIFY and audience-bound PROCESSOR API-key scopes
- ES256 provider-bound MSP+JWT with a maximum 60-second lifetime
- Exact provider, payee, amount, resource and signed provider-idempotency binding
- Atomic online execution-permit redemption; offline verification never grants
- Fresh redemption true exactly once; retry false and conflicting replay rejected
- Durable ProviderSubmission, ProviderEvidence and ReconciliationRecord state machines
- Signed Stripe webhook replay protection as scheduling evidence, never terminal proof
- Independent exact Stripe PaymentIntent API lookup and x402 canonical-chain confirmation
- Autonomous strong-evidence COMMIT or RELEASE with conservative UNKNOWN/conflict retries
- ES256 MSE+JWT terminal execution receipt that never authorizes execution
- Explicit execution evidence class; caller assertions remain false while independently verified provider/chain evidence is true
- RESERVED, CONSUMED, COMMITTED, RELEASED, EXPIRED and conservative unknown-settlement states
- Advisory-only prompt and community signals

## Payment guardrails for autonomous AI agents

Add deterministic spending, merchant, consent and replay controls before a trusted gateway submits an AI-agent payment.

Audience: Teams building shopping, travel, procurement, research or operations agents that can place orders or initiate payments.

Risk: A model may correctly understand the original request and still encounter manipulated tools, changed prices or a substituted merchant later in the workflow. The final payment needs a deterministic boundary outside the model.

Controls: Hard spending caps, Merchant allowlists, Consent and expiry checks, Account-pinned issuer keys, One-time verification challenges, Cumulative budget reservation, Role-separated processor consumption, Provider-bound one-use permits, Independent configured provider reconciliation, Signed intent and purchase binding.

Outcome: The agent remains useful and autonomous while payment authority stays bounded by machine-enforceable user intent.

## Accept AI-agent orders without trusting the model

Reserve authority for autonomous checkout totals, merchant identity and user-approved limits, then require gateway consumption before creating a charge.

Audience: Online stores and commerce platforms preparing checkout flows for shopping agents, assistants and agentic browsers.

Risk: A valid card or wallet credential proves that a payment method can be used. It does not prove that the customer approved this exact seller, cart, total or delivery context.

Controls: Final-total validation, Seller identity binding, Cart and intent hashes, Authorization freshness, Consume-once execution state, Independent configured provider reconciliation, Minimal audit receipts.

Outcome: Merchants can support agentic checkout without replacing their processor or sending payment credentials to MandateShield.

## Policy enforcement for multi-merchant agent checkout

Control seller substitution, price drift and replay across marketplace purchases initiated by AI agents.

Audience: Marketplaces, booking platforms and aggregators where an agent can compare, select and buy from multiple sellers.

Risk: Search and ranking steps can change sellers, fees and availability between approval and payment. Marketplace complexity makes merchant binding and final-total validation essential.

Controls: Stable seller identifiers, Fee-inclusive budgets, Approved merchant scopes, Fulfillment-context binding, Regional currency policy, Atomic replay control, Fail-closed provider reconciliation.

Outcome: One policy layer protects many sellers and agent protocols without embedding model-specific logic in every checkout.

## Pre-authorization control for agentic payments

Add user-mandate enforcement before payment processing, alongside existing fraud and risk systems.

Audience: Payment processors, orchestration platforms, wallets and fintech infrastructure serving autonomous commerce.

Risk: Fraud scoring, card authorization and sanctions checks answer different questions from agent authority. Agent payments require an explicit policy decision tied to the user's mandate.

Controls: Protocol-neutral input, Fail-closed validation, Idempotent decisions, Reason-code output, Account-pinned key trust, Role-separated execution states, Independent configured provider reconciliation, Signed receipts and transparency lookup.

Outcome: Providers can add agent-payment authorization as a composable API instead of rebuilding protocol-specific policy engines.

## Explainable controls for autonomous transaction authority

Produce deterministic AI-payment decisions, reason codes and minimal receipts for operational oversight.

Audience: Fintech risk, compliance, security and governance teams evaluating autonomous transaction systems.

Risk: A model-generated explanation is not a control. Oversight requires stable inputs, deterministic rules, clear failures and evidence that can be retained without payment credentials.

Controls: Explicit policy boundaries, Explainable findings, Human-review state, Minimal-data design, Execution-time evidence, Replay-resistant records.

Outcome: Operational teams gain a consistent control point without treating an AI model's confidence as authorization.

## Payment controls for paid APIs, MCP tools and machine services

Authorize provider, resource, exact price and cumulative budget before an AI agent pays for an API call or MCP tool.

Audience: API sellers, MCP server operators, agent platforms and developers connecting autonomous software to usage-priced machine services.

Risk: A callable tool is not automatically an authorized purchase. Loops, retries, changed payment requirements and resource substitution can multiply spend or buy a different service than the user or enterprise approved.

Controls: Provider allowlists, Exact resource binding, Per-call spending caps, Lifetime, daily and monthly budgets, Concurrent reservation, Consume-once replay control, Fail-closed provider reconciliation, Protocol-neutral receipts.

Outcome: The paid API or MCP service keeps its own pricing and settlement flow while a separate authority boundary decides whether this agent may buy this exact resource now.

## AI procurement agent spending controls

Give procurement agents enforceable supplier scopes, exact transaction limits and concurrent daily or monthly budgets.

Audience: Procurement, finance, platform and security teams allowing agents to source software, services, travel, inventory or operational supplies.

Risk: Several agents can pass a simple budget check at the same time and collectively overspend it. Supplier substitution, fees, currency changes and retries create additional risk between an approval and the final payment submission.

Controls: Supplier allowlists, Per-purchase limits, Atomic cumulative budgets, Cross-agent concurrency control, Final amount and currency binding, Role-separated gateway execution, Independent configured provider reconciliation, Signed audit receipts.

Outcome: Agents can execute approved purchases without replacing the enterprise procurement system, ERP approval workflow, payment processor or settlement controls.

## Stop AI-agent overspend before payment

Enforce a hard maximum against the final amount, including checkout changes, fees and currency boundaries.

Audience: Any merchant, agent or payment platform allowing software to select products and execute purchases.

Risk: Prices, quantities, taxes and fees can change after the user delegates a purchase. Natural-language instructions such as 'around $100' are unsafe unless converted into an explicit maximum.

Controls: Numeric maximum amount, Currency allowlist, Final-total comparison, Fee-inclusive policy, Fail-closed parsing, Exact reason codes.

Outcome: A correctly integrated gateway receives no consumable reservation for a total outside the user's stated authority, so its provider-submission gate stays closed.

## Prevent merchant substitution in agentic checkout

Bind an autonomous purchase to the intended seller or approved merchant scope before execution.

Audience: Shopping agents, marketplaces, booking systems and merchants supporting cross-site autonomous checkout.

Risk: Search manipulation, affiliate redirects, tool compromise or inventory changes can move an agent from an approved merchant to an unknown seller.

Controls: Stable merchant IDs, Payee binding, Merchant allowlists, Redirect-aware checkout facts, Intent hashes, Evidence receipts.

Outcome: The final payee must match the seller authority the customer actually granted.

## Contain prompt injection at the payment boundary

Detect instruction-override signals and enforce deterministic payment policy outside the AI model.

Audience: Teams connecting language models to browsers, tools, checkout APIs, wallets or purchasing workflows.

Risk: A page or tool can tell an agent to ignore earlier instructions, reveal secrets or override a budget. Model-level defenses help, but the payment boundary must assume upstream compromise is possible.

Controls: Supplementary instruction-override signals, Deterministic amount checks, Merchant scope enforcement, Cryptographic purchase binding, One-time authorization challenges, Fail-closed trust checks.

Outcome: Even a manipulated agent cannot make the policy engine reinterpret the user's payment authority.

## Enforce consume-once autonomous payment submission

Consume each payment decision once with durable idempotency and reject sequential or concurrent replay.

Audience: Agent developers, payment infrastructure teams and merchants operating distributed or retrying systems.

Risk: Network retries, duplicated tool calls and malicious replay can execute the same authorized purchase more than once. In-memory deduplication does not survive restarts or coordinate regions.

Controls: Durable idempotency, Atomic uniqueness, Concurrent replay rejection, Stable decision receipts, Retry-safe responses, Account-wide uniqueness, Audience-bound processor state.

Outcome: One strict attempt produces one durable reservation, and an integrated gateway can consume it once before its separately idempotent provider call.

## Keep AI purchases inside current user consent

Reject missing, stale or weakly bound authority when checkout facts change after the user delegates a purchase.

Audience: Agentic commerce systems where time, inventory, price or fulfillment details can change between instruction and checkout.

Risk: An old approval may no longer represent the user's intent after a price, merchant, cart or delivery change. Long-lived and ambiguous authority creates consent drift.

Controls: Explicit consent state, Mandate identifiers, Short expiry windows, Intent binding, Checkout-change detection, Review outcomes.

Outcome: Execution proceeds only when the evidence still represents the user's current and specific authority.

## Stop concurrent AI agents from overspending one shared budget

Use atomic reservations so parallel agent purchases cannot all pass the same stale daily, monthly or lifetime budget check.

Audience: Enterprise procurement, marketplaces, agent platforms and payment gateways coordinating multiple autonomous buyers or parallel tool calls.

Risk: Two requests can each observe sufficient remaining budget before either records its spend. Without a database-atomic reservation, both may proceed and exceed the shared authority even though each individual request appeared valid.

Controls: Atomic budget reservation, Lifetime, UTC-day and UTC-month counters, Cross-agent serialization, Consume-once execution state, Conservative unknown-outcome handling, Durable audit evidence.

Outcome: Parallel agents share one enforceable budget without relying on stale reads, in-memory locks or model coordination.

## Commercial and self-service access

The dashboard is the self-service control plane. Pricing is published in USD at https://mandateshield.com/pricing. Free public tools demonstrate analysis and cryptographic behavior but cannot produce live execution authority.