Reserve authority, issue one permit, redeem it at the execution edge.

NORMATIVE EXECUTION RULE

A strict ALLOW reserves authority; it does not move money.

Only strict v2 can create a live execution reservation. A plain ALLOW is insufficient: sandbox, test and v1 results always set enforcement_authorized to false. Even a qualifying live response creates only a short RESERVED authorization. The payment gateway must atomically CONSUME it with an exact provider binding. That response does not authorize the customer or agent to submit. It issues a short signed execution permit that only a customer-deployed exclusive executor may redeem online. Redemption permits one fresh claimant in MandateShield state; it does not guarantee exactly-once provider delivery. The executor must attempt the exact bound operation with provider-native idempotency. Caller-report-independent hosted reconciliation or an explicit manual transition then records the terminal state.

// VERIFY creates a short reservation. It never permits provider submission.
const reservation = requireAllowed(result)
const transitionBase = {
  receipt_id: reservation.signed_receipt.receipt_id,
  compact: reservation.signed_receipt.compact,
  expected_envelope: finalPurchaseEnvelope,
  expected_audience: processorAudience
}

// CONSUME binds one exact provider request and issues a signed permit.
const consumed = await postMandateShield(
  "/api/v2/execution-authorizations",
  process.env.MANDATESHIELD_PROCESSOR_KEY,
  {
  ...transitionBase,
  action: "CONSUME",
  idempotency_key: `${attemptId}:consume`,
  provider_binding: {
    profile: "STRIPE_PAYMENT_INTENTS_V1",
    environment: "live",
    account:
      finalPurchaseEnvelope.payee_identity.binding.merchant_account_id,
    request_id: providerRequestId,
    payee_destination:
      finalPurchaseEnvelope.payee_identity.binding.connected_account_id,
    method: "POST",
    resource: "https://api.stripe.com/v1/payment_intents",
    body_digest: providerBodyDigest
  }
})
if (
  consumed.provider_submission_permitted !== false ||
  consumed.provider_redemption_required !== true ||
  !consumed.execution_permit?.compact
) throw new Error("No provider-bound execution permit")

// Signature-only verification is advisory and never unlocks submission.
const checked = await postPublic(
  "/api/v2/execution-permits/verify",
  {
    compact: consumed.execution_permit.compact,
    expected_audience: processorAudience
  }
)
if (
  !checked.cryptographically_valid ||
  checked.provider_submission_permitted !== false ||
  checked.online_state !== "UNKNOWN"
) throw new Error("Invalid execution permit")

// Run this only inside a customer-deployed exclusive executor.
const redeemed = await postMandateShield(
  "/api/v2/execution-permits/redeem",
  process.env.MANDATESHIELD_PROVIDER_PROCESSOR_KEY,
  {
    compact: consumed.execution_permit.compact,
    idempotency_key: `${attemptId}:redeem`,
    expected_request: {
      provider: checked.claims.provider,
      payee: checked.claims.payee,
      amount: checked.claims.amount,
      resource: checked.claims.resource
    }
  }
)
if (
  redeemed.provider_submission_permitted !== true ||
  redeemed.status !== "CLAIMED" ||
  redeemed.idempotent_replay !== false
) throw new Error("Permit was not freshly redeemed")

// The MandateShield claim is single-winner; provider delivery is not exactly-once.
const outcome = await submitIdempotentlyToPaymentProvider({
  idempotencyKey: redeemed.provider_idempotency_key
})
// The caller report is only a hint. Hosted verification establishes trust.

const report = await postMandateShield(
  "/api/v2/provider-submissions",
  process.env.MANDATESHIELD_PROVIDER_PROCESSOR_KEY,
  {
    provider_submission_id: redeemed.provider_submission_id,
    permit_id: redeemed.permit_id,
    claim_id: redeemed.claim_id,
    payment_reference: outcome.reference,
    outcome: outcome.status,
    occurred_at: outcome.occurredAt,
    provider_observation: outcome.boundedObservation
  }
)
if (
  report.terminal_transition_permitted !== true ||
  report.independent_verification !== true ||
  !["PROVIDER_API_VERIFIED", "CHAIN_FINALIZED"].includes(
    report.evidence_class
  ) ||
  report.authorization_finalized !== true ||
  !report.execution_receipt?.compact
) {
  await queueProviderReconciliation(redeemed.provider_submission_id)
  throw new Error("Provider outcome remains fail-closed")
}
const terminal = report.execution_receipt

