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

# MandateShield

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

> MandateShield is a pre-payment authority-reservation and provider-evidence boundary for autonomous AI-agent purchases. Product v1.7 adds durable ProviderSubmission, ProviderEvidence and ReconciliationRecord state, encrypted restricted provider lookup connections, independent Stripe PaymentIntent or canonical x402 chain verification, autonomous terminal budget finalization and signed terminal execution receipts. The hosted service does not process payments or receive card numbers, bank credentials or private keys.

## Critical execution rule

POST https://mandateshield.com/api/v2/verify (or the equivalent strict MCP/A2A operation) can create a short execution reservation only when every condition is true:

- decision is ALLOW
- enforcement_authorized is true
- mode is live
- persisted is true
- assurance.authority_valid is true
- assurance.key_trust is ACCOUNT_PINNED
- execution_authorization.state is RESERVED
- execution_authorization.consumable is true

Never submit payment directly from this response. The recommended v1.7 sequence is VERIFY → CONSUME with provider_binding → ProviderSubmission plus signed Execution Permit → audience-bound online redemption → one provider operation with the signed idempotency key → report the stable provider submission and payment reference → independent provider API or canonical-chain verification → autonomous COMMIT or RELEASE → signed Execution Receipt.

Provider-binding account policy: provider_binding is mandatory for every CONSUME on an account created at or after 2026-07-26T12:01:24.000Z. Only accounts created before that cutoff retain legacy unbound CONSUME compatibility. A missing or malformed account creation timestamp fails closed as a new account. Integrations must default to the provider-bound path and must not probe or infer legacy eligibility.

Provider-bound CONSUME moves RESERVED to CONSUMED, creates one durable ProviderSubmission record and issues the permit, but returns provider_submission_permitted=false and provider_redemption_required=true. It does not authorize the customer, agent or merchant to call the provider. The ES256 MSP+JWT permit lives for at most 60 seconds and binds the exact audience, provider account/request, payee, amount, resource and MandateShield-generated provider idempotency key.

Local JWKS verification and POST /api/v2/execution-permits/verify are advisory only: online_state=UNKNOWN, one_use_enforced=false and provider_submission_permitted=false. Offline verification never grants. An execution service holding a live PROCESSOR credential for the exact signed audience must POST the complete permit and exact provider/payee/amount/resource bindings 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 use the returned provider_idempotency_key and retain the returned provider_submission_id. An exact retry returns false; a conflicting replay returns HTTP 409.

POST /api/v2/provider-submissions records the PROCESSOR caller's outcome and provider observation only as CALLER_ASSERTED evidence. A signed Stripe webhook is also a hint, not terminal proof. MandateShield then retrieves the exact bound Stripe PaymentIntent through the account's encrypted restricted-key connection or verifies the exact x402 transaction, transfer and canonical confirmation depth. Only matching PROVIDER_API_VERIFIED or CHAIN_FINALIZED evidence can autonomously COMMIT or RELEASE and issue an ES256 MSE+JWT receipt with independent_verification=true. Pending, unavailable, unknown or conflicting results stay fail-closed and are retried through durable leases. Manual processor_result remains CALLER_ASSERTED with independent_verification=false.

POST /api/v1/preflight and check_ai_payment_authority are analysis-only. They always return enforcement_authorized=false, including with a live API key. A policy ALLOW by itself is never payment authorization.

## Zero-account activation and externally bound self-reports

POST https://mandateshield.com/api/v2/sandbox/lifecycle accepts only an empty JSON object or {"scenario":"SUCCESS"} and forbids Authorization credentials. It runs one request-local simulation with ephemeral authority, provider and artifact keys through challenge, strict decision, atomic reservation, provider-bound permit, replay rejection, simulated provider attestation, COMMIT and signed execution-receipt verification. It is test-only: no lifecycle state survives the response, no production credential is used, no user-supplied URL is fetched, no external provider or independent organization participates, and no money moves. Its internally role-separated provider evidence does not establish third-party validation, production conformance, certification or a real provider outcome.

