When the Buyer Is Not Human, the Risk Model Breaks
Every payment risk system in production today is built on one assumption: a human is present at the point of authorization. 3D Secure sends an SMS to a person. Behavioral biometrics track how a person moves a cursor. Chargeback processes assume a person can dispute a transaction.
AI agents do none of these things. When an agent buys the wrong item, pays the wrong amount, or transacts with a fraudulent endpoint, there is frequently no clear record of who authorized what, at which step, and why. That is not a capability gap — it is an infrastructure gap.
TL;DR
Agent payment risk control is the set of mechanisms that make agent-initiated transactions verifiable, attributable, and disputable — by establishing cryptographic proof of user intent before execution and enforcing that intent throughout the transaction chain.
| Core problem | Traditional risk models assume human presence — agents remove that assumption entirely |
|---|---|
| New risk paradigm | Human-Not-Present (HNP) — distinct from Card-Not-Present, requiring different controls |
| Foundational standard | Google AP2 — Payment Mandates as cryptographically signed proof of user intent |
| 4 risk control layers | Agent identity, intent verification, model drift detection, task-chain enforcement |
| Who needs this | Agent developers, merchants accepting agent payments, wallets and payment networks |
Our take: A payment mandate is not a feature. It is the prerequisite for agent commerce to function at scale — without it, no participant in the transaction chain can independently verify whether a payment reflects the user's actual intent.
Why Traditional Risk Control Fails in Agent Payments
Traditional payment security depends on a human being present and accountable at the point of transaction. Agent payments remove that human from every layer:
- No identity signal — agents have no biometric profile, behavioral history, or device fingerprint
- No confirmation step — no one receives a verification code or approves a push notification mid-workflow
- No clear accountability — transactions are recorded under the user's account, but decisions were made by autonomous software
Human-Not-Present is not Card-Not-Present
Card-Not-Present fraud is familiar: a human initiated the transaction, can be held accountable, and leaves behavioral traces. Human-Not-Present is categorically different.
When a user says "buy me a birthday gift," the agent interprets a vague intent, selects a product, and completes a purchase without the user present at any step. The questions this raises have no answer in current fraud frameworks: Did the agent's interpretation match the user's intent? Was the agent's behavior modified by a prompt injection attack mid-workflow? If the merchant delivered what the agent requested but not what the user wanted, who is liable?
Without a mandate framework, every participant in a disputed agent transaction has a defensible position — and none can produce verifiable evidence of what was actually authorized.
What Is a Payment Mandate
A payment mandate is a cryptographically signed digital contract that converts a user's natural language instruction into a machine-verifiable, tamper-proof record of what the agent is permitted to do.
According to the Google Cloud AP2 announcement, the protocol builds trust through Mandates — tamper-proof, cryptographically signed digital contracts that serve as verifiable proof of a user's instructions, creating a clear chain of evidence for every transaction.
AP2 defines two mandate types:
Intent Mandate — created when the user issues an instruction. Captures scope, constraints, and rules of engagement: price limits, timing windows, merchant categories, spending boundaries. As TechCrunch reported, for fully automated purchases where the agent executes without the user present, a detailed Intent Mandate is required upfront, specifying price limits, timing, and other rules of engagement.
Cart Mandate — created when the agent is ready to execute. As Vellum's AP2 breakdown describes, it is a cryptographically signed, unchangeable record of the exact items, price, and shipping information — ensuring what the user sees is what they pay for.
Why mandates alone are not enough
A signed mandate establishes what was authorized. It does not guarantee the agent executed within those boundaries. An agent can still be compromised by prompt injection after signing. A merchant can fail to validate that the cart matches the intent. An agent in a multi-step workflow can drift from its original instructions before the payment step.
The mandate is the foundation — not the complete solution. What it requires is a risk-control execution layer that enforces mandate compliance throughout the transaction chain, not just at the point of signing.
Further Reading: FluxA AEP2 Protocol
The 4 Risk Control Layers for Agent Payments
A mandate defines what was authorized. These four layers enforce that authorization throughout execution — detecting deviation, attributing responsibility, and producing verifiable evidence for dispute resolution.
1. Agent Identity Graph
Agent identity is the foundation of every other risk control — you cannot enforce a mandate, detect fraud, or resolve a dispute without knowing who executed the transaction.
Traditional payment identity is binary: the account holder is authenticated or not. Agent payments require a composite model, because the executing party — the agent — is not the same as the authorizing party — the user.
A complete agent identity layer binds together:
- The verified human principal who authorized the agent
- The agent's registered identity, scope, and purpose
- Deployment context and historical transaction reputation
This is what KYA (Know Your Agent) implements in practice — establishing the agent as a distinct, accountable identity with its own risk weight, authority boundaries, and audit trail. The key design principle: a compromised agent flags the specific node in the identity graph where the breach occurred, rather than invalidating all agents operating under the same principal.
2. Intent Mandate Semantic Layer
The Intent Mandate Semantic Layer converts natural language intent into a minimal, machine-verifiable constraint set — so the agent has a clear boundary to operate within, and the merchant has a clear standard to validate against.
"Buy me a birthday gift under $50" can be satisfied by thousands of products. A mandate that captures this verbatim provides no enforceable boundary. The semantic layer converts it into verifiable constraints:
| Dimension | Example Constraint |
|---|---|
| Budget | Maximum $50, single transaction |
| Timing | Execute within 24 hours of signing |
| Merchant scope | Category: gifts; excluded categories defined |
| Item type | Physical goods only; no subscriptions |
| Frequency | One execution; no repeat authorization |
When the agent attempts to execute, each parameter is checked against the signed mandate. A cart exceeding the budget cap is rejected before payment — not disputed after settlement.
3. Model Drift and AI-Specific Fraud Detection
Model drift detection addresses the risk unique to AI agents: the executing system can change behavior between authorization and payment — without any external attacker involved.
This happens two ways. First, prompt injection: malicious instructions embedded in content the agent processes can silently override mandate parameters before a transaction executes. Second, model drift: accumulated context or instruction conflicts cause the agent's reasoning to diverge from the user's original intent.
Effective detection requires monitoring at the execution layer, not just authorization:
- Pre-payment validation — all transaction parameters checked against the signed mandate immediately before execution; deviations trigger a hard stop
- Prompt injection detection — agent-received content treated as untrusted input; payment destinations set at mandate creation cannot be overridden by runtime content
- Graduated response — low-risk deviations flag silently; medium-risk escalate to user confirmation; high-risk terminate the transaction
4. Task-Chain Risk Enforcement
Task-chain enforcement solves the accountability problem in multi-step workflows: proving that every action the agent took was within the boundaries of the original mandate.
In complex agentic workflows — where an agent delegates subtasks, calls multiple APIs, and makes interdependent decisions — the gap between authorization and execution spans many steps. Task-chain enforcement records each step as a signed, cryptographically linked log entry:
- Every significant API call and decision point is logged with its inputs, outputs, and mandate context
- Each entry is linked to the previous, creating a tamper-evident chain
- The complete chain serves as independent, verifiable evidence in a dispute
The result is not just an audit log. It is an arbitration record — answering not just "what did the user authorize?" but "did the agent stay within that authorization at every step?"
The 4 Layers at a Glance
| Layer | What It Solves | Key Output |
|---|---|---|
| Agent Identity Graph | Who executed the transaction | Attributable, revocable agent identity |
| Intent Mandate Semantic Layer | What was actually authorized | Machine-verifiable constraint set |
| Model Drift Detection | Whether execution matched intent | Pre-payment validation + anomaly escalation |
| Task-Chain Enforcement | Whether every step was in bounds | Tamper-evident arbitration record |
Who Needs Agent Payment Risk Control Now
Agent Developers
Every payment your agent initiates needs a verifiable mandate chain — not because it is required today, but because when a dispute arises, the mandate chain is the only evidence that can exonerate your system from liability.
Key requirement: Mandate signing and task-chain logging before any agent touches a real transaction.
Merchants Accepting Agent-Initiated Payments
An agent presenting a cart inconsistent with its Intent Mandate is a transaction you should reject — not fulfill and dispute later. Merchant-side mandate validation is the last defense before an unauthorized transaction becomes a chargeback.
Key requirement: Validate incoming mandates server-side before order fulfillment.
Wallets and Payment Networks
A transaction carrying verified agent identity, a signed mandate, and a task-chain reference is categorically different from one that carries none of those signals — and should be treated differently at the authorization layer.
Key requirement: KYA-grade identity signals attached to every agent authorization request.
Conclusion
The shift from Card-Not-Present to Human-Not-Present is not an incremental change in fraud risk. It is a structural break — one that removes the assumption every existing risk control system was built on.
As Google's AP2 protocol establishes, this complete sequence — from intent, to cart, to payment — creates a non-repudiable audit trail that answers the critical questions of authorization and authenticity. Payment mandates, backed by cryptographic proof and enforced through identity, semantic, behavioral, and task-chain controls, are the architecture that makes agent commerce trustworthy at scale.
FluxA is building the risk-control execution layer that makes AP2 mandates enforceable in production — combining agent identity, mandate-governed credentials, and protocol-level compliance into a single deployable stack.
Frequently Asked Questions
What is a payment mandate in agent commerce?
A payment mandate is a cryptographically signed contract that records what a user authorized an agent to purchase. It converts natural language intent into a machine-verifiable boundary, giving every transaction participant tamper-proof evidence of what was actually permitted.
How is Human-Not-Present fraud different from Card-Not-Present fraud?
HNP removes the human from every layer of the transaction, not just the physical card. CNP fraud targets human behavior signals; HNP fraud exploits their complete absence — making behavioral detection ineffective and mandate-based verification the only reliable control.
What is AP2 and how does it relate to agent payment risk?
AP2 is Google's open Agent Payments Protocol, announced in September 2025. It defines the Intent and Cart Mandate framework that establishes cryptographic proof of user authorization — the industry standard that agent payment risk control is built on top of.
How does prompt injection affect payment security?
Prompt injection embeds malicious instructions in content the agent processes, silently redirecting payment behavior before execution. Pre-payment validation against the original signed mandate is the primary defense — any deviation from mandate parameters triggers a hard stop before settlement.
What is KYA and how does it work in agent payments?
KYA (Know Your Agent) binds each agent to a verified human authorizer with a defined scope of authority. It ensures every transaction carries attributable agent identity — making disputes resolvable and compromised agents revocable without affecting the broader account.