An AI shopping assistant finds the right product, compares prices and reaches checkout. Then the retailer needing to ensure KYC (Know Your Cutomer) sends a one-time passcode to verify the identity of the purchaser.
What followss next could determine whether agentic commerce strengthens payment security or creates a new opening for fraud.
The scenario is no longer theoretical. Visa, Mastercard, Google, OpenAI and Stripe have all introduced frameworks that let AI agents initiate payments on a customer’s behalf. How those agents handle step-up authentication is being formulated now on a global stage.The convenient answer is to ask the customer to share the code with their AI agent. But that turns a security boundary into just another checkout step. It teaches consumers that handing an authentication secret to an intermediary is acceptable if that intermediary appears helpful.
The more secureapproach is to keep the code out of the agent’s hands altogether. Agents should coordinate purchases. Customers should authorize them through a separate, trusted channel.
The danger is not just a stolen code
One-time passcodes have a limitation that matters here: being valid for only one use does not make them phishing-resistant. NIST’s digital identity guidelines explicitly distinguish OTP authentication from phishing-resistant authentication because a malevolent impostor impersonating the buyer can also input the y sent code.That is not an argument against OTPs. They remain the most widely used verification layer in digital commerce, and they work well when the code travels directly to the person it is intended for. The problem begins when another entity sits between the customer and the code.
Introducing an AI agent does not remove that weakness. It adds another participant to the authentication process – and potentially another place where a secret could be exposed through conversation history, connected tools or compromised workflows.
There is also a behavioral risk. If legitimate assistants routinely request security codes, criminals gain a more persuasive pretext to try to gain access to the code: “Your shopping assistant needs this code to complete your order.”
That is a foreseeable risk, not evidence that an AI-driven OTP fraud crisis has already arrived. There is still time to address it before code-sharing becomes an expected feature. Bank of America’s Building Trust in Agentic Commerce outlines five principles covering transparency, safety, privacy and data, choice, and interoperability. They are a useful foundation, but at checkout the industry needs to translate those principles into an explicit boundary between what an agent may initiate and what a customer has authorized.
Five design choices can establish that boundary.
1. Keep authentication outside the agent
When a purchase needs extra verification, the approval request should go straight to your customer and never pass through the agent. An SMS sent directly to your customer’s phone can handle this.
The SMS should show exactly what your customer is approving, including the items or services, the total price, the merchant, and the payment method. A generic “Approve?” message is not enough. When the full details are in front of them, your customers can confirm or reject the purchase based on the facts, rather than relying on their ability to spot a suspicious request.
Your customer can approve with a simple reply or a secure link, and the agent receives only the approval result for that specific transaction. The agent never sees the message, a code, or any other authentication secret. If your checkout still relies on manual OTP entry, your customer should enter the code themselves in a step the agent cannot observe or record. Supporting older checkout flows should never become a reason to pass secrets through an agent.
2. Bind approval to the purchase
Authenticating a customer and authorizing a transaction are different tasks.
A customer approving a $75 purchase from one merchant has not approved a $750 payment to another. The approval mechanism should cryptographically bind the customer’s decision to the merchant, amount, currency and a unique transaction reference. Any change to those details should require fresh approval.
There is already a regulatory precedent. The EU’s strong customer authentication rules under PSD2 require dynamic linking for in-scope remote electronic payments: the authentication code must be specific to the agreed amount and payee, and changing either must invalidate it.
Agentic checkout should preserve that relationship. A generic “customer verified” response is no substitute for transaction-specific authorization.
3. Give agents bounded authority
Delegation should not mean unrestricted access. Guardrails must be inplace.
An agent’s permissions should be short-lived, revocable and limited to a defined purpose. Controls should specify spending limits, eligible merchants, permitted transaction types and the point at which a human must approve.
Permission to reorder household supplies should not extend to gift-card purchases, account changes or recurring subscriptions.
These limits should be enforced by the payment or authorization infrastructure, not just written into the agent’s instructions. Instructions guide behavior; an independently enforced boundary limits what can happen when that guidance fails.
Customers also need a simple way to see and revoke delegated permissions without relying on the agent’s cooperation.
4. Preserve evidence of intent
When a customer disputes a payment, “the OTP was correct” says little about what the customer intended to approve. The chain of approval must be documented.
A defensible workflow should preserve the agent’s authenticated identity, the scope of its delegated authority, the transaction details shown to the customer and verifiable evidence of the resulting approval. Those records should be tamper-evident and linked to the completed payment.
That does not mean keeping every conversation forever. Evidence should be limited to what is necessary, properly secured and subject to clear retention rules.
The goal is to distinguish among an agent exceeding its mandate, an attacker altering a transaction and a customer approving the purchase as presented.
5. Make the safe path the default
Interfaces should warn users against sharing OTPs in agent conversations, or block it outright. Sensitive authentication screens and messages should be kept out of the agent’s view wherever possible.
Security testing should include attempts to manipulate the agent through malicious checkout content (prompt injection), impersonated support messages and instructions to pull codes from connected email or SMS accounts.
When verification cannot be completed safely, the agent should pause and return control to the customer, not improvise a workaround.
Agentic commerce should reduce the work involved in buying something, while not weakening the importance of the approval process. The design rule is simple: let the agent prepare the purchase, but have the bank, payment provider, or retailer confirm that the customer approved it. Customers should never have to share a one-time password with an agent just to enjoy faster checkout.
________
About Ira Cohen
Ira Cohen is Chief Strategy Officer at MMDSmart, leading strategic development and innovation, including key CPaaS solutions like MessageWhiz and Call Center Connect. With extensive executive leadership experience across consumer electronics, telecom, and tech startups, he has helped shape key industry standards for SIM cards and Bluetooth. He is an active contributor to the Mobile Ecosystem Forum and a frequent global speaker on business messaging and telecommunications.
Join our LinkedIn group Information Security Community!
——————————————————-
Click Here For The Original Source.