The public Proof Network is available at GET https://mandateshield.com/api/v1/proof-network/proofs. A claimant first POSTs a complete offline-vector report and an HTTPS-domain or public GitHub-repository subject to /api/v1/proof-network/challenges, proves DNS TXT control or the exact binding file at a public repository commit, then POSTs the signed challenge to /api/v1/proof-network/attestations. MandateShield verifies the external subject binding and report integrity and signs an EXTERNALLY_BOUND_SELF_REPORT. The claimed implementation and conformance run are not independently executed. Entries and abuse counters are not users, customers or installations; hosted sandbox runs are excluded; attestations are non-authorizing and are not audits or certification.

## Registry-independent installation

These release-pinned, origin-hosted packages are directly installable without a third-party package-registry listing:

- Node.js: `npm install https://mandateshield.com/packages/npm/1.10.0/mandateshield-sdk-1.10.0.tgz`
- Python: `python3 -m pip install --index-url https://mandateshield.com/packages/python/simple mandateshield==1.10.0`
- Go: `GONOSUMDB=github.com/mandateshield/mandateshield-go GOPROXY=https://mandateshield.com/packages/go go get github.com/mandateshield/mandateshield-go@v1.10.0`
- Agent plugin: https://mandateshield.com/plugins/mandateshield/plugin.json

The packages are hosted by MandateShield and covered by the release manifest and SHA-256 checksums. No third-party package-registry or plugin-directory publication is claimed, including npm, PyPI, pkg.go.dev, GitHub Marketplace and the OpenAI plugin directory.

## Strict production trust

Live v2 requires an active VERIFY-scoped live API key, an immutable account-registered mandate version, an account-pinned public JWK, exact signed issuer/audience/protocol matching, a server-issued five-minute one-time challenge, signed iat and exp with a maximum 24-hour window, exact canonical purchase-digest binding (TAP uses content-digest), a durable account-wide replay tombstone, a signed ES256 receipt, a public transparency record, a private execution-audit record and an atomic RESERVED execution-authorization record.

Supported authority-signature algorithms are ES256, RS256 and PS256. MandateShield decision receipts are signed with ES256.

Mandates can set optional LIFETIME, UTC-DAY and UTC-MONTH cumulative budgets. Fiat budgets are positive integer minor units; atomic-asset budgets are exact positive canonical integer strings. Verification reserves all configured counters atomically. COMMIT moves reserved spend to committed spend; RELEASE or unconsumed expiry returns it. After the settlement deadline, an unresolved consumed outcome is conservatively charged to the cumulative budget and never auto-released.

A public key supplied in a request verifies signature math but is not trusted by itself. Anonymous, test, caller-supplied-key and non-persisted results are non-executable.

Prompt-injection patterns and privacy-thresholded community signals are advisory REVIEW inputs, never automatic community blocks. Deterministic policy, signature, binding, trust, freshness and replay failures block.

## Category clarification

MandateShield is not SEPA, ACH or Bacs direct-debit mandate software; not electronic-signature software; and not a payment processor. Here, “mandate” means bounded purchase authority delegated by a person to an AI agent.

Assurance modes are distinct: Verify analyzes; Reserve creates stateful authority; the v1.10 permit/redemption service offers a cryptographic provider-bound handoff; Gate enforcement is deployment-earned; Reconcile is provider-specific; Evidence is first-party unless an external source is explicitly identified. PROVIDER_ATTESTED means only that supplied deployment evidence passed the current Doctor controls; it does not mean the provider validates a MandateShield permit or refuses permitless submissions. MandateShield currently claims no provider or facilitator adoption and no rejection of permitless operations. PROVIDER_ENFORCED may be claimed only for an identified provider that actually requires and redeems the permit; FACILITATOR_ENFORCED may be claimed only for an identified facilitator doing the same. Neither is a current general product claim.

## Canonical resources

