As AI agents start buying things for consumers, payment infrastructure has a new question to answer: was the transaction within the authority the consumer actually granted?
A payment can be valid without being permitted.
01 · The regulatory signal
A new signal from Europe
On November 11, 2026, the European Commission published its proposal for a Digital Fairness Act, a set of consumer-protection rules for digital commerce. Article 26 covers automated systems that conclude contracts on behalf of consumers.
Businesses that offer such systems would have to let consumers set and change their authorization preferences. On first use, the consumer chooses whether to confirm every contract, only contracts that meet criteria they set (such as a maximum price), or none at all. The proposal also covers commercial conflicts of interest and a durable confirmation of the consumer's choices.
When an agent buys on a consumer's behalf, those preferences have to be checked as part of the transaction.
02 · The practical problem
A valid payment can still exceed the consumer's authority
Imagine a consumer asking an AI shopping agent to buy running shoes. The instructions are simple: spend no more than €150, buy only from approved retailers, and sign up for no memberships or subscriptions.
The agent finds the shoes for €120 at a retailer outside the approved list. The payment credentials are valid, the merchant accepts the order, and the payment processor authorizes it. Every technical check passes, and the purchase still breaks the consumer's approved-retailer rule.
Scenario A / Retailer restriction
€120
Shoes from an unapproved seller
Below the price cap, from a seller outside the approved list.
Scenario B / Prohibited subscription
€90
Shoes plus €12/month membership
The lower upfront price comes with a recurring commitment the consumer ruled out.
Both payments might succeed even though the overall purchase violates the consumer's instructions.
In the second scenario, the agent goes for the lowest upfront price and signs the consumer up for a €12 monthly membership they had ruled out.
Neither scenario involves fraud, stolen credentials or a payment network fault. Card authorization checks credentials, authentication, available funds and acceptance. None of those checks knows what the consumer told the agent.
03 · The authority boundary
Mandates need an enforcement point
In agentic commerce, a mandate is the authority a consumer delegates to an agent (a different thing from a direct-debit mandate): what it may buy, from whom, under which conditions, and when it must ask for approval.
A mandate might set price thresholds, approved merchants, transaction categories, an expiry date, or a ban on recurring commitments. Writing those rules down does not make an agent follow them.
Distinct responsibilities
Delegated authority
What the consumer allows
Runtime policy decision
Does this action comply?
Payment execution
Process only after required checks
These controls have to hold across agent platforms, merchants and payment providers, even when each one handles a different part of the transaction. Enforcement cannot rely on the agent reading its own instructions correctly.
04 · Engineering the control
What runtime enforcement must evaluate
A spending limit is simple to check when the amount and currency are known. Other controls are harder. Merchant restrictions need a reliable seller identity. Recurring commitments need the full contract terms, including what happens after the first charge. Revocation, expiry and cumulative spending need current, authoritative state.
For the unapproved-retailer example, the runtime decision fits in a short record:
- Proposed action
- €120 shoes from an unapproved retailer
- Active mandate
- €150 cap, approved retailers only, no subscriptions
- Decision
- BLOCK: retailer is outside the approved list
- Evidence
- Mandate version, merchant, evaluated conditions, decision, timestamp
A block and a hold are different outcomes. Some constraints forbid the purchase outright; others let the consumer grant extra permission. If critical transaction information is missing, or the enforcement point itself is unavailable, the system needs an explicit failure policy (block or hold) that is designed into the payment path. A merchant whose identity cannot be confirmed is treated as unapproved.
A control holds up in production only if it meets three requirements:
The reliability test
- 01
No ungoverned execution path
Protected actions must pass through enforcement. If an agent can pay through an alternate route, the policy is bypassable.
- 02
Authoritative, current state
Revocations, cumulative limits, and concurrent transactions cannot be governed reliably with stale policy snapshots.
- 03
Decision bound to execution
The executed payment must match the approved merchant, amount and terms. Reconciliation catches any mismatch afterwards; an approval log alone does not show the match.
05 · Conflict-aware authorization
When the agent has a financial incentive
The proposal also covers commercial conflicts of interest. Under Article 26, the agent would have to disclose any payment its provider receives for proposing a contract and any conflict of interest with the merchant, and the consumer would have to confirm that contract whatever their default approval setting.
Imagine an agent whose provider earns a commission for recommending one retailer over another. The purchase may sit inside the consumer's €150 limit, and the commission still adds an approval step.
A runtime control can read declared commissions or sponsorship metadata, require the disclosure to be shown, and hold the transaction until the consumer approves. It can then keep the disclosed relationship, the approval and the final decision on record.
Enforcement only sees the relationships that are declared. It cannot discover an undisclosed commission on its own, so it depends on accurate declarations, ideally reconciled against independent records.
06 · Verifiable consumer mandates
Proving what the consumer actually authorized
A correctly enforced decision can still be hard to investigate later. Suppose a consumer disputes a purchase and asks for a refund. The merchant says it was permitted, the agent provider says the rules were followed, and the payment processor confirms the charge was accepted.
What was the consumer's mandate at the time, and what exactly did the agent attempt?
The record should keep the authorization choices with their effective dates and revisions, the transaction attributes that were evaluated, and any extra approval the consumer gave.
The verifiable record
- Mandate snapshot
- Who authorized what, under which version
- Transaction context
- Merchant, price, terms, and requested action
- Enforcement outcome
- Allow, block, hold, and approval evidence
- Integrity proof
- Hash-chained records and trusted timestamps that anyone can check
Hash chains, trusted timestamps and independently verifiable evidence packages show whether a record was changed after it was written. That lets an investigator reconstruct what the system evaluated and enforced. Whether every input was true, and whether the authorization was legally valid, are separate questions.
Article 26 also requires the business to send the consumer a confirmation of their authorization settings on a durable medium (a record the consumer can keep and reopen unchanged, such as an email or a PDF). An evidence platform can produce and preserve those confirmations; the business still has to deliver them to the consumer in a form they can keep.
07 · The larger shift
Building trust into agentic commerce
AI agents will deal with retailers, subscription services, marketplaces and payment providers more and more without a consumer watching each step, so the controls have to work without someone watching too. The same pattern applies inside financial institutions, where treasury and procurement agents act within approval limits.
Consumers need a clear way to delegate authority, and businesses need enforcement they can rely on. When a purchase is disputed, everyone needs evidence of the terms in effect and of what the agent did.
At Meilynx, we work on this with runtime policy enforcement that sits outside the agent and evidence that anyone can verify. Governance stays the same whichever agent or payment provider is involved.