Safeguarding agentic commerce – fraud strategy advice by Ravelin's CPO

In the next five years, agentic commerce is going to become a $3–5 trillion market, according to McKinsey. And Boston Consulting Group says that more than half of ecommerce will be AI-assisted in wave 1, and 18% autonomous by wave 3 of agentic – but did not clarify when they expect each wave.

Respondents to Ravelin's Agentic Commerce & Fraud survey were a little more modest, with the majority predicting that agentic commerce will represent up to 15% of their transactions by 2029.

Is this the real story? It’s part of it. What matters more, perhaps, is that everyone would agree that agentic commerce is a new thing. And if there’s anything fraudsters like, it’s a new thing.

Regardless of consumer adoption specifics, at Ravelin we confidently believe that fraudsters will adopt and adapt, and so must we as online merchants and the fraud prevention community. And yes, there’s a clear danger many companies have identified. The danger of being left behind. Of being stuck in a world that no longer exists – being complacent and not adapting.

Merchants want to know how to benefit from the shift to agentic in a sustainable, scalable and secure way. That’s what we’re setting out to do in this analysis. We'll also explore the specifics of fraud detection for agentic commerce: what data is available, how to leverage it, and how to adapt your fraud strategy.

Fragmentation and opportunities

The industry response to agentic commerce has been fragmented, and it’s fair to say it will remain so for some time. For all the hype, promise and investment, agentic commerce is still in its infancy in 2026.

But the distribution opportunity is crystal clear: ChatGPT has 800 million active users and Gemini has 450 million active users, not counting the other LLMs out there. This is likely to be an important channel to anyone who can take advantage of it.

There are so many protocols, many of which we saw mentioned by our survey participants. And new protocols emerge almost every week. Merchants are expected to adapt and reshape their front and back ends, but often do not know where to start.

Why care about agentic protocols?

There are a lot of protocols out there in 2026, with each intending to solve problems that include accountability for mistakes, financial liability for disputes, correctly interpreting and surfacing product information, capturing customer information, and much more.

What we’ve increasingly seen from findings such as those published in the Agentic Commerce & Fraud Report seems to have some common patterns. To embrace this new era,

• Consumers are looking for reassurance, control and the ability to intervene in their agentic shopping.
• Merchants, on the other hand, are also looking for reassurance, control and the ability to influence agentic shopping.

The gating factor in agentic commerce is trust – in the same way that trust was the main obstacle to overcome to encourage consumers to start paying by card online.

Even before the agentic era, merchants at the forefront of creating trust with their customers always had a competitive advantage.

Our goal at Ravelin is to help you seize the opportunities of agentic by inspiring trust through this agentic AI era. And one aspect of inspiring this elusive trust is thinking about fraud and how to prevent it. After all, it’s one of consumers’ main blockers in using agentic – and if you invest in such a project, you’ll want them to use it.

There are several ways in which agentic and AI shopping in general could go wrong, including:

• hallucinations
• plausible deniability
• prompts weaponized for first-party fraud
• scripted probing to test fraud rules and thresholds
• synthetic ID generation at scale
• AI-generated fake stores and
• takeover of AI platform accounts…

So, where do we go from here?

New fraud dimensions

Let’s start by considering the new dimensions that shopping agents bring to fraud.

Asking the right questions is the critical part of understanding something. So we are going to focus on key questions, to ask…

How can we classify agentic commerce fraud cases?

How can we classify fraud cases related to agentic use or agentic enablement?

It's important to consider whether criminals are using AI to more effectively target existing vectors, or whether this is a brand new type of fraud.

When you look closely, a lot of agentic commerce fraud falls into the category of existing use cases. These are all familiar attack vectors:

• account takeover attacks (ATO)
• card testing
• fake accounts
• phishing
• returns and refund abuse

But – critically – with agentic commerce, this is done on a different scale or at a different speed, or at a greater level of sophistication.

But there are also entirely new use cases such as:

• agent hallucinations
• a good user unwittingly using a bad agent
• prompt injections to fool agents

and so on. And, in fact, some cases may fall somewhere in-between the two.

A second question is...

How autonomous is the agent?

When is a human involved in AI shopping, if at all? It’s important to recognize that much of the discussion around agentic commerce focuses on a future flow where agents are fully autonomous and humans are not present. However, this is not in use today.

Most agentic AI activity at present is human-present and agent-mediated. A human will click to confirm an instant checkout or may even be expected to click and take control of an agent browser in order to pay, including authenticating their identity.

That moves us on to considering the different parties: the agent(s) and the user(s) behind the agent(s). To stop fraud, we need to consider both of these dimensions.

So, what agentic commerce brings to fraud detection is a different matrix of combinations: Is it a good or bad agent? And is it a good or bad user?

Variability by interaction and by payment method

At Ravelin, information is the weapon we use against attackers. The important question to ask is: Which data is available in each agentic commerce transaction?

Firstly, any appraisal of the situation has to consider the interaction mode: On ChatGPT alone, an agentic commerce transaction might come through an agent-driven browser, or through Instant Checkout (now discontinued yet a similar flow may arise in the future), or through an embedded merchant app.

