The Agent Was Authorized. The Purchase Wasn't.
Authorized agentic fraud, and why a clean transaction can still be the wrong one
Agentic commerce introduces an unusual risk. A legitimate customer can authorise a legitimate agent, and still end up disputing the purchase it makes.
Picture a simple instruction. A customer tells an AI agent: “Restock the office and keep the total under $500.” The agent finds a merchant, selects products, and completes a $480 order. The payment is valid. The customer’s account is legitimate. The agent was genuinely authorised. The transaction passes conventional fraud checks.
There’s only one problem: the order includes a premium espresso machine the customer never intended to buy.
Was that fraud? A product mistake? Poor instructions? Or an authorised purchase that quietly exceeded the customer’s actual intent? Agentic commerce is manufacturing a category of risk the payment ecosystem still lacks a settled name for. A useful one is authorised agentic fraud - and it’s the name we use here. Treat it as an emerging risk to understand now, not a widespread fraud pattern that’s already here.
Authorisation is not a blank check
Traditional fraud systems are built to answer familiar questions. Was the card stolen? Was the account compromised? Does the transaction look abnormal? Is automated traffic attacking the checkout?
Agent-driven purchases introduce a different question entirely: did this agent have permission to make this particular purchase?
An agent can be authentic while its action is inappropriate. A user may authorise an agent but limit its authority - by amount, product category, merchant, location, or time. The agent may misread an ambiguous instruction, keep operating after permission has changed, or be compromised after receiving legitimate access. In each case the credentials look clean and the transaction looks successful. It’s only later that the disagreement surfaces, when the customer says: “I authorised the agent, but I did not authorise this.”
Two conditions, not one
The concept only earns credibility if it’s defined precisely. Not every mistaken agent purchase is fraud. The technical condition has to be separated from malicious conduct, or the term collapses into “any agent order a customer regrets.”
Agentic authorisation mismatch
A transaction initiated by a validly identified agent, under a valid delegation, where the proposed transaction violates, exceeds, or cannot be proven consistent with the delegation’s scope. This is a technical state. It says nothing about intent.
Authorised agentic fraud
An authorisation mismatch that involves intentional manipulation, a compromised delegation, deceptive instructions, or deliberate exploitation of authorisation ambiguity. Fraud is the subset of mismatch where intent turns a scope problem into an attack.
Model error, vague instructions, and buyer’s remorse are mismatches, not fraud. Keeping the two apart is what makes the category defensible rather than alarmist.
The mismatch has a compact formal shape:
Agent identity: valid Principal-agent delegation: valid Payment credential: valid Transaction matches mandate: no / indeterminate Step-up approval: absent
The first three conditions are exactly why conventional fraud controls approve the transaction. The fourth is the new risk, and today almost nothing at checkout is actually evaluating it.
Identity is only the beginning
Knowing the identity of an agent is useful. Establishing its authority to transact takes more than identity. For an agent-driven order, a merchant eventually needs to understand more than who showed up:
Who operates the agent, and who does it claim to represent?
And is that relationship verifiable, rather than merely asserted?
What was the agent permitted to purchase?
Were there spending, category, merchant, or geography restrictions on this delegation?
Was the permission active when checkout occurred?
Delegations get revoked. Revocation that arrives after fulfilment isn’t worth much.
What evidence survives if the order is disputed?
Two weeks later, can the merchant show what authority was actually presented at checkout?
Merchants shouldn’t have to interpret pages of natural-language instructions at checkout. Authorisation needs to become structured enough for merchant systems to evaluate it against policy - and the result should support a practical decision: accept, review, or decline.
The dispute happens after the clean transaction
Authorised agentic fraud is difficult precisely because it looks legitimate at the moment it happens. The agent logs in correctly. The payment succeeds. The shipping address is familiar. The customer previously approved the agent. Two weeks later, the customer disputes the order.
Without a checkout record, the merchant is left reconstructing the transaction from payment data, application logs, and conversations between systems outside its control. A useful record would show what agent appeared, who it represented, what authority it presented, which merchant policy was applied, and why the transaction was accepted.
That record won’t settle every dispute or decide legal liability. It will, however, give merchants something better than a folder of screenshots and a theory.
From bot detection to authority decisions
The future of commerce won’t divide neatly into good bots and bad bots. Merchants will meet all three of these at once: authorised agents performing authorised actions, compromised agents performing malicious ones, and legitimate agents exceeding unclear or outdated instructions. Detecting automation separates them from humans, not from each other.
The merchant risk infrastructure that comes next therefore has to do more than notice that an agent is present. It has to help establish whether the agent is authorised for this merchant, this transaction, and this moment.
What KYA does about it
This is the problem we built KYA around, and the pieces are already in production. Every verified agent presents a signed KYA trace at checkout - an Ed25519 envelope that binds a principal, an operator, an action scope, an amount limit, an audience, and a validity window. That’s the structured authorisation a merchant can actually evaluate against, instead of a paragraph of instructions.
When a transaction diverges from that authority, our pre-dispute side-channel already speaks in mismatch terms: reason codes like SCOPE_EXCEEDED, AMOUNT_EXCEEDED, and WRONG_ITEM name the exact dimension that failed - before it becomes a chargeback. And because we now translate KYA traces into AP2 mandates, that scope check can run inside an AP2-aware risk engine without a bespoke integration.
Our approach is to make the scope decision explicit and to preserve it. In our design, the merchant normalises whatever authorisation the agent presents into a common mandate, compares the proposed transaction against every dimension of that mandate, and then writes a signed evidence receiptrecording the inputs, the per-dimension results, the policy version, and the decision. Missing authorisation is never silently treated as authorisation - “unspecified” and “unverifiable” are first-class outcomes, not rounding errors.
The payment may be valid. The agent may be real. The purchase can still be wrong - and a merchant should be able to prove which of those it checked.
We’ve written up how to build this on the merchant side - normalising the mandate, matching the transaction field by field, a decision state machine, JSON schemas, the request/response contract, worked examples, and a threat model. If you want the mechanics rather than the narrative, that’s the one to read next.
Prepare for agent disputes before they arrive
KYA gives merchants a structured authorisation to check at checkout, a per-dimension scope decision, and a signed record of why an agent order was accepted. Let us show you what that looks like on your checkout.
Request a Demo