How Pre-Execution Guardrails Work for Autonomous Payment Agents

Definition and summary

• A pre-execution guardrail is a deterministic control that evaluates a proposed agent payment before executable payment authority is released. It blocks covered payments that fail defined controls.
• The fixed-amount path verifies native authorization before normalizing intent. Policy evaluation and atomic budget reservation occur before exact-payload signing.
• A bound receipt provides independently verifiable evidence for the covered policy evaluation. Settlement records still require separate matching.
• Inherence provides evidence for covered actions routed through the defined enforcement path and evaluated against committed or attested inputs. It does not independently establish the truth of every external input or cover actions executed outside that path.
• AP2 and x402 adapters, signer controls, and budget bindings remain proposed integration architecture rather than demonstrated behavior.

What a pre-execution guardrail is

A pre-execution guardrail is a deterministic control that evaluates a proposed agent payment before executable payment authority is released. Depending on the payment rail, the guardrail sits before wallet signing, credential release, payment initiation, or smart contract execution. The guardrail evaluates formalized payment rules against a verified, typed representation of the proposed transaction. The evaluation can also include committed or attested inputs.

Authorization establishes which principal may act under a defined mandate. Native verification checks the authorization object under the payment scheme’s rules. Policy evaluation determines whether the normalized payment intent satisfies defined controls. Stateful budget control reserves the proposed payment amount against cumulative or time-bound limits before signing. Settlement establishes whether value moved. Monitoring records and analyzes activity, often after a decision or settlement.

Each control answers a different question. A policy gate does not authenticate every principal or establish the truth of external screening data. Monitoring supports investigation but cannot prevent an irreversible payment after value moves.

The fixed-amount path follows one autonomous payment through native authorization verification and normalization. Policy evaluation and atomic budget reservation occur before signing. Native payment verification and settlement matching follow. Receipt binding connects the covered evaluation to the resulting authorization and payment record.

How Inherence fits

Inherence applies this control model to covered actions before execution. It evaluates the mandate’s formalized policy rules and produces evidence that an outside party can verify without receiving the protected inputs encoded in the proof. Proposed payment integrations would place that evaluation before signing, credential release, or initiation. The AP2 and x402 adapters described below remain proposed architecture pending implementation evidence.

Step 1: Verifying native authorization before anything else

In this enforcement path, native verification precedes normalization. A common payment object cannot preserve every protocol-specific security rule.

1. Parse the authorization without changing its signed representation.
2. Identify the protocol version, payment scheme, network, and required verifier.
3. Run the protocol’s native checks against the original object.
4. Reject unknown versions, schemes, or constraints unless an explicit handler can evaluate them.
5. Extract authenticated claims only after native verification succeeds.
6. Record a digest of the original object and the verifier context.

For AP2, the verifier processes the full mandate chain under AP2’s native rules (opens in a new tab). The verifier checks the authority and integrity conditions required by AP2. It also preserves authenticated claims carried forward from open mandates. The verifier evaluates every disclosed constraint against the closed mandate. Unknown constraints fail closed rather than disappearing during normalization.

AP2 also binds the closed Checkout Mandate to the merchant-signed checkout through a cryptographic hash. The linked Payment Mandate carries payment authority for that checkout. A smaller reconstructed object could omit the checkout binding or change how a disclosed constraint is interpreted.

For x402 Exact payments, the verifier applies the registered scheme rules to the native authorization (opens in a new tab). Depending on the network, the signed object may use a token authorization or a network transaction. The normalized payment intent records accepted claims after the applicable verifier validates that object.

The verification order describes a mechanism-level design grounded in published protocol behavior. Native verification operates on the protocol-defined signed representation rather than a locally reserialized substitute. Any Inherence adapter that invokes these checks and passes accepted claims into a shared policy gate remains proposed integration architecture pending implementation evidence.

Step 2: Building the normalized payment intent