Each of these three flows has different data implications. And this is just one AI platform, and still there are dozens out there.

Different payment methods also entail different data to be captured: To create a delegate token, the agent platform sends the payment method details and spending allowance to the PSP, so there’s data available there. And for an agentic token such as Visa’s, the end user device data is collected when creating a payment passkey.

Agentic commerce fraud detection has to be scalable but encompassing as many use cases as possible. Let’s keep in mind this variability of both interaction mode and payment method as we look at the impact on signals useful for fraud prevention.

The dependable six signals

We have half a dozen dependable data points that are guaranteed to be present, regardless of the variability of agent and payment method or protocol:

• order items
• order value
• order contact
• payment method
• billing address
• shipping address

These might come through API calls rather than an ecommerce website. You may not know if the contact details are verified, but even if you don’t know who is buying, you will know what they are buying, how it is being bought and where it is being sent.

That is a decent foundation for fraud detection. In fact, Ravelin’s payment fraud PSP solution is very much centered on these transactional data points, without necessarily having reliable customer IDs.

Customer account IDs are one of the first gaps in our data with agentic versus traditional shopping. At the moment, the easiest path to agentic favors guest checkout, so we’re likely to see an uptick in that, at least in the short to medium term.

As a result, it is more challenging to look at a broader picture of a customer. However, some protocols offer a peek into what the future might hold for data availability.

Google’s UCP, for example, includes data points that Google will share with a merchant at checkout, so they can be used to stop fraud. They include:

• session data
• device data
• browser data
• order data
• shipping & billing data
• payment verification data

On the other hand, OpenAI’s ACP only includes a container for the output of risk models. The merchant is not involved in risk decisioning. ACP expects merchants’ own risk checks to happen before this point in the flow, but they do not provide any additional data to help with that, at the moment.

Even with UCP, there are differences between Google’s UCP and the open protocol UCP, which is much more open ended, stating that it may include risk signals, without making any commitment.

A similar approach is taken in the Google-penned open standard AP2, which is not expected to replace UCP but to be used in combination with it to provide both fraud signals and consent signatures. Obviously, it’s a bigger engineering lift and adoption is unknown.

Overall, fraud signal availability is a mixed bag with the leading protocols so far and, Google aside, we can expect to see a loss in user session data.

Agent-driven browsers vs bots

The above are all "headless commerce" cases that go directly to the APIs, bypassing the merchant interface entirely. The user will stay on the AI platform, so if the platform is not sharing user data with the merchant, the merchant loses sight of it.

In other cases, there will be a browser, but it will be driven by an agent rather than a human. This has its own implications.

The first thing to recognize is that bots have been around for a long time. They aren’t new. And we already have tools to detect them. There are easy to capture, well-known differences between human sessions and bot sessions.

A typical human session will have pauses and variable time between events, for instance, whereas bot sessions typically involve precise, rigid interactions, short sessions, rapid events – the programmatic behavior of credential stuffing, card testing and ticket scalping.

This behavior will still be true for some bots, but it is not the case for agent-driven browsers. These are LLM browsers run on the hosted provider, controlled by the AI platform while the user stays in the LLM’s chat interface. These can simulate human behavior in order to buy from a merchant who has not integrated any protocols.

Therefore, agent-driven browsers differ from bots in their behavior. Consider Perplexity’s Comet browser when self-driving. Interactions with the online shop are not speedy, like with traditional bots. There are big pauses between actions. Sometimes, it clicks the wrong thing – it’s a bit like a human, yet in other ways it is still jerky and robotic with scrolling, clicking and cursor movements.

This behavior lands agent-driven browsers somewhere between a human and a bot. In time, this may evolve. So, we can add session data to our list of changes.

Agent-driven browser sessions initiated in an AI chat are not on the end user’s browser but run on the hosted provider. This means that we lose sight of the actual user’s device data and IP address in this case as well.

A more obfuscated guest checkout

Altogether, at the worst end of the scale of available fraud data, agentic commerce can have guest checkout, combined with missing session data, missing device data, and missing IP information.

It’s a more obfuscated form of guest checkout, missing data such as:

• account ID
• session data
• device data
• IP address

Recommendations: Adjusting your fraud strategy for agentic commerce

It’s fair to say agentic commerce presents a complicated, sometimes overwhelming picture. There’s a lot of “it depends”, so let’s shift to action: adjusting your fraud strategy.

This is how we approach the problem at Ravelin.

First, we evaluate the agent. As part of this, we need to identify the agent, verify the agent, and factor in the agent.

1. Identifying AI agents

Ways to identify agents already exist, albeit with varying degrees of precision.

They involve the Web Bot Auth standard, IP ranges used by AI platforms, KYA registrations with card schemes, and so on.

And when all else fails, behavioral signals can indicate if it’s an agent or human visiting your site. You may not know which agent it is, but you can judge if it looks like an agent.

From there, you need to make sure you share everything you can with your fraud provider.

From a Ravelin perspective, we’re interested in any and all of these signals and have updated our API to gather some of this new data. We now also highlight agentic orders in our dashboard and reporting – including agent verification information, and refunds or disputes linked to agentic orders.

