Snapshot status: immutable product release v1.13.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.13.0
OpenAPI contract snapshot: v3.4.0
Boundary specification snapshot: v2.4.0
Released and generated: 2026-07-28T14:25:22.000Z
Authoritative current-release pointer: https://mandateshield.com/current-release.json
Immutable OpenAPI: https://mandateshield.com/openapi/3.4.0.json
Immutable AI index: https://mandateshield.com/llms/1.13.0.txt
Immutable full AI context: https://mandateshield.com/llms-full/1.13.0.txt
Immutable discovery manifest: https://mandateshield.com/discovery/1.13.0.json
Agent payment authority discovery: https://mandateshield.com/.well-known/agent-payment-authority.json
Agent payment authority lifecycle discovery: https://mandateshield.com/.well-known/agent-payment-authority.json
Agent payment authority discovery schema: https://mandateshield.com/schemas/agent-payment-authority-discovery/v1
Agent payment authority discovery specification: https://mandateshield.com/specifications/agent-payment-authority-discovery/v1
The profile publishes the canonical new-account lifecycle resolve_authority → reserve → consume → redeem_once → verify_outcome → retain_proof, its exact pre-cutoff legacy compatibility boundary, executable HTTP/OpenAPI contracts, MCP/A2A authority-check and strict-reservation surfaces, a common receipt schema across supported profiles and the account emergency execution interlock. MCP/A2A expose no PROCESSOR transition, permit redemption, provider submission or payment execution. The lifecycle state contract is provider-profile-independent; terminal outcome checking currently supports only configured Stripe PaymentIntents and the documented x402 EIP-3009 profile. The canonical order is required for accounts created at or after 2026-07-26T12:01:24.000Z and for missing or malformed account-creation evidence, and recommended for every integration. Only accounts created before that cutoff retain the non-recommended legacy unbound CONSUME path, which may return direct permission without redeem_once; callers must not infer legacy eligibility. It is published by MandateShield and does not establish an accredited industry standard, independent certification, external-agent or provider adoption, or provider enforcement.
Account-owner emergency interlock: GET or POST https://mandateshield.com/api/account/execution-interlock
Global execution interlock specification: https://mandateshield.com/specifications/global-execution-interlock/v1
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 hint and reconciliation independent of caller assertion: 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
Deploy & Prove guided flow: https://mandateshield.com/launch
Deployment activation proof directory: https://mandateshield.com/deployment-proofs
Deployment activation proof list: GET https://mandateshield.com/api/v1/deployment-proofs
Deployment activation proof JSON template: GET https://mandateshield.com/api/v1/deployment-proofs/{proof_id}
Deployment activation proof badge template: GET https://mandateshield.com/api/v1/deployment-proofs/{proof_id}/badge.svg
Deployment activation proof specification: https://mandateshield.com/specifications/deployment-activation-proof/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
Primary AP2-to-Stripe last-mile profile: https://mandateshield.com/integrations/ap2-to-stripe
Installable Stripe adapter: @mandateshield/sdk/gateway/stripe-payment-intents
The adapter binds the Stripe connected account, PaymentMethod and exact URL-encoded form-body digest into the fresh execution permit. Caller-independent configured lookup reconstructs that body binding and keeps substitutions, unavailable results and conflicts nonterminal.
Node.js install: npm install https://mandateshield.com/packages/npm/1.13.0/mandateshield-sdk-1.13.0.tgz
Python install: python3 -m pip install --index-url https://mandateshield.com/packages/python/simple mandateshield==1.13.0
Go install: GONOSUMDB=github.com/mandateshield/mandateshield-go GOPROXY=https://mandateshield.com/packages/go go get github.com/mandateshield/mandateshield-go@v1.13.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
Optional x402 v2 exact compatibility profile: https://mandateshield.com/integrations/x402-v2-exact
Pinned JavaScript SDK: https://mandateshield.com/sdk/v1.13.0/mandateshield.mjs
Pinned execution-evidence verifier: https://mandateshield.com/sdk/v1.13.0/mandateshield-execution-evidence-verifier.mjs
Execution-evidence verifier TypeScript declarations: https://mandateshield.com/sdk/v1.13.0/mandateshield-execution-evidence-verifier.d.ts
Pinned gateway adapter: https://mandateshield.com/sdk/v1.13.0/mandateshield-gateway.mjs
Gateway TypeScript declarations: https://mandateshield.com/sdk/v1.13.0/mandateshield-gateway.d.ts
Pinned x402 exact adapter: https://mandateshield.com/sdk/v1.13.0/mandateshield-x402-v2-exact.mjs
x402 TypeScript declarations: https://mandateshield.com/sdk/v1.13.0/mandateshield-x402-v2-exact.d.ts
Release checksums: https://mandateshield.com/sdk/v1.13.0/SHA256SUMS
Release manifest: https://mandateshield.com/evidence/v1.13.0/release-manifest.json
x402 compatibility evidence: https://mandateshield.com/evidence/v1.13.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
Current deployment assurance schema: https://mandateshield.com/schemas/deployment-assurance-v2.json
Legacy deployment assurance v1 schema: https://mandateshield.com/schemas/deployment-assurance-v1.json
PostgreSQL DurableGatewayJournal guide: https://mandateshield.com/integrations/postgres-gateway-journal
Pinned PostgreSQL journal JavaScript: https://mandateshield.com/sdk/v1.13.0/mandateshield-postgres-gateway-journal.mjs
Pinned PostgreSQL journal declarations: https://mandateshield.com/sdk/v1.13.0/mandateshield-postgres-gateway-journal.d.ts
Pinned PostgreSQL journal migration: https://mandateshield.com/sdk/v1.13.0/mandateshield-postgres-gateway-journal.sql
Rolling PostgreSQL journal JavaScript: https://mandateshield.com/sdk/mandateshield-postgres-gateway-journal.mjs
Rolling PostgreSQL journal declarations: https://mandateshield.com/sdk/mandateshield-postgres-gateway-journal.d.ts
Rolling PostgreSQL journal migration: https://mandateshield.com/sdk/mandateshield-postgres-gateway-journal.sql
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, grants only one fresh online claim, persists ProviderSubmission/ProviderEvidence/ReconciliationRecord state, checks configured Stripe PaymentIntent or canonical x402 chain outcomes without trusting the caller report, autonomously finalizes terminal budget state and returns an ES256 terminal Execution Receipt. A fresh claim is not an exactly-once provider-call guarantee; credential isolation, provider idempotency and reconciliation remain mandatory. 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 MandateShield authority to attempt the idempotent provider operation. This single-winner MandateShield claim is not an exactly-once provider-delivery guarantee. The service must retain provider_submission_id. An exact retry returns the same claim with permission false; a different replay is rejected with HTTP 409.
11. Attempt exactly the signed request using the returned provider_idempotency_key and retain the stable non-secret payment_reference when the provider returns one.
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 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 without trusting the caller report. A Stripe webhook must pass raw-body signature, freshness and event-replay checks, but remains only a scheduling hint before that caller-independent API lookup. This is not an independent organization, certification or audit.
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.