SEPARATION OF DUTIES

Use different credentials for verification and execution.

A VERIFY key can issue challenges and call strict verification, but cannot transition an authorization. A PROCESSOR key can call execution transitions and permit redemption and is bound at creation to one exact processor_audience. It cannot issue a challenge or create an authorization. Keep transition credentials inside the trusted gateway. Keep the credential used for redemption inside the customer-deployed exclusive executor with the provider credential and only permitted egress path; never expose either credential to the agent, model, browser, merchant page or verification worker. MandateShield claims no provider or facilitator adoption.

ONE-TIME ACCOUNT SETUP

Register authority before an agent can spend.

In the dashboard, create an active live VERIFY key plus a separate audience-bound PROCESSOR key, register an immutable mandate version and pin the authority issuer's public JWK. Each pinned key records its exact issuer, audience, protocol and RFC 7638 thumbprint. Private keys are rejected. A new mandate version supersedes the prior version without rewriting its historical record; mandates and keys can be revoked independently.

The registered mandate—not limits supplied by the agent—is the production source of truth. Fiat mandates bind currency and a minor-unit cap. Atomic-asset mandates bind the exact asset, network, decimal exponent, atomic-unit cap and paid resources. Both can add lifetime, UTC-day and UTC-month cumulative budgets, and both bind merchants, expiry and the external consent-record reference.

CONCURRENT SPEND CONTROL

Reserve against every configured budget atomically.

A mandate may contain up to one LIFETIME, DAY and MONTH cumulative limit. Fiat limits use positive integer max_amount_minor values; atomic-asset limits use positive canonical string max_atomic_units values. DAY and MONTH boundaries are UTC. Empty limits are omitted; the per-attempt maximum still applies.

"cumulative_budgets": [
  { "period": "LIFETIME", "max_amount_minor": 500000 },
  { "period": "DAY", "max_amount_minor": 25000 },
  { "period": "MONTH", "max_amount_minor": 150000 }
]

Strict verification reserves the candidate amount against all configured counters in the same durable operation as the receipt and replay record. Concurrent attempts cannot both spend the same remaining headroom. COMMIT transfers reserved spend to committed spend; RELEASE or an unconsumed expiry returns it. A consumed outcome that remains unknown after the settlement deadline is charged conservatively to the cumulative budget and never auto-released.

X402 VERIFICATION PROJECTION

Keep atomic amounts exact and bind every substitutable field.

Register an ATOMIC_ASSET mandate in the dashboard, then send atomic_units as a canonical decimal digit string. Production compares that string with the registered max_atomic_units using exact BigInt semantics. Never convert either value to a JavaScript number, floating-point amount, signed string, decimal or exponent notation.

Every X402 envelope must also carry the exact registered asset_id, network, resource and asset_decimals. A change to any one is a substitution and fails closed; decimals are an explicit binding, not a display hint inferred from the asset.

{
  "protocol": "X402",
  "mandate_id": "mnd_api_access_2048",
  "agent_id": "agent_research_07",
  "merchant_id": "merchant_data_api",
  "amount": {
    "atomic_units": "900719925474099312345678901",
    "asset_decimals": 6
  },
  "asset_id": "eip155:8453/erc20:0x833589fcd6edb6e08f4c7c32d4f71b54bda02913",
  "network": "eip155:8453",
  "resource": "https://api.example.test/v1/research/report-7",
  "created_at": "<current ISO-8601 timestamp>",
  "idempotency_key": "x402_report_7_attempt_1",
  "intent_hash": "sha256:example-x402-intent",
  "credential_binding": "issuer:payment-authority:agent_research_07"
}

This object is MandateShield's normalized pre-payment verification projection. It is not an HTTP 402 challenge, payment credential or settlement instruction. MandateShield neither creates the x402 payment signature nor submits it to a facilitator; keep challenge parsing, payment construction and execution in the x402 integration after the complete strict authorization invariant passes.

STEP 1 · FRESH CHALLENGE

Issue a server-bound, consume-once nonce.

Call this endpoint immediately before signing. It requires an active live VERIFY key and an active registered mandate. The nonce expires after five minutes and can be consumed only once for the same account, mandate, protocol and pinned key. Supply the exact RFC 7638 key_thumbprint of that pin. Challenge protocols are AP2, TAP, UCP, X402, ACP and CUSTOM; ANY is available only on a trust-key registration.

