Software agents will soon be spending your money. The question isn't whether this will happen, but whether you and your team will have the controls to prevent unauthorized purchases when it does.
EMVCo released a draft framework for card-based agentic transactions in early 2025, inviting feedback by Sept. 30. The document, titled "EMV Agentic Payments, Framework for Specifications," addresses a problem most compliance teams haven't tackled yet: how do you verify intent when a piece of code, not a human, initiates the transaction?
The framework focuses on managing consumer intent over time, particularly for recurring purchases. But releasing a draft standard is the easy part. Implementation is where teams often make costly mistakes.
Why These Mistakes Keep Happening
Agentic commerce intersects three domains most organizations manage separately: payment security, fraud monitoring, and identity verification. Your PCI team thinks about cardholder data. Your fraud analysts focus on transaction patterns. Your IAM team handles authentication. But nobody's considering how an autonomous agent fits into all three.
The result: teams apply existing controls to a fundamentally different transaction model. You can't just add Multi-Factor Authentication to an agent that's supposed to operate without human intervention. You can't rely on behavioral analytics when the "behavior" is algorithmic, not human.
Mistake 1: Treating Agent Authorization Like User Authentication
Your team applies the same authentication controls to agents that you use for human cardholders. You require MFA, set session timeouts, and flag "unusual" login patterns.
This happens because it's what you know. Your authentication stack was built for humans logging into applications. When someone says "autonomous agent," you hear "another user account."
The consequence: your controls either block legitimate agent activity or create security gaps. An agent authorized to reorder office supplies every Monday doesn't need MFA each time, but it does need bounded spending authority. Session timeouts designed for humans make no sense for an agent that might wait three weeks between transactions.
The fix: Separate agent authorization from user authentication. EMVCo's framework introduces the concept of managing intent over time through "a common coordination point." Build your controls around scope and limits, not login patterns. Define what the agent can purchase (category codes), how much it can spend (per-transaction and cumulative limits), and when its authority expires (time-bounded delegation).
For recurring purchase agents, implement transaction-level attestation. The agent doesn't authenticate; it presents a credential that proves it's operating within previously authorized parameters.
Mistake 2: Ignoring the Shared State Problem
You treat each agent transaction as independent, applying the same fraud rules you use for card-not-present purchases.
This happens because your fraud monitoring system was built for discrete transactions. It looks at velocity, geolocation, and device fingerprints, signals that assume each transaction is a separate decision by a human cardholder.
The consequence: you either generate false positives (flagging legitimate agent behavior as suspicious) or miss actual fraud (because the agent's pattern looks "normal" even when it's been compromised). An agent authorized to buy cloud storage might legitimately make 50 purchases in an hour during a migration. A compromised agent might make one fraudulent purchase that perfectly mimics its normal pattern.
The fix: Implement intent state management. EMVCo's framework specifically addresses situations where "intent needs to be managed over time" with "a shared intent 'state' that persists across multiple participants." This isn't just logging, it's maintaining a verifiable record of what the agent was authorized to do.
Build monitoring rules that compare transactions against the original authorization scope, not against behavioral baselines. If an agent authorized to purchase "cloud storage services" (MCC 7372) suddenly buys electronics (MCC 5732), that's a scope violation regardless of transaction amount or velocity.
Mistake 3: Skipping Agent Identity Verification
You assume that if the payment credentials are valid, the agent is legitimate. You verify the card, not the code making the purchase.
This happens because your payment gateway doesn't have a mechanism to verify agent identity. The transaction looks like any other API call with valid credentials.
The consequence: a compromised or rogue agent can drain accounts before you detect the problem. Your fraud rules trigger on transaction patterns, not on whether the entity making the purchase is the entity that was authorized.
The fix: Implement what EMVCo calls "Know Your Agent." This isn't a metaphor, it's a technical requirement. Before you process agent transactions, verify the agent's identity using cryptographic attestation.
Require agents to present verifiable credentials that prove:
- The agent's identity (cryptographic signature tied to the original authorization)
- The scope of its authority (what it's allowed to purchase)
- The delegation chain (who authorized it and when)
EMVCo is collaborating with the FIDO Alliance and OpenID Foundation on interoperable standards for this. Don't wait for the final specification to start planning. Identify where in your payment flow you'll verify agent credentials, and what you'll do when verification fails.
Mistake 4: Failing to Implement Transaction-Level Indicators
You process agent transactions through the same payment rails as human-initiated purchases, with no distinction in the authorization message.
This happens because your payment processor doesn't support agentic transaction indicators. The ISO 8583 message looks identical whether a human or an agent initiated the purchase.
The consequence: issuers can't apply appropriate risk controls. They don't know they're authorizing an agent transaction, so they can't verify it against the cardholder's agent authorization settings. Chargebacks become disputes about whether the agent was authorized, with no transaction-level evidence.
The fix: Plan for Agentic Transaction Indicators in your authorization messages. EMVCo has flagged this as a future framework feature. When it arrives, you'll need to:
- Tag agent-initiated transactions in authorization requests
- Include the agent's identity and scope in supplemental data fields
- Route agent transactions through risk engines that understand delegated authority
Start now by identifying which transactions in your environment are already agent-like (subscription renewals, auto-reorders) and how you'd mark them if you had the technical capability.
Mistake 5: Treating This as a Future Problem
You're waiting for final standards before you build anything. EMVCo's framework is a draft. The FIDO Alliance collaboration is ongoing. You'll implement controls when the specifications are complete.
This happens because you're managing competing priorities. Agentic commerce feels theoretical compared to the PCI DSS v4.0 requirements you need to meet this year.
The consequence: you'll be implementing agentic payment controls under deadline pressure, without time to test or train your team. When EMVCo publishes final specifications, you'll have months, not years, to comply if you're processing agent transactions.
The fix: Start building your framework now, even if the standards aren't final. The core requirements won't change: you'll need to verify agent identity, manage intent over time, and monitor for scope violations.
Build your technical foundation:
- Identify where agent transactions would enter your payment flow
- Define how you'll store and verify authorization scope
- Create monitoring rules for intent violations
- Document your agent authorization process
EMVCo's Sept. 30 feedback deadline isn't just for standards bodies. If you're processing payments at scale, submit comments based on your operational reality. The final specifications will be more useful if they reflect what compliance teams can actually implement.
Prevention Checklist
Before you process your first agentic transaction:
□ Define agent authorization separately from user authentication, scope and limits, not login patterns
□ Implement intent state management, verify transactions against original authorization, not behavioral baselines
□ Establish agent identity verification using cryptographic attestation before processing payments
□ Plan for transaction-level indicators in authorization messages, even if your processor doesn't support them yet
□ Create monitoring rules that detect scope violations (agent purchasing outside authorized categories)
□ Document the delegation chain for every agent, who authorized it, what it can purchase, when authority expires
□ Build a process for revoking agent credentials that's faster than your standard card cancellation workflow
□ Test your chargeback process for agent disputes, can you prove the transaction was within scope?
□ Identify which of your current transactions are already agent-like and how you'd mark them
□ Submit feedback to EMVCo by Sept. 30 based on your operational constraints
The standards are coming. The technology exists. The only question is whether you'll implement controls before you process agent transactions, or after you process the first unauthorized purchase.