After native verification succeeds, an adapter extracts authenticated claims into a typed payment intent. The object records the authenticated payment fields required for policy evaluation. These fields include the payer, payee, amount, asset, network, and expiry. A source digest links the object to the native authorization. The object can also identify the protocol version and native verifier. The normalized intent gives the policy engine a stable schema. It does not replace the original signed object.

Normalization must preserve the original units and identities. The amount remains in the asset’s native atomic units rather than a human-readable approximation. The asset field identifies the specific currency or token. The payee field preserves both protocol identity and settlement address when those values differ. Expiry retains the protocol’s native time semantics. These distinctions prevent a policy check from treating different payment instructions as equivalent.

A collision-resistant digest binds the normalized intent to the exact authorization bytes or protocol-defined reference. The binding also records the verifier context used to accept that authorization. Policy evaluation and the later receipt include the digest. Receipt verification detects a binding mismatch when the presented authorization or normalized object differs from the bound version.

The normalized intent records what the native protocol authenticated. It does not establish facts that the protocol did not authenticate. For example, an authenticated settlement address does not independently establish the legal identity controlling it. AP2 and x402 Exact schemes (opens in a new tab) retain their native authorization rules throughout this path.

Step 3: Policy evaluation against the mandate

Policy evaluation determines whether the authenticated payment intent remains inside the agent’s mandate. Inherence compiles the mandate’s formalized policy rules into deterministic checks. The evaluator applies those checks to typed fields such as the payment amount and payee identity.

Formalized rules express explicit conditions in machine-readable terms. Arbitrary prose cannot enter the enforcement path unchanged. For example, “keep purchases reasonable” requires translation into defined limits or approval conditions. Each condition must define the data and comparison used during evaluation. It must also define the applicable units and failure behavior.

The evaluator can also use attested external inputs. A screening provider might attest to a counterparty status. An identity provider might attest to an eligibility attribute. The enforcement path can verify the attestation and evaluate the encoded value. It cannot independently establish the underlying fact’s truth.

For AP2 payments, this policy check complements AP2’s native constraint evaluation (opens in a new tab). AP2 already evaluates disclosed payment constraints and rejects unknown constraints. An added policy layer can enforce rules shared across protocols or produce privacy-preserving policy evidence. It must not replace AP2’s mandate verification.

A failed evaluation blocks the covered payment before signing or credential release. A passing evaluation admits the exact intent to the budget reservation step. The resulting verdict binds to the policy version and authenticated intent. It also binds to any accepted external inputs used in the evaluation.

Step 4: Atomic budget reservation before signing

A read-only budget check cannot prevent concurrent requests from spending the same remaining allowance. Two requests can read an available balance before either request records its liability. Both can then pass the same check.

An atomic reservation prevents both concurrent requests from reserving the same available budget before signing. One authoritative transaction reads committed and reserved liability. The transaction creates a reservation only when the proposed payment remains within the budget. Every in-scope signing path must use the same authoritative budget ledger.

The proposed budget identity identifies the applicable mandate and principal. It also identifies the policy version, asset, and payment scope. Each logical payment also carries an idempotency key. A repeated key with an identical payload returns the existing reservation. The service rejects the same key when the payload differs. The x402 payment identifier extension (opens in a new tab) applies a similar request-fingerprint pattern to retries.

The reservation also binds to a digest of the exact unsigned payment payload. Before signing, the signer must match every policy-relevant payment field against the reservation. These fields include the payer, payee, amount, asset, network, scheme, and expiry. Payload binding prevents an approved reservation from authorizing a modified payment.

Under the proposed integration for the fixed-amount Exact scheme (opens in a new tab), the budget-reservation state begins as reserved. It moves to authorized when executable payment authority leaves the signer. Native settlement confirmation moves it to settled. An unused reservation can become expired. A failed attempt can become failed. The budget service moves liability to released only after execution becomes impossible. An HTTP failure after signing does not establish that condition.