curl https://mandateshield.com/api/v2/challenges \
  -X POST \
  -H "content-type: application/json" \
  -H "authorization: Bearer ms_live_..." \
  -d '{
    "mandate_id": "mnd_2048",
    "protocol": "AP2",
    "key_thumbprint": "<RFC 7638 base64url thumbprint>"
  }'

The response returns the selected pin's issuer and audience. Sign those exact returned values; do not substitute a hardcoded service audience.

ACCOUNT-WIDE REPLAY BOUNDARY

Keep one stable key for each intended payment.

Generate a new idempotency_key for each intended payment, then keep it stable across transport retries. The uniqueness boundary is account-wide, not per API key: rotating credentials cannot make a consumed attempt executable again. Reconcile a timed-out request before deciding whether to create a genuinely new attempt. Use distinct, stable idempotency keys for VERIFY, CONSUME and the terminal COMMIT or RELEASE transition, and propagate the attempt identity to your order and provider. The hosted MandateShield service never executes payment and cannot deduplicate a provider charge if the customer Gate bypasses the consume step. Provider-native idempotency therefore remains mandatory.

STEP 2 · STRICT VERIFICATION

Sign the final facts, then verify once.

Submit the exact final purchase envelope and its signed evidence to POST /api/v2/verify. The signed claims must include the challenge nonce, issuer, relying-party audience, iat, exp and the SHA-256 digest of the canonical envelope. The iat–exp window must not exceed 24 hours. The TAP adapter accepts normalized TAP-shaped, RFC 9421-style components with a content-digest binding and maximum 15-minute signature window. Parsing raw Visa structured fields and the full Visa trust-store profile remain external.

const result = await fetch(
  "https://mandateshield.com/api/v2/verify",
  {
    method: "POST",
    headers: {
      "content-type": "application/json",
      "authorization": "Bearer ms_live_..."
    },
    body: JSON.stringify({
      envelope: finalPurchaseEnvelope,
      evidence: {
        format: "jws",
        compact: signedAuthority,
        public_key: issuerPublicJwk
      }
    })
  }
).then(response => response.json())

SUPPORTED EVIDENCE

The supplied JWK verifies math; the account pin establishes trust.

Strict v2 accepts compact JWS, an AP2-shaped closed-payment SD-JWT projection with RFC 9901 KB-JWT, and normalized TAP-shaped RFC 9421-style HTTP-signature evidence using ES256, RS256 or PS256 where the selected format supports it. Passing a public key in a request does not make that key trusted. For live authorization, its RFC 7638 thumbprint, signed issuer, signed audience and protocol must all match an active account registration. Optional expected_* request fields add constraints; they are never trust anchors.

AP2 additionally requires a closed mandate.payment.1 credential whose disclosed amount, currency, payee and transaction binding match the final envelope. Its holder proof is the RFC 9901 KB-JWT. This verifier checks the closed-payment projection only; validation of the checkout_jwt hash, delegate chain, open-mandate constraints and AP2 issuer registry remains external. Unbound, duplicated or colliding SD-JWT disclosures fail closed.

RESPONSE

Decision and execution authority are separate fields.

The response contains ALLOW, REVIEW or BLOCK, stable findings, risk details, mandate version/hash, cryptographic assurance, a signed receipt and its public transparency URI. enforcement_authorized is true only when the live decision is ALLOW, authority is account-pinned, the decision and replay tombstone are persisted, and the receipt transparency and private execution-audit records both commit successfully. In that case execution_authorization.state is RESERVED, consumable is true and the signed receipt is the transition token. These fields do not permit a direct provider call.

Prompt-injection patterns and privacy-thresholded community signals are advisory. They can produce REVIEW, never an automatic community block. Deterministic authority, policy, signature, binding and replay failures produce BLOCK.

PROVIDER-BOUND STATE MACHINE

CONSUME issues; redemption grants; verified evidence finalizes.

Call POST /api/v2/execution-authorizations with a PROCESSOR-scoped key whose bound audience exactly matches the signed receipt and expected_audience. Every request also supplies the exact original envelope, compact signed receipt and a transition-specific idempotency key. Every account created at or after 2026-07-26T12:01:24.000Z must also supply provider_binding for the exact provider account, request, payee, HTTP method, resource and body digest. Only accounts created before that cutoff retain legacy unbound compatibility. Provider-bound CONSUME moves RESERVED to CONSUMED, creates a prepared durable provider submission and issues a signed permit, while returning provider_submission_permitted=false and provider_redemption_required=true. The customer, agent and merchant therefore remain unable to treat CONSUME as submission authority.

