An AI agent just initiated a transaction on your customer's behalf. Three seconds later, your fraud team flags it. Who authorized this payment? Which agent made it? What authority did the consumer actually delegate? If you can't answer those questions with cryptographic certainty, you're operating a payment system built on hope.
The OpenID Foundation recently submitted feedback to EMVCo on the EMV® Agentic Payments, Framework for Specifications v1.0 DRAFT, highlighting a fundamental issue: payment and identity standards have evolved separately, and agentic commerce is forcing them to converge. This isn't theoretical. Every agent-initiated payment creates an accountability surface that your current controls probably can't cover.
The Core Issue
EMVCo released a draft framework for agentic payments. The OpenID Foundation responded with detailed technical comments on three areas: accountability mechanisms, agent identity separation from delegated authority, and adversarial threat modeling. The submission included a cover letter and line-item technical feedback from OpenID Foundation experts.
The core issue: EMVCo's draft framework addresses payment mechanics but leaves identity verification and non-repudiation largely undefined. When an agent acts on a consumer's behalf, you need cryptographic proof of two things: what the consumer authorized, and which accountable agent acted within that authority.
Timeline
2025: EMVCo and the OpenID Foundation established a liaison relationship.
Recent: EMVCo published EMV® Agentic Payments, Framework for Specifications v1.0 DRAFT.
Current: OpenID Foundation submitted technical comments, offering three forms of collaboration: due diligence on specifications, terminology alignment, and joint interoperability testing for overlapping use cases.
The timeline is compressed. Agentic payment systems are already in development. If identity controls are bolted on afterward, you'll inherit the same accountability gaps that plague current remote payment systems.
Missing or Failed Controls
The OpenID Foundation's comments identify three control failures in the draft framework:
Missing Verifier role definition: The framework doesn't specify who verifies agent identity or what minimum checks they must perform. Without defined verification requirements, you can't build consistent controls across implementations.
Lack of non-repudiation architecture: Every actor in the payment flow should sign its actions. The draft doesn't mandate this. Result: when a disputed transaction surfaces six months later, you can't prove which agent initiated it or whether it acted within delegated scope.
Absent threat model: The framework doesn't address compromised agents, prompt injection attacks before consent, malicious merchants, replay attacks, or wallet compromise. You're designing for happy-path scenarios while adversaries target the edge cases.
Without these controls, your customer delegates payment authority to an agent. The agent's credentials get compromised. An attacker uses those credentials to initiate fraudulent transactions. Your fraud detection flags unusual activity, but you can't definitively prove whether the legitimate agent was compromised or the customer's authorization was manipulated. You're left with disputes instead of cryptographic evidence.
Relevant Standards
OAuth 2.0 and OpenID Connect already solve parts of this problem for human-initiated flows. The standards establish:
Delegated Authorization: Clear separation between resource owner (the consumer), client (the agent), and authorization server. The agent receives a scoped token, not blanket access.
Proof Key for Code Exchange (PKCE): Prevents authorization code interception. Every Authorization Code Flow includes a cryptographic challenge that ties the token request to the original authorization.
Back-Channel Communication: Sensitive operations happen server-to-server, not through the browser where they're vulnerable to manipulation.
For agentic payments, you need these same principles applied to machine actors:
Agent identity must be verifiable and separate from delegated authority. Every agent needs a persistent identifier that relying parties can validate against signed metadata from the Agent Provider. This is analogous to how OAuth 2.0 separates client registration from user authorization.
Non-repudiation requires signatures at every step. The consumer signs the authorization. The agent signs the payment request. The merchant signs the acceptance. Later, when disputes arise, you have a chain of cryptographic evidence.
Threat modeling must assume adversarial conditions. FIDO2 exists because passwords and SMS codes couldn't withstand phishing attacks. Agentic payment standards need the same adversarial mindset: assume agents will be compromised, prompts will be injected, and merchants will attempt replay attacks.
Action Items for Your Team
If you're building or operating systems that will handle agent-initiated payments, start now:
Map your current delegation model to agent scenarios. How do you currently handle Delegated Authorization? Service accounts? API keys? OAuth clients? Agent payments will expose the same risks at higher volume. Document which controls transfer and which don't.
Define your Verifier role requirements. Before you accept an agent-initiated payment, what checks will you perform? Agent identity validation? Scope verification? Freshness of authorization? Write these requirements into your design documents now, before vendors ship implementations.
Build non-repudiation into your data model. Every payment event needs a signature and a timestamp. Your transaction logs should record not just what happened, but cryptographic proof of who authorized it and who executed it. This isn't optional; it's the only defensible position when disputes escalate.
Threat model the agent compromise scenario. Walk through what happens when an agent's credentials are stolen. Can you distinguish legitimate agent activity from attacker activity? Can you revoke compromised agent access without disrupting legitimate flows? If not, you have a design gap.
Participate in standards work. The OpenID Foundation offered EMVCo joint interoperability testing. If your organization processes payments, you should be in that room. Standards only work when implementers surface real-world constraints early.
The gap between payment standards and identity standards isn't a theoretical concern. It's the difference between a disputed transaction you can prove and one you can't. Agentic commerce will scale quickly. Your controls need to scale with it, and that means building identity verification and non-repudiation into the foundation, not retrofitting them later.