AP2 defines cumulative budget evaluation and updating (opens in a new tab), but safe concurrency still requires an atomic implementation. The reservation design described here represents proposed AP2 and x402 integration architecture.

Usage-based Upto payments fall outside this fixed-amount path. They require a scheme-specific extension that reserves the authorized ceiling until final settlement or conclusive cancellation.

Step 5: Signing and native payment verification

The proposed signer handoff accepts only the fixed-amount payload bound to an active reservation. The signer checks that the reservation identifier and intent digest match the proposed payment. It also checks the amount, asset, network, recipient, and expiry. Any mismatch stops signing. A consumed, released, expired, or failed reservation also stops signing.

The policy gate controls what reaches the signer. It does not replace the payment scheme’s native verifier. After signing, the applicable verifier checks the resulting authorization under the scheme’s own rules. For x402 Exact (opens in a new tab), that verification covers the native authorization before settlement.

The proposed retry design preserves one executable authorization per logical payment. The same idempotency key and reserved payload must return the existing authorization after a successful signing attempt. A retry must not generate a second executable authorization. A changed payload must require a new reservation rather than reuse the prior approval. This rule prevents transport failures or repeated requests from turning one approved payment into multiple valid payment authorizations.

Step 6: Binding the receipt to the payment

A policy receipt proves that a defined computation produced the recorded result over the inputs bound into the proof. Proof validity alone does not establish settlement, freshness, or acceptance of the correct policy version.

AP2 provides a useful binding model (opens in a new tab). Its Checkout Mandate hashes the merchant-signed checkout object. Its Payment Mandate links back to that checkout. Receipt verification recomputes the referenced hashes.

A proposed policy receipt should preserve those native links. The receipt should bind the policy identifier and version to the normalized intent digest. It should also bind the native authorization digest and reservation identifier. The recorded result and freshness fields require the same binding. The cryptographic proof forms one component of the receipt. The complete receipt must include or reference the verification context.

A verifier must confirm the accepted verification key and its association with the expected policy. The verifier must match the action digest to the presented payment. It must also match the payer, payee, amount, asset, network, and payment scheme. Freshness and replay checks must confirm that the receipt remains valid for the current request. Record-association checks must prevent a valid receipt from being attached to a different payment.

Native payment verification remains necessary after signing. The payment scheme must validate the resulting authorization under its own rules. After execution, the processor confirmation or settlement record must match that authorization. The receipt binds to the authorization. The authorization binds to the settlement record.

Independent verification can support a concrete commercial decision. A payment platform could use the bound evidence when approving a higher agent spending limit, accepting a controlled agent-payment flow, or granting a counterparty access without requiring disclosure of protected policy inputs. Each decision still depends on the relying party’s acceptance rules and the trust boundaries described below.

Trust boundaries: what this path can and cannot verify

Inherence provides evidence for covered actions routed through the defined enforcement path and evaluated against committed or attested inputs. It does not independently establish the truth of every external input or cover actions executed outside that path.

The receipt establishes that the defined policy computation produced the stated result over its bound inputs. Coverage can include the normalized payment intent and policy version. The proved statement can also bind the budget reservation, authorization digest, and freshness fields. The receipt reveals only the claim defined by that statement.

External facts remain outside the proof unless authenticated evidence brings them into the proved statement. Examples include identity attributes, sanctions status, market data, and merchant inventory. The receipt cannot establish settlement unless the proved statement separately includes an authenticated settlement record.

Trust is reduced and relocated, not eliminated. Native protocol issuers and verifiers remain responsible for their authorization rules. Attestation providers remain responsible for supplied inputs. The authoritative atomic ledger remains responsible for accepted budget history. The signer custodian remains responsible for key custody. Policy governance remains responsible for associating approved policies with accepted verification keys. The settlement system remains responsible for its payment records.

A verifier must therefore check the expected policy, verification key, action digest, payment scope, freshness, record association, and replay status. Proof validity alone does not complete those acceptance checks.

Demonstrated mechanism versus proposed AP2 and x402 integration

