Account-controlled authority
Live limits come from an immutable registered mandate version. The agent cannot raise its own cap, expand merchant scope or invent consent in the verification request.
SECURITY ARCHITECTURE
Assume the agent and request can be manipulated.
A live reservation exists only when account-controlled trust, cumulative headroom and durable evidence agree; a separate execution edge must win a fresh claim on the exact bound permit before an idempotent provider attempt.
Pinned issuer trust
A supplied public JWK verifies signature math but establishes no trust. Live execution requires its thumbprint, signed issuer, signed audience and protocol to match an active account pin.
Fresh, exact binding
Signed authority binds the canonical final envelope—or TAP content-digest—to a server-issued, five-minute, consume-once nonce. Signed iat and exp are mandatory for production.
Durable evidence
Account-wide replay tombstones survive API-key rotation. An executable reservation is withheld unless its decision, signed receipt, public transparency record, private execution audit, state record and cumulative-budget allocation all persist atomically.
THREAT COVERAGE
Deterministic failures block. Heuristics pause.
Prompt-override matching is a supplementary heuristic, not a complete prompt-injection detector. The security claim is containment: amount, payee, consent, signature, freshness, budget and replay controls remain decisive even when upstream content or an agent is compromised.
OverspendServer-registered maximum in integer minor units
BLOCKMerchant substitutionServer-registered merchant scope
BLOCKCurrency switchServer-registered ISO currency scope
BLOCKExpired or missing authorityMandate and signed-evidence expiry
BLOCKForged authorityJWS, SD-JWT or HTTP signature verification
BLOCKAttacker-supplied keyAccount-pinned RFC 7638 key thumbprint
BLOCKIssuer or audience swapExact signed claim-to-key registration match
BLOCKPurchase substitutionCanonical digest or TAP content-digest binding
BLOCKChallenge replayFive-minute server nonce consumed once
BLOCKPayment replayDurable account-wide idempotency tombstone
BLOCKConcurrent budget exhaustionAtomic lifetime/day/month reservation
BLOCKAuthorization-token reuseRESERVED-to-CONSUMED compare-and-set
BLOCKVerification-key privilege escalationSeparate VERIFY and PROCESSOR scopes
BLOCKPrompt override languageHeuristic pattern signal; authority remains decisive
REVIEWCross-account abuse signalThree-account privacy threshold; advisory only
REVIEWGateway bypassProvider/facilitator edge must require fresh bound-permit redemption
EXTERNALThe provider-bound production invariant
Strict verification may create a reservation only when decision=ALLOW, enforcement_authorized=true, mode=live, persisted=true, assurance.authority_valid=true and assurance.key_trust=ACCOUNT_PINNED, and when execution_authorization.state=RESERVED with consumable=true. That response still must not call the provider directly. For every account created under the current default, an audience-bound PROCESSOR key must atomically transition the exact signed receipt and envelope with an exact provider binding. That transition issues a short-lived permit while submission remains forbidden. The provider or facilitator execution edge must then freshly redeem the exact permit and request binding online; only the first non-replayed claim unlocks one operation. v1, anonymous, test, caller-supplied-key, offline-verification and replay results are always non-executable.
Execution state and cumulative budgets
Strict verification reserves the candidate amount against every configured LIFETIME, UTC-DAY and UTC-MONTH limit. A successful processor-side CONSUME transition can happen once. COMMIT moves the allocation from reserved to committed; RELEASE or an unconsumed expiry returns it. After the settlement deadline, a consumed authorization with an unresolved provider outcome is conservatively charged to the cumulative budget and never auto-released for another attempt.
VERIFY keys cannot transition state. PROCESSOR keys cannot verify authority and are bound to one exact relying-party audience. This separation limits credential misuse, but it cannot stop a merchant system that bypasses MandateShield and calls its provider directly. The gateway must make a successful CONSUME response a mandatory precondition, then freshly redeem the exact provider-bound permit before attempting the idempotent provider operation.
Provider-bound CONSUME creates a prepared durable submission record and signed permit. A fresh provider-side redemption claims that record for one MandateShield claimant; it does not guarantee exactly-once provider delivery. Reporting the operation stores the caller's observation as a hint, then the hosted reconciliation worker reads the configured Stripe PaymentIntent or x402 chain state without trusting that hint. Only exact, non-conflicting PROVIDER_API_VERIFIED or CHAIN_FINALIZED evidence can autonomously COMMIT or RELEASE with independent_verification=true. Pending, unknown and conflicting evidence remains fail-closed.
The legacy independent_verification field means independent of the caller's assertion. It does not represent an independent organization, provider attestation, certification or audit.
Fail-closed availability posture
If strict verification is unavailable, no new executable reservation is granted. If provider reconciliation is unavailable or ambiguous, the consumed amount remains reserved or is conservatively charged under the documented deadline rules; it is not released for a blind retry. This protects authority but can pause a customer's checkout. Deployments need bounded queues, idempotent recovery and a manual-review path, and must not bypass the boundary by failing open. MandateShield does not claim an independent uptime guarantee or eliminate the availability tradeoff of a hosted control point.
Data boundary
The API needs authorization facts, public verification keys and purchase digests—not card numbers, bank credentials, private keys, full conversations or raw prompts. Public transparency lookups expose fixed receipt and decision digests, not the purchase envelope, merchant identity, account identity or payment credentials.
Receipt portability depends on the corresponding public verification key. Evidence archives should retain the exact public JWK identified by each receipt, not rely only on the mutable live JWKS URL. A versioned, checksum-covered JWKS archive ships with the current release for local retention. It remains first-party material, not independent escrow or a guarantee that MandateShield can provide verification infrastructure indefinitely.
What MandateShield does not claim
The hosted authority-verification route is designed not to collect card or bank credentials; customers must not submit them. It does not submit or settle payments. Optional first-party Gate adapters run inside customer infrastructure, where they may validate payment credentials and submit one bound provider attempt. Separately, hosted reconciliation may use an encrypted, restricted Stripe lookup key or configured x402 RPC solely to verify the stored outcome of that attempt. MandateShield does not provide fraud insurance, perform sanctions screening or replace issuer, acquirer, payment-network, consumer-law or chargeback controls. An executable authorization proves that the supported authority and policy checks passed; it does not prove that a transaction is legitimate in every respect.
A processor_result is a structured assertion made by the customer's trusted adapter and authenticated with its PROCESSOR key. MandateShield checks its exact amount, payee, audience, outcome and reference binding, but it is not independent evidence signed by the payment provider and does not prove settlement by itself.
A correctly signed Stripe webhook is also only CALLER_ASSERTED input and a reconciliation wake-up signal. It is not the trust source for a terminal receipt. The Stripe API lookup performed by MandateShield without trusting the caller report must re-establish the exact account, environment, amount, currency, request and MandateShield metadata bindings before stronger evidence is recorded.
The public specification is a vendor-published open technical contract, not an accredited industry standard. No independent security certification, third-party audit, customer deployment or loss-prevention result is claimed unless an identifiable evidence source is published.
Evaluate the evidence before you trust the product
The buyer and AI due-diligence index grades every public source as an official external record, publicly repeatable first-party evidence, a first-party observation, an externally bound self-report, or absent. It also prevents the unrelated Mandatory Shield/ShieldAD/ADSecure Active Directory product references from being confused with MandateShield.