Present Is Not Provable

Present Is Not Provable

Consider a spend cap. A cap that is present on the wire is a well-formed field that an agent or an intermediary can display. A cap that is provable is one a downstream verifier can show was the cap the mandate authorized. Those are not the same thing.

An intermediary can forward a well-formed payment request whose cap, recipient or expiry no longer matches the authority that issued it. Every field validates. Nothing catches the drift if the checks that ran govern identity and format, while the drift governs behavior.

This is the payment-specific form of a pattern that runs through the series: an authorized agent can still be manipulated, and an authorized payment can be re-priced, re-scoped or replayed after the principal has consented. Identity governance is necessary. It is not where unauthorized payment behavior lives.

Bind the Authority, and Check the Execution Against It

The first step is a binding: a content-addressed reference that ties the authorized parameters, at minimum the amount cap, the recipient and the expiry, to the mandate that issued them, and that travels with the payment into its receipt. A verifier recomputes the binding from the mandate rather than trusting a value an intermediary asserted.

A matching binding is not enough on its own. An intermediary could carry the authentic reference for "up to $100 to merchant A" while executing $500 to merchant B, and recomputing the mandate's hash would still match the copied reference. So the verifier must also authenticate evidence of the actual execution, the amount, currency, recipient and time, link that evidence to the same mandate and transaction, and evaluate it against the mandate's constraints. The question is not "is the mandate reference intact?" It is "does what actually executed satisfy what was actually authorized?"

One precondition decides whether any of this means anything. Execution evidence must come from an authority competent to establish what happened, and the intermediary under scrutiny must not be able to forge that evidence. A component that can write or control the evidence about its own behavior can make that evidence say whatever it sent. Where roles share an operator, the resulting concentration of trust must be explicit. The verifier can then establish the relationship between execution and mandate by evaluating separately authenticated pieces of evidence; no single attestor needs to certify the whole relationship. Enterprises already know the underlying rule as separation of duties: a check carries weight only when it is built from evidence the party under scrutiny cannot forge.

A Precedent from Banking

None of this is new to payments. Under the European PSD2 regime, the regulatory technical standards on Strong Customer Authentication (Commission Delegated Regulation (EU) 2018/389, Article 5) require dynamic linking wherever they apply: the authentication code must be specific to the amount and the payee the payer agreed to, and any change to either invalidates it. The authentication binds the payer's approval to the amount and the payee, rather than to a generic session.

That is the human-principal form of the binding above. This architecture applies the same binding principle to delegated agent authority: where Strong Customer Authentication ties a person's approval to the amount and payee, an agent-initiated payment must also be verifiable against the authority the principal's own policy issued. That is an additional check, not a substitute for whatever authentication obligations already apply to the payment.

That precedent highlights a distinction this architecture must preserve, and it matches the before-and-after rules from Part 5:

• A gate check runs immediately before execution and decides whether the payment may proceed. A commitment created at consent time does not prevent anything by itself; the gate has to compare it against the actual payment about to execute. Done that way, and provided execution uses exactly the parameters the gate checked and the gate cannot be bypassed, it prevents drift.
• A receipt check runs after execution. It detects drift, and it is only as strong as the attestation that chains the receipt back to the consent-time commitment.

A receipt that "reproduces the mandate" can still be weaker than a gate if the executing party reconstructed it after the fact. Enterprises need both: the gate to stop the wrong payment, and the receipt to show, afterward, whether the gate held.

Authority Has a Clock

Part 5 named runtime revocation as an open edge. Payments make it concrete. The authority behind a delegated payment involves three elements, the principal's intent, the mandate and the executed payment, and each has a time.

A mandate captured at one moment does not bind an intent that changes before execution. Consent is revoked, a daily limit is lowered, or a condition the mandate's own rules depend on lapses. A check that replays a mandate without establishing that it is still valid at the moment of execution is testing a snapshot, not the runtime contract. That does not require a live call to the issuer on every payment. It requires a defined revocation boundary: before execution, the gate establishes mandate validity under an explicit revocation and freshness policy, one that defines when a revocation takes effect and how authorization state is coordinated with execution.

Live limits also apply across payments, not only within one. A sequence of payments can each be individually valid and together exceed a daily allowance, and the same authorization can be replayed or executed twice. A gate that checks each payment in isolation misses all three. Replay, duplicate execution and aggregate spending each need their own check against the state of the mandate at execution time. Checking that state is not enough on its own: two $60 payments can each see $100 remaining and both pass. The gate must reserve or consume authorization capacity atomically, so concurrent payments cannot each spend the same remaining allowance, and retries must resolve to the same authorized operation rather than to a new one.

