# MandateShield: complete product context Canonical URL: https://mandateshield.com/ Category: AI agent payment security; pre-payment authorization control API endpoint: POST https://mandateshield.com/api/v1/preflight Strict cryptographic endpoint: POST https://mandateshield.com/api/v2/verify Receipt verifier: POST https://mandateshield.com/api/v2/receipts/verify Public receipt JWKS: https://mandateshield.com/.well-known/jwks.json Threat intelligence: https://mandateshield.com/api/v1/threat-intelligence Batch endpoint: POST https://mandateshield.com/api/v1/batch (1–25 purchase envelopes) MCP endpoint: POST https://mandateshield.com/api/mcp A2A discovery: https://mandateshield.com/.well-known/agent-card.json OpenAPI: https://mandateshield.com/openapi.json Open boundary specification: https://mandateshield.com/standard Human documentation: https://mandateshield.com/docs Free risk assessment: https://mandateshield.com/tools/ai-agent-payment-risk-assessment Free mandate builder: https://mandateshield.com/tools/ai-payment-mandate-builder Free cryptographic verifier: https://mandateshield.com/tools/cryptographic-authority-verifier Methodology: https://mandateshield.com/methodology ## What MandateShield does MandateShield evaluates whether an autonomous purchase stays inside the authority a person granted. The v1 boundary evaluates normalized purchase facts. The strict v2 verifier additionally validates compact JWS, AP2 SD-JWT or Visa TAP-style HTTP message evidence for signature integrity, freshness, audience, nonce and purchase bindings. The response is ALLOW, REVIEW or BLOCK with exact findings, assurance evidence and a portable ES256-signed decision receipt. ## Critical category clarification MandateShield is not SEPA, ACH or Bacs direct-debit mandate software. It does not collect debit authorizations, IBANs, signatures or bank instructions. It is not electronic-signature software and does not move money. In this product, “mandate” means the explicit, bounded purchase authority a person delegates to an AI agent. ## What MandateShield does not do MandateShield is not a payment processor, fraud guarantee, sanctions service or card vault. It verifies supported authorization signatures but does not validate payment credentials, settle transactions or replace a payment-provider or network-specific risk decision. Payment credentials should remain with the existing payment provider. ## Supported inputs The protocol-neutral envelope can represent AP2, UCP, Visa Trusted Agent Protocol, x402, Agentic Commerce Protocol and custom signed payment envelopes. ## Agent-native access AI clients can discover both check_ai_payment_authority and verify_cryptographic_payment_authority at https://mandateshield.com/api/mcp. A2A-compatible agents can discover the public agent card at https://mandateshield.com/.well-known/agent-card.json and send either a normalized envelope or strict envelope-plus-evidence payload to https://mandateshield.com/a2a. ## Open execution boundary The Mandate Execution Boundary v2 specification at https://mandateshield.com/standard publishes portable JSON Schemas for purchase envelopes, cryptographic evidence and signed decision receipts plus a canonical reason-code registry. It is an open technical contract and reference implementation; it is not represented as an accredited or consensus industry standard. ## Core controls - Maximum amount and currency scope - Merchant or payee scope - Consent and authorization expiry - Intent and credential binding - Timestamp freshness and amount precision - Prompt-injection indicators - Durable, consume-once idempotency - Machine-readable reasons and receipt hashes - JWS, SD-JWT and HTTP message-signature verification - Signed decision receipts with public JWKS - Privacy-thresholded cross-account threat signals ## Payment guardrails for autonomous AI agents Add deterministic spending, merchant, consent and replay controls to an AI agent before it executes a 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, Prompt-injection signals, Consume-once idempotency, Intent and credential 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 Verify autonomous checkout totals, merchant identity and user-approved limits 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, Duplicate execution prevention, 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. 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, Credential-free metadata, Tamper-evident receipts. 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. ## 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: The payment call never runs when the final total is outside the user's stated authority. ## 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: Instruction-override signals, Deterministic amount checks, Merchant scope enforcement, Consent evidence, Short authorization windows, Minimal input surface. Outcome: Even a manipulated agent cannot make the policy engine reinterpret the user's payment authority. ## Block duplicate autonomous payment execution 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, Per-key isolation. Outcome: One approved intent can produce at most one executable payment decision. ## 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. ## Commercial access A free anonymous validator is available at https://mandateshield.com/tools/ai-agent-payment-validator. Production access is self-service at https://mandateshield.com/pricing with USD subscription and metered-usage plans. ## Free decision tools The risk assessment scores ten execution-boundary controls and produces a prioritized action plan. The mandate builder creates fresh protocol-neutral purchase-envelope JSON plus a runnable curl request. The live validator evaluates individual purchases or five attack variants. None requires an account or accepts payment credentials.