## Official PostgreSQL Gateway journal

The first-party PostgreSQL module implements the Gateway v2 DurableGatewayJournal begin, get and compare-and-set interface over mandateshield_gate.gateway_journal_v1. It accepts a customer-supplied query object compatible with a node-postgres Pool or Client and has no driver dependency. Its versioned SQL migration is applied separately by a database-owner migration role; the runtime module does not migrate, retry, delete, log or connect to a payment provider.

The PostgreSQL database, connection credential and journal rows stay in customer infrastructure and are not sent to MandateShield. Use a dedicated runtime role with schema USAGE, SELECT, INSERT and UPDATE only on version, state, record and updated_at. The journal must not contain card data, bank credentials, wallet private keys, provider secrets or signed payment credentials.

Every process and region for one Gate binding must use the same writable, actually linearizable PostgreSQL primary. checkReadiness requires PostgreSQL 14+, READ COMMITTED, a read-write non-recovery connection, synchronous_commit on/remote_write/remote_apply and the exact constrained schema. The check does not attest connection routing, replication, failover fencing or global topology; topology_attested is always false. A split-brain or replica-read deployment is unsafe, and the namespace is collision isolation rather than an authorization boundary.

This module is the generic Gateway coordination journal. The x402 exact adapter separately requires an encrypted signed-payload artifactJournal because that record is a payment credential; the PostgreSQL Gateway journal does not replace that contract. The module is first-party reference code, not managed storage, topology certification, an independent audit or adoption evidence.

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.13 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 without trusting that assertion; a matching terminal result is stored as PROVIDER_API_VERIFIED or CHAIN_FINALIZED with the legacy field independent_verification=true and can drive an autonomous SYSTEM transition. That field means independent of the caller assertion, not an independent organization or audit. 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 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, a customer-deployed credential-isolated execution 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 operator declaration without making network requests. It reports one cumulative v2 level: UNVERIFIED, SDK_ONLY, CREDENTIAL_ISOLATED, OPERATOR_DECLARED_EGRESS_CONTROLS or OPERATOR_DECLARED_PROVIDER_OUTCOME_CONTROLS. Current deterministic production-readiness output requires OPERATOR_DECLARED_PROVIDER_OUTCOME_CONTROLS and zero failed controls, but that label means only that the submitted declaration satisfies the current Doctor controls. MandateShield does not inspect the deployment or independently audit the evidence, and no payment provider attests to that level.

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 Stripe/x402 terminal reconciliation without trusting the caller assertion, but that mechanism becomes external enforcement only at a customer-deployed execution service that actually requires it. Gate is the customer-controlled credential and submission boundary. OPERATOR_DECLARED_PROVIDER_OUTCOME_CONTROLS records a Doctor-accepted operator declaration, not provider enforcement, technical inspection or attestation, 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 success or failure checked without trusting the caller from 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.

