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 is 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 does not yet have a settled name for. A useful one is authorised agentic fraud - and it should be treated as an emerging risk to understand now, not a widespread fraud pattern that is 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. The disagreement only surfaces later, 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 is 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, but identity alone does not establish transaction authority. 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 is worth very little.
What evidence survives if the order is disputed?
Two weeks later, can the merchant show what authority was actually presented at checkout?
Merchants should not 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 does not look like fraud when 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 it does not 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 will not 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 will not 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 does not tell them apart.
The next generation of merchant risk infrastructure therefore cannot stop at noticing 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 KYA is built 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 trace is the structured authorisation a merchant can actually evaluate against, instead of a paragraph of instructions.
When a transaction diverges from that authority, KYA's 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 KYA now translates its traces into AP2 mandates, that scope check can run inside an AP2-aware risk engine without a bespoke integration.
KYA's approach is to make the scope decision explicit and to preserve it. 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 receipt recording 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 wrote 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, read it 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