// VERIFY creates a short reservation. It never permits provider submission.
const reservation = requireAllowed(result)
const transitionBase = {
  receipt_id: reservation.signed_receipt.receipt_id,
  compact: reservation.signed_receipt.compact,
  expected_envelope: finalPurchaseEnvelope,
  expected_audience: processorAudience
}

// CONSUME binds one exact provider request and issues a signed permit.
const consumed = await postMandateShield(
  "/api/v2/execution-authorizations",
  process.env.MANDATESHIELD_PROCESSOR_KEY,
  {
  ...transitionBase,
  action: "CONSUME",
  idempotency_key: `${attemptId}:consume`,
  provider_binding: {
    profile: "STRIPE_PAYMENT_INTENTS_V1",
    environment: "live",
    account:
      finalPurchaseEnvelope.payee_identity.binding.merchant_account_id,
    request_id: providerRequestId,
    payee_destination:
      finalPurchaseEnvelope.payee_identity.binding.connected_account_id,
    method: "POST",
    resource: "https://api.stripe.com/v1/payment_intents",
    body_digest: providerBodyDigest
  }
})
if (
  consumed.provider_submission_permitted !== false ||
  consumed.provider_redemption_required !== true ||
  !consumed.execution_permit?.compact
) throw new Error("No provider-bound execution permit")

// Signature-only verification is advisory and never unlocks submission.
const checked = await postPublic(
  "/api/v2/execution-permits/verify",
  {
    compact: consumed.execution_permit.compact,
    expected_audience: processorAudience
  }
)
if (
  !checked.cryptographically_valid ||
  checked.provider_submission_permitted !== false ||
  checked.online_state !== "UNKNOWN"
) throw new Error("Invalid execution permit")

// Run this only inside a customer-deployed exclusive executor.
const redeemed = await postMandateShield(
  "/api/v2/execution-permits/redeem",
  process.env.MANDATESHIELD_PROVIDER_PROCESSOR_KEY,
  {
    compact: consumed.execution_permit.compact,
    idempotency_key: `${attemptId}:redeem`,
    expected_request: {
      provider: checked.claims.provider,
      payee: checked.claims.payee,
      amount: checked.claims.amount,
      resource: checked.claims.resource
    }
  }
)
if (
  redeemed.provider_submission_permitted !== true ||
  redeemed.status !== "CLAIMED" ||
  redeemed.idempotent_replay !== false
) throw new Error("Permit was not freshly redeemed")

// The MandateShield claim is single-winner; provider delivery is not exactly-once.
const outcome = await submitIdempotentlyToPaymentProvider({
  idempotencyKey: redeemed.provider_idempotency_key
})
// The caller report is only a hint. Hosted verification establishes trust.

const report = await postMandateShield(
  "/api/v2/provider-submissions",
  process.env.MANDATESHIELD_PROVIDER_PROCESSOR_KEY,
  {
    provider_submission_id: redeemed.provider_submission_id,
    permit_id: redeemed.permit_id,
    claim_id: redeemed.claim_id,
    payment_reference: outcome.reference,
    outcome: outcome.status,
    occurred_at: outcome.occurredAt,
    provider_observation: outcome.boundedObservation
  }
)
if (
  report.terminal_transition_permitted !== true ||
  report.independent_verification !== true ||
  !["PROVIDER_API_VERIFIED", "CHAIN_FINALIZED"].includes(
    report.evidence_class
  ) ||
  report.authorization_finalized !== true ||
  !report.execution_receipt?.compact
) {
  await queueProviderReconciliation(redeemed.provider_submission_id)
  throw new Error("Provider outcome remains fail-closed")
}
const terminal = report.execution_receipt

A fresh redemption admits one non-replayed claimant for that durable provider submission. The customer-deployed exclusive executor must then attempt the exact operation with the returned provider idempotency key; MandateShield does not guarantee exactly-once provider delivery. Report the returned provider_submission_id, permit_id, claim_id, exact payment reference and caller outcome to POST /api/v2/provider-submissions. The report is stored as CALLER_ASSERTED evidence; it is a hint, not authority for a terminal transition.