## Account-bound server-observed deployment activation proofs

The guided flow at https://mandateshield.com/launch is account-bound and legally gated. After authenticated acceptance of the current terms, it accepts an HTTPS-domain or a public GitHub repository at the exact current HEAD of its default branch, verifies DNS TXT control or the exact binding file at that default-branch HEAD, applies the external-subject eligibility checks, creates a one-use, seven-day activation entitlement, and bootstraps separate narrowly scoped live VERIFY and PROCESSOR credentials plus one trusted P-256 authority key and a fixed USD 0.01 mandate. The signed account-bound binding challenge carries no publication direction. A fork-only object, pull-request ref, or non-default-branch commit does not satisfy the GitHub binding. The private authority key remains in the participant-controlled deployment bundle; MandateShield receives only the public JWK.

The participant runs the published deployment-proof runner outside mandateshield.com. The mutable release pointer https://mandateshield.com/launch/runner-release.json names the current immutable versioned runner and its SHA-256 checksum. That runner performs exactly one server-observed strict live reservation, provider-bound CONSUME for the GENERIC_HTTP_V1 test profile, and one fresh credential-bound permit redemption. The official runner contains no client that calls the bound resource or any payment provider; exact retries only recover the same idempotent chain. When the hosted database matches the exact account, entitlement, VERIFY key, PROCESSOR key, trusted key, mandate, authorization and claimed permit chain, the pilot may complete privately without creating any public record. Publication is optional and separate: only a fresh finalization request with publication_consent=true may issue the signed public proof. Omission, false consent, or private completion alone never publishes.

GET https://mandateshield.com/api/v1/deployment-proofs lists signed ACCOUNT_BOUND_SERVER_OBSERVED_ACTIVATION records. GET https://mandateshield.com/api/v1/deployment-proofs/{proof_id} returns the exact proof; GET https://mandateshield.com/api/v1/deployment-proofs/{proof_id}/badge.svg returns its bounded badge; and https://mandateshield.com/deployment-proofs/{proof_id} is the human-readable record. The normative semantics are at https://mandateshield.com/specifications/deployment-activation-proof/v1.

The positive claim is limited to external-subject control verified at the record's exact binding.verified_at time, one strict live reservation observed by the MandateShield server, and one fresh redemption of the exact credential-bound execution permit. Final proof issuance does not re-verify subject control. Every proof states mandateshield_provider_submission_observed=false, mandateshield_provider_enforcement_observed=false, provider_evidence_recorded=false and independent_terminal_evidence_verified=false. These are scoped MandateShield observations; activity outside MandateShield is outside the proof. The eligibility classifier excludes known MandateShield/Hemelion domains, repository owners and matching account-email domains, but operator_exclusion_no_match_at_evaluation=true means only that no configured exclusion matched at eligibility.evaluated_at; final proof issuance does not rerun that classifier, and the result is not independent identity or independent-organization verification. No customer, revenue, runtime-inspection, non-bypassability, audit, certification or security-guarantee claim follows.