The relationship between intent and mandate is a separate question. AP2, for instance, has the user approve a set of constraints on a non-agentic trusted surface before an agent may act autonomously, which addresses consent capture directly. The methodology in this part assumes that a trustworthy consent process produced the mandate. It does not establish whether that process captured the principal's intent correctly.

Three Things a Tampered-Input Test Misses

Most payment-integrity testing has one shape: send a bad input, expect a rejection. Three failure classes do not fit that shape, and an enterprise evaluating an agent-payment stack should ask about each by name.

Settlement that never lands. In a denial-of-settlement attack, the attacker consumes the resource and then withholds or delays finality, so the payment never completes. There is no bad input to reject; the attack is an absence. The control is to define the settlement condition required before the resource is released. Where a rail or commercial model releases earlier, the enterprise should specify the exposure it accepts and the recovery steps that follow. Revoking future access can limit further loss, but it cannot recover data already downloaded, inference already consumed or a service already performed.

A trusted party in the middle. The realistic threat is often not a malformed request but an authorized intermediary that forwards a well-formed request with a parameter changed in transit: a payment service that raises the cap or broadens the recipient between authorization and execution. Testing for this means simulating the intermediary, not just feeding bad inputs. That is the test I propose for this class; PSD2's dynamic linking supplies the requirement it checks against.

Routes with more than one leg. Real payments cross several parties and retry when they fail. A binding scoped only to the first hop does not establish whether later legs conformed to the mandate. A payee substituted at a later leg, or on a retry under the same mandate, can reproduce the first-hop binding while breaking the authorization. Intermediaries also have legitimate reasons to change a payment in transit, such as currency conversion or fees, so the right property is not "the bytes never changed." It is "the bytes changed only in ways the mandate permits": reject a payee substitution, allow an attested currency adjustment. For retrospective verification, either a binding carried end to end or a terminal attestation checked against the original mandate can establish whether the final payment conformed. Prevention is different: it requires enforcement wherever an authorized parameter can change, before that change becomes an irreversible payment instruction. A terminal attestation that arrives after payment cannot stop a downstream substitution.

What a Payment Receipt Has to Show

The receipt is where the enterprise's audit trail lives, so it carries the same burden as the approval record in Part 5. My companion work, Signing Is Not Authorization, decomposes an action receipt into four separately assessable properties, applied there to agent payments:

A valid signature supports only the first row. The published receipt-claim vectors, action-receipt vectors applied here to payments, make the other three testable, and they split along the same before-and-after line. One vector rejects at admission because the authorization covers different parameters than the action requests. Its pair rejects after execution because the execution acknowledgement does not link to the action that was admitted. A receipt can be correctly signed and fail either one. These vectors are conformance fixtures signed with deterministic test keys; they test a verifier's decisions, not a live payment integration.

What to Require Before an Agent Spends

For a CIO, CISO, treasurer or enterprise architect, the decision is not which payment protocol to adopt. It is what to require of any agent-payment implementation, at each point in a payment's life, before its records can stand as evidence that a payment was authorized.

As in Part 5, ask vendors to demonstrate each requirement rather than describe it. A demonstration against known-good and known-bad cases, with retained evidence, provides evidence for the conditions tested. It is not proof of effectiveness across a whole deployment.

What This Part Does Not Show

The methodology behind this part tests whether the supplied execution evidence supports conformance to the mandate, under its stated assumptions. That is a forensic check; the preventive gate is a separate control. Its reference verifier abstracts production cryptography to test accept-and-reject decisions, so it says nothing about the correctness of a particular cryptographic implementation. It assumes the verifier itself runs faithfully, and it assumes, rather than tests, that a trustworthy consent process produced the mandate. The independence of the attestation is stated as a precondition, not yet checked automatically against a live deployment. The executable interposition mode, a simulated intermediary that alters requests in transit, is specified but remains the main line of future work. The preprints are not peer-reviewed, and no claim of independent validation, certification or adoption is made for them.

About This Series

Identity tells us who requested a payment. Settlement tells us that the payment occurred. The authority layer answers the question that remains: was this the payment the principal actually authorized?

Cite This Part

@misc{saleme2026provable,
  author    = {Saleme, Michael K.},
  title     = {Present vs. Provable: A Conformance-Testing Methodology for the Authority Layer of Agentic Payments},
  year      = {2026},
  version   = {3},
  publisher = {Zenodo},
  doi       = {10.5281/zenodo.23838145},
  url       = {https://doi.org/10.5281/zenodo.23838145}
}