So we can identify agents.

2. Verifying AI agents

There is also an obvious need to verify agents: Fraudsters will want to impersonate good agents. Reliable verification (sometimes called KYA – Know Your Agent) can give confidence to merchants, allowing them to accept more agentic orders. It allows us to have trust that the agent is who we think it is.

One of the positives in the industry development, Web Bot Auth has emerged as a standard here for browser-based flows. Pioneered by Cloudflare, it’s used by ChatGPT, Manus, Visa, Mastercard and others.

Web Bot Auth allows us to cryptographically verify that the agent is who they claim to be. We can know, with confidence, that this is indeed an order from ChatGPT, for example, and not someone nefarious trying to impersonate ChatGPT.

At Ravelin, we are collecting these signatures through our SDK and performing these verification checks. If an agent fails verification, this is a big red flag.

The interests of the AI platform and the merchant are aligned in this case: Reputable AI vendors don’t want to be impersonated, so the incentive is there to participate – and this is much better than relying on brittle lists of IP addresses assigned to AI agents.

3. Factoring in AI agents and building a picture

Lastly, we want to factor in the agent. It’s a familiar last step: Using the data points we have collected about the agent to make a fraud recommendation – in the same way we do with any transaction.

To do this, we can add agent-based features into machine learning fraud models. For example, merchant-level and consortium-level agent fraud rates.

At Ravelin, we are also building up agent risk profiles following similar principles to what we do for BINs, domains, and locations.

Agent-focused conditions can also be factored into rules. And of course, there’s a need for building out reports, tracking the volume and value of agentic orders, their fraud and refund rates, their promo usage rate.

As ever, this is about both safeguarding and enabling: both blocking bad agentic orders and allowing good agentic orders.

4. Assessing the human behind the agent

We’ve already covered that the end user data may be missing, and consumer intent is a thorny topic. So let’s look at what we can do now, how a merchant can respond.

If a shopper logs in and then hands control to an agent, this is a form of permissioned account takeover (ATO) – letting a known AI into your account to shop for you. This agent might run on a remote server with a different location to the shopper. And to an unprepared fraud solution, this can look a lot like malicious ATO.

Indeed, in the past, there was little reason to allow bots on merchant platforms. You’ll likely have defenses against it already in place. But these defenses can trip up legitimate, verified agents.

So beware of bot false positives: Check your device and location anomaly strategies. Avoid blocking orders from legitimate, verified agents.

• Customer ID: Sometimes, a customerID is available – for example with UCP. You as a merchant can support this. The card schemes’ consumer identity features are also interoperable with existing identity systems. And where we can’t get a customerID? Then we need to boost identity proxies.
• Customer addresses: We were always going to know where the order is going to be dispatched to. Fulfillment addresses and billing addresses aren’t going away – so look at how you are using them today.
• Instrument ID: Another proxy is the instrumentID. Revisit your instrument ID integrations. Are you using the latest payment APIs? What about agentic commerce updates? Are there any data points available that you don’t collect or use and could you start doing so? Getting persistent, stable IDs for payment instruments from your PSP is crucial. Make sure you are on the latest version of your PSP’s tooling.
• Consortium data: Further boosting this is consortium data. Ravelin is adding more data points to our consortium from Worldpay and Global Payments transactions, collecting networked insights on payment methods, locations and email domains. And that global footprint is also helping us collect more data more quickly on agentic orders, where we are building up global consortium views of agents and their risk profiles.

The last action step here we recommend is about consumer disputes. While we await further news on rule changes around liability, there are some sensible steps to take: Ensure that any evidence is being saved – be that from protocols like AP2 or the card schemes, and that fraud teams have visibility and access to it.

Also make sure you pay attention to your product descriptions. Similarly to traditional shopping, if your product feed has led an agent astray with unclear language or false promises, then the liability falls on you as the merchant, not on the agent.

Parting thoughts

Remember that there isn’t a single type of “agentic commerce”, at least at present. There are many competing experiences, and there are likely to be some dead ends. The questions we’ve asked can help make sense of it and move forward with confidence.

By considering some key differences, you can categorize and start making an action plan: Existing vs new use cases. API protocols vs agent-driven browsers. Human-present vs human-not-present agentic. The agent vs the user behind the agent.

Your action plan as a payments or fraud team ought to align with the overarching question of your company’s agentic strategy, but you bring in the function expertise:

• Catalog the modes you support and their particular characteristics
• Review the impact, potential false negatives and false positives
• Identify and verify agents, and adjust fraud strategies to account for them
• Mitigate the loss of user data points by boosting proxy data points and substituting model features and rule conditions

In the end, it’s still all about data. Logging data, auditing data, refreshing integrations to get better data, expanding your data sources, and verifying data, including the data you provide to AIs as a merchant.

Agentic AI may be a new world, but it touches on a lot of the old world. There are still a lot of unknowns, but agentic-enabled fraud is almost certain. So be prepared for it.

References

• Agentic Commerce and Fraud Report
• McKinsey Report
• Boston Consulting Group
• Risk signals in UCP – Google
• Cloudflare Web Both Auth