For a configured Stripe PaymentIntents connection, MandateShield reads the exact PaymentIntent from the Stripe API without trusting the caller report. For configured x402 exact settlement, it checks the canonical chain, confirmation depth and exact transfer bindings. Only non-conflicting PROVIDER_API_VERIFIED or CHAIN_FINALIZED evidence can autonomously COMMIT or RELEASE and return a signed receipt with independent_verification=true. Pending, unknown or conflicting observations remain fail-closed and continue reconciliation; they never authorize a retry or release.

Direct COMMIT and RELEASE remain available for manual processor integrations. Their supplied processor_result is authenticated by the PROCESSOR key and bound to the payee, audience, amount and provider reference, but remains CALLER_ASSERTED with independent_verification=false. If submission may have happened but its result is unknown, do not RELEASE or submit again.

{
  "payment_reference": "pay_9f22a1",
  "outcome": "COMMITTED",
  "payee": "merchant_rail",
  "audience": "https://checkout.example.com/payments",
  "occurred_at": "<current ISO-8601 timestamp>",
  "amount": {
    "minor_units": 12490,
    "currency": "USD"
  }
}

For atomic assets, the amount assertion instead repeats the exact atomic_units, asset_decimals, asset_id, network and resource. No numeric conversion is allowed.

OFFICIAL DURABLE JOURNAL

Back every Gate worker with one PostgreSQL primary.

The first-party PostgreSQL implementation replaces the application-defined globalLinearizableGatewayJournal placeholder. It implements the Gateway v2 DurableGatewayJournal contract with one explicit SQL migration, atomic insert-if-absent, primary reads and version-plus-state compare-and-set. The adapter accepts a customer-supplied query interface and has no PostgreSQL driver dependency.

import { Pool } from "pg"
import {
  createPostgresGatewayJournal
} from "@mandateshield/sdk/gateway/postgres"

const journal = createPostgresGatewayJournal({
  database: new Pool({
    connectionString: process.env.GATE_DATABASE_URL
  }),
  namespace: "checkout.production"
})

// Fails closed on a replica, read-only session, unsafe durability
// setting, missing migration or incompatible schema.
await journal.checkReadiness()

const gateway = createMandateShieldGateway({
  journal,
  mandateShield: processorClient,
  provider: providerAdapter
})

The database, connection credential and journal rows remain in customer infrastructure and are not sent to MandateShield. Every process and region must reach the same writable, actually linearizable PostgreSQL primary. checkReadiness() inspects the connected server, transaction mode, synchronous-commit setting and installed schema; it does not attest routing, replication or failover. Split-brain writers are unsafe.

This is the generic Gateway coordination journal. It does not replace the x402 Gate's separate encrypted signed-payload artifactJournal, which stores a payment credential under a different contract.

FRESH PROVIDER-BOUND CLAIM

Redeem the signed permit online at the execution edge.

The ES256 MSP+JWT permit binds the decision and attempt digests, audience, provider profile/account/request, generated provider idempotency key, payee, exact amount and exact resource. Its maximum lifetime is 60 seconds and max_uses is one. A customer-deployed exclusive executor holding the live PROCESSOR credential for the exact signed audience must send the complete compact permit and the exact provider, payee, amount and resource claims to POST /api/v2/execution-permits/redeem.

The first-party Gateway requires a canonical payee_identity for its provider profile and derives the exact provider destination from the signed final envelope. A merchant label alone cannot unlock that path.

Only a response with provider_submission_permitted=true, status=CLAIMED and idempotent_replay=false grants one fresh claimant in MandateShield state. It does not prove or guarantee that the provider receives the operation exactly once. The executor must attempt the exact operation with the returned provider_idempotency_key, which was generated and signed by MandateShield. An exact redemption retry returns the same claim with permission false; a different replay is rejected.

Local JWKS verification and POST /api/v2/execution-permits/verify validate the signature and optional audience only. They report online state unknown, one-use enforcement false and provider submission permission false. Offline verification can never grant execution. MandateShield claims no provider or facilitator adoption. The redemption contract enforces a provider boundary only when the customer deploys it as the exclusive credential holder and blocks alternate provider egress.

SIGNED TERMINAL EVIDENCE

Every terminal transition returns an execution receipt.

COMMIT, RELEASE and EXPIRE transitions return an ES256 MSE+JWT execution receipt; the system can use the same artifact for a conservative SETTLEMENT_UNKNOWN terminal record. It binds the decision receipt, optional permit, exact payment context, transition, terminal state, outcome and evidence digest. The receipt declares artifact_purpose=HISTORICAL_EXECUTION_EVIDENCE and execution_authorized=false; it can never be reused to authorize another operation.