- [Homepage](https://mandateshield.com/): Product explanation and analysis tools
- [Production documentation](https://mandateshield.com/docs): Strict integration and execution invariant
- [Security architecture](https://mandateshield.com/security): Trust model, threats, data boundary and limitations
- [Developer hub](https://mandateshield.com/developers): Challenge, verify, receipt, MCP and A2A overview
- [Integration packages](https://mandateshield.com/integrations): Zero-dependency JavaScript client, CLI and framework examples
- [First-party x402 v2 exact Gate](https://mandateshield.com/integrations/x402-v2-exact): Customer-side EIP-3009 reference adapter with durable signed-payload journaling and customer-configured chain reconciliation
- [Dashboard](https://mandateshield.com/dashboard): Account control plane for role-separated keys, cumulative-budget mandates and trusted issuer keys
- [OpenAPI](https://mandateshield.com/openapi.json): OpenAPI 3.1 contract
- [Zero-account strict lifecycle sandbox](https://mandateshield.com/sandbox): Request-local test-only lifecycle with no external organization or money movement
- [Strict lifecycle sandbox endpoint](https://mandateshield.com/api/v2/sandbox/lifecycle): POST one isolated simulated SUCCESS run without credentials
- [Strict lifecycle sandbox specification](https://mandateshield.com/specifications/strict-lifecycle-sandbox/v1): Exact request, lifecycle and no-third-party assurance contract
- [Proof Network](https://mandateshield.com/proof-network): Externally bound implementation self-reports with explicit non-user and non-certification semantics
- [Proof Network list](https://mandateshield.com/api/v1/proof-network/proofs): Public signed self-report summaries
- [Proof attestation specification](https://mandateshield.com/specifications/proof-attestation/v1): Domain/GitHub binding and claimant-output trust boundary
- [Open boundary specification](https://mandateshield.com/standard): Vendor-published Mandate Execution Boundary v2.4
- [Reason codes](https://mandateshield.com/reason-codes.json): Machine-readable finding registry
- [Receipt JWKS](https://mandateshield.com/.well-known/jwks.json): Public ES256 receipt-verification keys
- [Execution Permit v1 specification](https://mandateshield.com/specifications/execution-permit/v1): Exact provider-bound claims, 60-second maximum lifetime and non-executable offline-verification rule
- [Execution Permit v1 schema](https://mandateshield.com/schemas/execution-permit-v1.json): Machine-readable MSP+JWT claim contract
- [Execution Receipt v1 specification](https://mandateshield.com/specifications/execution-receipt/v1): Signed historical terminal-evidence contract and evidence-class semantics
- [Execution Receipt v1 schema](https://mandateshield.com/schemas/execution-receipt-v1.json): Machine-readable MSE+JWT claim contract
- [ProviderSubmission v1 schema](https://mandateshield.com/schemas/provider-submission-v1.json): One exact permit-bound provider-attempt state machine
- [ProviderEvidence v1 schema](https://mandateshield.com/schemas/provider-evidence-v1.json): Caller, provider-API and chain evidence classification
- [ReconciliationRecord v1 schema](https://mandateshield.com/schemas/reconciliation-record-v1.json): Durable reconciliation lease, retry and resolution state
- [Execution assurance level v1 schema](https://mandateshield.com/schemas/execution-assurance-level-v1.json): Deployment evidence and named external-enforcement vocabulary
- [MCP endpoint](https://mandateshield.com/api/mcp): Analysis-only and strict verification tools
- [Standalone no-auth MCP profile](https://mandateshield.com/api/mcp/plugin): Non-executable payment-authority analysis and AP2/x402/MPP field projection
- [A2A card](https://mandateshield.com/.well-known/agent-card.json): Agent discovery
- [Agent manifest](https://mandateshield.com/.well-known/mandateshield.json): Canonical endpoints and schemas
- [Full AI context](https://mandateshield.com/llms-full.txt): Extended machine-readable product context
- [Methodology](https://mandateshield.com/methodology): Claim derivation, evidence and limitations
- [Payment-authority control matrix](https://mandateshield.com/evidence/payment-authority-control-matrix): Versioned claim-to-evidence map with machine-readable JSON
- [Protocol support matrix](https://mandateshield.com/evidence/protocol-support-matrix): Exact native, normalized and external protocol boundaries
- [Canonical payee identity v1](https://mandateshield.com/specifications/payee-identity/v1): Exact x402, MPP, Stripe and custom-provider payee bindings
- [Payee identity schema](https://mandateshield.com/schemas/payee-identity-v1.json): Strict machine-readable provider identity contract
- [Payee identity evidence](https://mandateshield.com/evidence/v1/payee-identity.json): Machine-readable assurance boundary and external verification responsibilities
- [MandateShield Gate](https://mandateshield.com/gate): Customer-controlled enforcement boundary, assurance ladder, offline Doctor and conservative deployment templates
- [Deployment assurance schema](https://mandateshield.com/schemas/deployment-assurance-v1.json): Strict non-secret evidence contract for the offline Gate Doctor
- [x402 Gate execution profile](https://mandateshield.com/specifications/x402-gate/v1): Normative exact-request, transmit-once and settlement-proof rules
- [x402 artifact journal schema](https://mandateshield.com/schemas/x402-gate-artifact-v1.json): Customer-side durable signed-payload record contract
- [Gateway adapter specification v2](https://mandateshield.com/specifications/gateway-adapter/v2): Consume recovery, provider-intent lease and provider-input binding
- [Gateway journal schema v2](https://mandateshield.com/schemas/gateway-adapter-v2.json): Machine-readable durable gateway state contract
- [Bounded formal execution model](https://mandateshield.com/evidence/formal-execution-model): Vendor-authored TLA+ state machine plus actually executed finite TypeScript exploration and mutation controls
- [Formal model results](https://mandateshield.com/evidence/formal-execution-model/v1/results.json): Machine-readable bounds, invariant outcomes, mutation detections and explicit proof limitations
- [AP2, x402 v2 and MPP protocol bridge](https://mandateshield.com/tools/protocol-bridge): Documented-field projection with an explicit non-executable assurance boundary
- [Release integrity](https://mandateshield.com/evidence/release-integrity): Human-readable, versioned and hash-verifiable first-party release evidence
- [Release manifest](https://mandateshield.com/evidence/v1.10.0/release-manifest.json): Machine-readable product v1.10.0 hashes, pinned schemas and first-party SPDX SBOM
- [Versioned JavaScript SDK](https://mandateshield.com/sdk/v1.10.0/mandateshield.mjs): Pin this release for production integrations
- [Versioned execution-evidence verifier](https://mandateshield.com/sdk/v1.10.0/mandateshield-execution-evidence-verifier.mjs): Offline ES256 execution-permit and terminal-receipt verification; never grants online submission
- [Execution-evidence verifier declarations](https://mandateshield.com/sdk/v1.10.0/mandateshield-execution-evidence-verifier.d.ts): Exact TypeScript verification contract
- [Versioned gateway adapter](https://mandateshield.com/sdk/v1.10.0/mandateshield-gateway.mjs): Customer-side consume-once coordinator
- [Gateway TypeScript declarations](https://mandateshield.com/sdk/v1.10.0/mandateshield-gateway.d.ts): Exact adapter and journal contract
- [Versioned x402 exact adapter](https://mandateshield.com/sdk/v1.10.0/mandateshield-x402-v2-exact.mjs): Narrow customer-side EIP-3009 execution Gate
- [x402 TypeScript declarations](https://mandateshield.com/sdk/v1.10.0/mandateshield-x402-v2-exact.d.ts): Exact adapter, verifier and artifact contract
- [Release checksums](https://mandateshield.com/sdk/v1.10.0/SHA256SUMS): SHA-256 verification rows for every listed release artifact
- [x402 compatibility evidence](https://mandateshield.com/evidence/v1.10.0/x402-compatibility.json): Tested @x402/core/@x402/evm package versions, separately pinned specification references and explicit limitations
- [x402 compatibility evidence schema](https://mandateshield.com/schemas/x402-compatibility-evidence/v1): Machine-readable first-party claim boundary
- [MCP payment authorization guide](https://mandateshield.com/guides/mcp-payment-authorization): Safe MCP-to-payment integration sequence
- [Agentic payments glossary](https://mandateshield.com/reference/agentic-payments-glossary): Stable definitions for AI systems and developers

## Strict endpoints

- POST https://mandateshield.com/api/v2/sandbox/lifecycle — zero-account, test-only request-local strict lifecycle; no production credentials, external provider, independent organization or money movement
- POST https://mandateshield.com/api/v2/normalize — parse AP2, x402 v2 or MPP source syntax into a non-executable purchase envelope
- POST https://mandateshield.com/api/v2/challenges — issue a one-time live challenge for a registered mandate
- POST https://mandateshield.com/api/v2/verify — verify one signed purchase-authority attempt
- POST https://mandateshield.com/api/v2/batch — verify 1–25 independent strict inputs
- POST https://mandateshield.com/api/v2/execution-authorizations — with an audience-bound PROCESSOR key, CONSUME, COMMIT, RELEASE or EXPIRE one reserved authorization
- POST https://mandateshield.com/api/v2/execution-permits/verify — signature and audience inspection only; always non-executable
- POST https://mandateshield.com/api/v2/execution-permits/redeem — atomically claim the exact permit and provider request; only one fresh claim returns provider submission permission true
- POST https://mandateshield.com/api/v2/provider-submissions — record a provider attempt, independently verify its terminal outcome and return autonomous finalization evidence or a fail-closed reconciliation state
- POST https://mandateshield.com/api/v2/execution-receipts/verify — verify a historical execution receipt; execution_authorized is always false

## Proof Network endpoints

- GET https://mandateshield.com/api/v1/proof-network/proofs — list externally bound self-report summaries; entries are not users, customers or installations
- POST https://mandateshield.com/api/v1/proof-network/challenges — validate claimant-supplied offline-vector outputs and issue a signed domain or GitHub binding challenge
- POST https://mandateshield.com/api/v1/proof-network/attestations — verify the external binding and issue a signed non-authorizing self-report
- GET https://mandateshield.com/api/v1/proof-network/proofs/{proof_id} — retrieve the full signed attestation and caveat
- GET https://mandateshield.com/api/v1/proof-network/proofs/{proof_id}/badge.svg — retrieve the “externally bound self-report” badge; it is not certification
- POST https://mandateshield.com/api/v2/receipts/verify — verify a compact MandateShield receipt
- GET https://mandateshield.com/api/v2/transparency/{receipt_id} — retrieve the privacy-safe, append-only issuance record while retained under the account plan

## Free analysis tools

- [AI Agent Payment Validator](https://mandateshield.com/tools/ai-agent-payment-validator)
- [AI Agent Payment Risk Assessment](https://mandateshield.com/tools/ai-agent-payment-risk-assessment)
- [AI Payment Mandate Builder](https://mandateshield.com/tools/ai-payment-mandate-builder)
- [Cryptographic Authority Verifier](https://mandateshield.com/tools/cryptographic-authority-verifier)
- [AP2, x402 v2 & MPP Protocol Bridge](https://mandateshield.com/tools/protocol-bridge)

These public tools demonstrate policy and signature behavior; they do not establish live execution authority.

## Protocol adapters and paid API scope

MandateShield maps the documented fields of an AP2 terminal closed-payment projection, x402 v2 PAYMENT-REQUIRED offer, or MPP Payment charge challenge into one deterministic envelope. X402 binds canonical network+payTo identity and MPP binds canonical HTTPS service origin+method identity; merchant_id alone is insufficient. Evidence references are bound but not independently fetched or certified. assurance.projection_fields_valid=true is not full source-protocol conformance, and assurance.enforcement_authorized is always false. The protocol bridge itself does not verify the full AP2 chain, create an x402 PAYMENT-SIGNATURE, verify an MPP method credential or settle a payment.

The separate first-party customer-side x402 v2 exact/EIP-3009 Gate adapter can create one payment payload through a customer-configured compatible x402 client only after its documented fresh consume result. Product v1.10.0 tests the exact pinned @x402/core and @x402/evm 2.19.0 client path. The adapter binds a signed application-request projection and MandateShield settlement deadline, reserves 180 seconds for safe expiry proof and release, requires one configured payer plus local signer recovery, and atomically claims network+asset+payer+nonce ownership in one globally shared linearizable customer journal. Before paid transmission it captures the latest canonical block and proves the exact nonce unused through a block-hash-pinned require-canonical query; the complete anchor is persisted with the signed payload. Commit requires a canonical later block whose ancestry includes that anchor and a transaction whose transferWithAuthorization call, nonce, validity window, payer, payee, asset and amount match. Ambiguity is never automatically retransmitted or released. A finalized unused nonce can release only before MandateShield's settlement deadline and only with proof bound to the persisted anchor; later unused evidence remains UNKNOWN and conservatively charged. The runtime requires a GLOBAL_SHARED_LINEARIZABLE journal declaration, but the customer remains responsible for the backing store, verifier correctness and split-brain prevention. Wallets, RPC credentials, payloads and paid resources remain outside the hosted service. This customer-side adapter is distinct from the provider-bound v1.10 permit/redemption handoff and is not external provider enforcement. The narrow profile is not all-x402 support, a facilitator, settlement service, partnership, certification or exactly-once HTTP guarantee.

Strict v2 separately verifies an account-pinned signature over the final envelope. MCP, MPP and x402 transport or negotiate capabilities and payment; none is by itself proof that the exact purchase stayed inside delegated human or enterprise authority.

## Solutions, protocols and threats

- [Payment guardrails for autonomous AI agents](https://mandateshield.com/solutions/ai-agent-builders): Add deterministic spending, merchant, consent and replay controls before a trusted gateway submits an AI-agent payment.
- [Accept AI-agent orders without trusting the model](https://mandateshield.com/solutions/ecommerce-merchants): Reserve authority for autonomous checkout totals, merchant identity and user-approved limits, then require gateway consumption before creating a charge.
- [Policy enforcement for multi-merchant agent checkout](https://mandateshield.com/solutions/marketplaces): Control seller substitution, price drift and replay across marketplace purchases initiated by AI agents.
- [Pre-authorization control for agentic payments](https://mandateshield.com/solutions/payment-providers): Add user-mandate enforcement before payment processing, alongside existing fraud and risk systems.
- [Explainable controls for autonomous transaction authority](https://mandateshield.com/solutions/fintech-compliance): Produce deterministic AI-payment decisions, reason codes and minimal receipts for operational oversight.
- [Payment controls for paid APIs, MCP tools and machine services](https://mandateshield.com/solutions/paid-apis-and-mcp-tools): Authorize provider, resource, exact price and cumulative budget before an AI agent pays for an API call or MCP tool.
- [AI procurement agent spending controls](https://mandateshield.com/solutions/enterprise-procurement-agents): Give procurement agents enforceable supplier scopes, exact transaction limits and concurrent daily or monthly budgets.
- [Stop AI-agent overspend before payment](https://mandateshield.com/threats/ai-agent-overspend): Enforce a hard maximum against the final amount, including checkout changes, fees and currency boundaries.
- [Prevent merchant substitution in agentic checkout](https://mandateshield.com/threats/merchant-substitution): Bind an autonomous purchase to the intended seller or approved merchant scope before execution.
- [Contain prompt injection at the payment boundary](https://mandateshield.com/threats/prompt-injection-payments): Detect instruction-override signals and enforce deterministic payment policy outside the AI model.
- [Enforce consume-once autonomous payment submission](https://mandateshield.com/threats/payment-replay-attacks): Consume each payment decision once with durable idempotency and reject sequential or concurrent replay.
- [Keep AI purchases inside current user consent](https://mandateshield.com/threats/consent-drift): Reject missing, stale or weakly bound authority when checkout facts change after the user delegates a purchase.
- [Stop concurrent AI agents from overspending one shared budget](https://mandateshield.com/threats/concurrent-agent-budget-exhaustion): Use atomic reservations so parallel agent purchases cannot all pass the same stale daily, monthly or lifetime budget check.

## Limitations

MandateShield is not a payment processor, fraud guarantee, sanctions service or card vault. It does not claim an independent certification, third-party audit, customer deployment, financial outcome or accredited industry-standard status unless an identifiable evidence source is published.