This record is materially different from a Proof Network entry. The Deployment Activation Proof is account-bound and the strict reservation plus permit redemption are server-observed, while a Proof Network entry is an externally bound claimant-supplied conformance self-report whose execution is not independently run. Neither record establishes payment execution, provider enforcement, a customer, revenue, audit or certification.

## 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.13 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.13.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 retrieves that exact transaction and receipt from a configured EVM RPC endpoint without trusting the caller report, 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 compatibility profile, not the product's primary differentiation or external provider enforcement. Native x402/EIP-3009 already supplies payment authorization, value/payee/validity/nonce binding and facilitator settlement primitives. MandateShield 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.

The MCP endpoint supports the stateless 2026-07-28 protocol through server/discover and per-request protocol, method and named-tool/resource binding plus client-capability metadata. It also retains initialize-based compatibility for 2025-11-25, 2025-06-18 and 2025-03-26. The server issues no MCP session ID in either era. Protocol compatibility does not add execution authority: neither flow exposes a PROCESSOR transition, permit-redemption, provider-submission or payment-execution tool.

## 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
- One fresh MandateShield redemption; retry false and conflicting replay rejected; provider idempotency remains required
- Durable ProviderSubmission, ProviderEvidence and ReconciliationRecord state machines
- Signed Stripe webhook replay protection as scheduling evidence, never terminal proof
- Exact Stripe PaymentIntent API lookup and x402 canonical-chain confirmation independent of caller assertion
- 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 provider/chain evidence checked without trusting the caller is true
- First-party customer-controlled PostgreSQL DurableGatewayJournal with atomic begin/compare-and-set and bounded readiness checks
- RESERVED, CONSUMED, COMMITTED, RELEASED, EXPIRED and conservative unknown-settlement states
- Advisory-only prompt and community signals

## Outcome verification for AI agents using Stripe or x402

Bind a supported provider request, grant one fresh online permit claim, and verify the terminal outcome without trusting the calling agent's report.

Audience: Teams with existing Stripe PaymentIntent or supported x402 EIP-3009 execution code that can isolate payment credentials behind one exclusive executor.

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 permits with one fresh server-side claim, Configured provider reconciliation independent of caller assertion, Signed intent and purchase binding.

Outcome: On the supported path, the caller cannot finalize success merely by reporting it; MandateShield checks the configured Stripe record or canonical chain evidence and keeps UNKNOWN reserved.

## 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, Configured provider reconciliation independent of caller assertion, 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: For an architecture that forces its supported payment path through the Gate, one account policy can mediate multiple sellers 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, Configured provider reconciliation independent of caller assertion, Signed receipts and transparency lookup.

Outcome: An integrator can add a normalized agent-authority boundary without claiming complete conformance with every labeled protocol.

## 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, Configured provider reconciliation independent of caller assertion, 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

Assume instruction overrides can succeed, use heuristic signals only for review, and contain payment impact with deterministic policy outside the 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: MandateShield does not claim complete prompt-injection detection; hard authority controls limit what a manipulated agent can authorize through this boundary.

## Enforce consume-once authority before payment submission

Consume each MandateShield decision once, reject a second permit redemption, and preserve provider idempotency as a separate requirement.

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

Risk: Network retries, duplicated tool calls and malicious replay can attempt the same authorized purchase more than once. In-memory deduplication does not survive restarts or coordinate regions, while MandateShield redemption alone cannot guarantee provider-side deduplication.

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.

## Mediate the AI-payment authorization-to-execution gap

Bind an approved autonomous purchase to one supported provider request, one fresh online permit claim and an outcome checked by MandateShield without trusting the caller report.

Audience: Teams with existing Stripe PaymentIntent or supported x402 EIP-3009 execution code that can isolate credentials behind one exclusive executor.

Risk: Between a detached preflight ALLOW and the provider call, another component can replace the payee, amount, resource or request body; concurrent workers can race; and an ambiguous provider response can cause a blind retry. A policy decision and post-hoc logs do not by themselves mediate that transition.

Controls: Exact request-digest binding, Provider and payee binding, Atomic consume-once permit claim, Provider idempotency binding, Shared cross-mandate budget reservation, Fail-closed unknown outcomes, Supported-provider reconciliation independent of caller assertion, Signed decision and terminal receipts.

Outcome: On the supported paths, the authorization remains linked to one exact provider attempt instead of becoming a reusable ALLOW that downstream code must interpret correctly.

## 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.