When your AI assistant places an order, who's really authorizing that transaction? This question is no longer theoretical. As autonomous agents handle tasks like grocery reorders and subscription renewals, payment systems face a critical challenge: proving the human behind the AI intended to make that purchase.
Verifiable Intent, a framework released by Mastercard and Google, presents a choice familiar to Privileged Access Management (PAM) engineers: require explicit authorization for every action, or trust the agent once and let it operate within set boundaries.
Continuous Biometric Verification
Verifiable Intent requires a biometric check before each transaction. Consumers establish intent through a FIDO Alliance-compliant passkey interaction, creating a cryptographic record that includes their verified identity, the instruction given to the AI, and the resulting transaction. Without this step, there's no payment authorization.
This model treats every AI-initiated transaction as a privileged action needing fresh proof of human intent. It's akin to the Just-in-Time Elevation pattern in commerce: standing authorization is a vulnerability, real-time verification is the control.
The security benefits are clear. If an attacker compromises your AI agent's session, they can't complete purchases without your biometric input. The cryptographic bundle provides an audit trail linking every transaction to a specific moment of human authorization. In disputes, you're not debating whether your agent had general permission. You're examining a tamper-resistant record of what you authorized and when.
For high-value or sensitive transactions, this friction is likely worth it. Your AI booking a $3,000 flight should require the same level of verification as logging into your bank vault to transfer funds. The biometric step prevents scenarios where a misconfigured instruction or compromised agent drains your account while you sleep.
The framework's selective disclosure mechanism addresses privacy concerns. Each party in the transaction chain receives only the minimum data needed: merchants verify authorization, issuers check fraud patterns, and dispute systems review the cryptographic record. No single participant sees everything, limiting exposure if one component is breached.
Delegated Authorization with Boundaries
The opposing view sees continuous biometric checks as unnecessary security theater. If you must manually approve every transaction, you haven't truly delegated anything. You've just added steps to a process you could complete yourself.
This perspective advocates for a different model: establish trust boundaries once, then let the agent operate within those constraints. Authorize your AI to spend up to $50 per transaction on recurring household items, or to book travel within specific date ranges and price limits. The agent acts autonomously until it hits a boundary, at which point it requests elevation.
This approach is akin to Policy-Based Access Control for commerce. You're defining what the agent can do, not authenticating every action. The security focus shifts from continuous verification to robust boundary enforcement and anomaly detection.
Consider a scenario where your AI handles subscription renewals, restocks household items, and books your regular commute parking. If each action requires biometric approval, you're interrupting your day multiple times for routine $15 transactions. The friction eliminates the benefit of automation.
From an architectural standpoint, this model also simplifies recovery. If a biometric authentication system fails, Verifiable Intent-style frameworks can't process payments. Your AI is effectively stalled until the service recovers. Boundary-based delegation fails more gracefully: the agent continues operating within established limits, and only elevated actions queue for later approval.
The fraud detection argument is nuanced. Continuous biometric checks prevent unauthorized transactions, but they also generate so much authentication noise that you might stop paying attention. When every coffee reorder requires your thumbprint, you're more likely to approve things reflexively. Attackers know this. Social engineering shifts from "click this link" to "approve this routine transaction" while you're distracted.
Balancing Both Approaches
Most PAM engineers implementing AI payment systems will likely want both models available, triggered by transaction context. Routine, low-value purchases within established patterns can run on delegated authorization. Anything outside normal boundaries, above a risk threshold, or flagged by anomaly detection should require biometric verification.
The Verifiable Intent framework's protocol-agnostic design supports this hybrid approach. It incorporates standards from FIDO Alliance, EMVCo, Internet Engineering Task Force, and World Wide Web Consortium, making it compatible with both Google's Agent Payments Protocol and Universal Commerce Protocol. You're not locked into one authentication pattern.
The real challenge isn't choosing between continuous verification and delegated authorization. It's defining the boundaries correctly and detecting when the agent crosses them. This requires real-time visibility into agent decision-making, classification of transaction risk based on context, and the ability to interrupt autonomous workflows for step-up authentication.
Our Take
Require biometric verification for AI transactions that cross risk thresholds, but don't mandate it for every action. The Verifiable Intent framework's strength isn't in mandating continuous authentication. It's in providing a cryptographic mechanism to prove intent when needed.
Treat your AI agent like a privileged service account with elevated access. Define what it can do autonomously, monitor its actions, and require Just-in-Time Elevation when it attempts something outside normal parameters. The biometric step should be a control gate, not a speed bump on every transaction.
The tradeoff is between friction and autonomy. Too much verification, and your AI assistant can't assist. Too little, and you've created a standing privilege that exposes your payment credentials to any attacker who compromises the agent's session.
Start with tighter boundaries than you think you need. You can always relax them once you've observed the agent's behavior patterns and tuned your anomaly detection. But if you grant broad delegated authorization from day one, you won't know what normal looks like when something goes wrong.