A manual COMMIT or RELEASE records authenticated customer PROCESSOR evidence as CALLER_ASSERTED with independent_verification=false. Caller-report-independent hosted provider reconciliation can instead issue a terminal receipt with PROVIDER_API_VERIFIED or CHAIN_FINALIZED and independent_verification=true, but only after the configured Stripe API or x402 chain verifier confirms the exact bound outcome without trusting the caller report. This is not an independent organizational audit. A signed Stripe webhook is still only a caller hint and wake-up signal; it is not the trust source for that stronger evidence.

STRICT V2 BATCH

Verify up to 25 independent attempts.

Send 1–25 { envelope, evidence } objects to POST /api/v2/batch. Every item follows the same strict verifier and needs its own idempotency key and unconsumed challenge. The summary separately counts reserved authorizations; never treat the HTTP status of the batch as payment approval. Every qualifying item creates its own budget reservation, so consume the intended items promptly and release any confirmed non-submissions.

INDEPENDENT VERIFICATION

Verify the decision receipt and its public issuance record.

Receipts are ES256 JWS objects containing input and decision digests, assurance, mandate binding, relying-party audience and execution-authority state. Verify the compact receipt with POST /api/v2/receipts/verify or the public JWKS. The pinned offline verifier performs the same signature and digest checks locally; verify its bytes against SHA256SUMS. Resolve /api/v2/transparency/:receipt_id to compare its privacy-safe receipt hash and digest bindings. The public record is append-only while retained, not a claim of a Merkle ledger. For long-term verification, retain the exact public JWK named by the receipt with your evidence archive. The mutable live JWKS is a current first-party source, not independent key escrow or a continuity guarantee. A valid signature alone is not an execution switch: send the exact expected_envelope and expected_audience. Only enforcement_ready=true confirms that both match the signed receipt and its transparency record. Receipt verification and archival preserve evidence; they do not authorize a new or replayed payment. Provider submission permission comes only from the original strict decision, its processor-side CONSUME and one fresh online redemption under the complete invariant.

PUBLIC BINDING NOTARY

Bind an external self-report without turning it into certification.

The no-account Proof Network binds one complete offline conformance self-report to either a public HTTPS origin or one exact public GitHub commit. Create a signed challenge with POST /api/v1/proof-network/challenges, publish the returned DNS TXT value or fixed repository proof file, then call POST /api/v1/proof-network/attestations. Published records are available from GET /api/v1/proof-network/proofs and their stable proof URLs.

DNS verification confirms control at verification time through the exact TXT record; MandateShield does not fetch or test the HTTPS service. Repository verification retrieves only the fixed /.well-known/mandateshield-proof.json file from the supplied 40-hex commit. The signed result always labels itself EXTERNALLY_BOUND_SELF_REPORT with issuer_role=BINDING_NOTARY, independently_verified=false and certification=false. It proves subject binding and report integrity only—not claimant-code execution, a security audit, production use, or adoption.

DUAL-ERA MCP COMPATIBILITY

One stateless endpoint serves current and legacy clients.

POST https://mandateshield.com/api/mcp supports the stateless MCP 2026-07-28 server/discover flow. Modern requests bind their protocol version, method and named tool or resource in HTTP headers and repeat the protocol version plus client capabilities in request metadata. Responses are complete, private and non-cacheable by protocol instruction.

The same URL retains initialize-based compatibility for MCP 2025-11-25, 2025-06-18 and 2025-03-26. The server remains stateless in both eras and issues no MCP session ID. Transport compatibility does not change authority: MCP exposes no PROCESSOR transition, permit-redemption, provider-submission or payment-execution tool.

ANALYSIS-ONLY PROFILE

v1 evaluates policy but cannot authorize payment.

POST /api/v1/preflight, its batch endpoint and the check_ai_payment_authority MCP tool remain useful for testing and diagnostics. They always return enforcement_authorized=false, including with a live key. Use them to explain policy outcomes—not as an execution gate.

HTTP STATUS

Transport failures and non-executable decisions fail closed.

In plain language, an unavailable strict-verification service grants no new execution authority. An unavailable or ambiguous outcome check leaves the authorization reserved and forbids a blind provider retry. This can pause checkout or hold budget. Integrators should queue safely, retry only idempotent MandateShield requests, and route prolonged uncertainty to manual review; they must not switch to fail-open payment submission.