Inherence (opens in a new tab) describes and demonstrates pre-execution evaluation of covered actions with independently verifiable evidence for those evaluations. The available evidence does not establish an end-to-end AP2 or x402 payment integration.

AP2 adapters, x402 adapters, signer controls, credential-release controls, and atomic budget-service bindings remain proposed integration architecture pending implementation evidence. A proposed AP2 adapter would preserve AP2’s native mandate-chain verification and constraint handling (opens in a new tab). A proposed x402 adapter would use an existing payment-creation hook (opens in a new tab) before signing. The applicable x402 scheme verifier would still validate the resulting payment authorization.

Inherence would serve as a shared policy-enforcement and privacy-preserving evidence layer beside both protocols. It would not replace AP2’s mandate structures or x402’s payment lifecycle. A combined integration would bind both adapters to one logical payment and one atomic budget reservation.

Coverage would remain limited to actions routed through the defined enforcement path. External input sources and authoritative budget state would retain separate trust assumptions.

Preventive controls versus monitoring: a compact comparison

Pre-execution gating can stop an out-of-policy payment before signing or initiation. Monitoring records or detects activity after a decision, execution attempt, or settlement.

Existing controls often combine contractual limits, approvals, multisignature authorization, audit reports, and transaction monitoring. Those controls remain useful, but they cannot retroactively block an irreversible payment after value has moved. A pre-execution gate instead acts like escrow for payment authority. It releases that authority only after the covered conditions pass.

Payment operations often need both control types. Pre-execution gating governs covered actions before execution. Monitoring helps explain failures and detect activity outside the gated path.

How pre-execution systems differ

Pre-execution systems differ in where they intervene and what evidence another party can verify.

The evidence models answer different questions. Newton provides quorum-backed authorization. Predicate provides an attester-backed verdict. Dfns controls wallet signing. Inherence lets an outside party verify that the defined policy computation produced the recorded result for the covered action.

Native authorization and wallet controls remain necessary. Independent policy evidence does not validate every external input, establish settlement by itself, or cover actions outside the enforcement path.

FAQ

Where does a pre-execution guardrail sit?

A pre-execution guardrail sits before executable payment authority is released. The control point may be wallet signing, credential release, payment initiation, or smart contract execution.

What gets verified before payment intent is normalized?

The enforcement path verifies the original authorization object under its native rules. That object may be an AP2 mandate chain (opens in a new tab) or an x402 Exact authorization payload (opens in a new tab). Normalization occurs only after verification succeeds.

What state changes before signing?

An atomic reservation records the fixed payment amount against the applicable budget. The signer accepts only the exact payload bound to that reservation.

Can retries create two payment authorizations?

An idempotency record binds retries to the same reservation and payload. A matching retry returns the existing authorization. A changed payload requires a new evaluation.

What does a policy receipt establish?

A policy receipt provides independently verifiable evidence that the defined computation produced the stated result over bound inputs. The complete receipt identifies the policy version and intent digest. It also identifies the source authorization, reservation, freshness data, and verification context. It does not independently prove settlement or the truth of external inputs.

What falls outside the receipt’s scope?

Inherence provides evidence for covered actions routed through the defined enforcement path and evaluated against committed or attested inputs. It does not independently establish the truth of every external input or cover actions executed outside that path. Settlement requires a separately authenticated record matched to the approved authorization.

Evaluating the mechanism for a payment product

Evaluate pre-execution enforcement against a specific commercial decision involving capital, risk, or access. Identify the covered payment action and the evidence that a counterparty requires for that decision.

Independent verification reduces reliance on operator logs. Trust remains in the formalized policy, accepted verification keys, external input providers, and authoritative budget state. Actions outside the enforcement path remain outside the evidence boundary. The mechanism is relevant when its bounded evidence supports a defined approval, payment limit, or access decision.

Inherence applies this model to covered agent payments by enforcing formalized policy before executable authority is released and producing evidence that an outside party can verify.