Your Next Customer Is an AI Agent. Your Next Fraud Case Might Be Too.

For further context, see SPF Readiness Is an Operating Model Problem and From Scam Signal to Reasonable Steps Evidence.

Click to view full size

“Find the same hotel, keep it under A$400, and book it.” It is an ordinary instruction to give an assistant. Now imagine the assistant arriving at a travel website, checking availability, signing into a loyalty account and moving towards payment. Which part should the website allow? The product team wants the booking. Security wants to know who is operating the browser. The customer expects the assistant to follow the budget. None of them has authorised a change to the account’s recovery email, a different merchant hidden behind a redirect or an extra charge invented by a page the assistant read along the way. Spotting that the visitor is automated settles very little. The difficult decisions begin after the website has recognised the machine.

That is where the familiar “human or bot?” question starts to lose its usefulness as a complete security policy. A customer can arrive through software, an attacker can use a genuine commercial AI service, and a legitimate assistant can be manipulated after it has already earned access. These are different situations with different remedies. Blocking every machine throws away legitimate activity. Trusting every recognised agent hands too much power to an identity label. A workable policy has to follow the action: what is this agent trying to do now, who authorised it, and what would happen if it succeeded? The answer can change between opening a product page and submitting an order, even when the visitor’s identity has not changed at all.

The machine at the door may be bringing a customer

HUMAN Security’s 2026 benchmark report puts numbers around this shift. Across its observed customer traffic, monthly AI-driven volumes grew 187% between January and December 2025. Traffic attributed to AI agents and agentic browsers grew 7,851% year on year, starting from a low baseline. More than 95% of observed AI-driven traffic was concentrated in retail and e-commerce, streaming and media, and travel and hospitality.^[1] This is vendor telemetry, not a census of the entire internet, and the growth figures use different comparison periods. The location of the activity is more interesting than the spectacular percentage. These are places where a browsing session can become a booking, an account change or a payment. Treating all automation as an unwanted scraper increasingly means making a commercial decision as well as a security decision.

A training crawler, a search retriever and a customer’s purchasing assistant should not inherit the same permissions simply because they all fetch pages. The crawler may be collecting content in bulk. The retriever may need a current answer for a user. The assistant may need to make a reservation under a limited mandate. Their identity signals can overlap, especially when the same infrastructure provider supports different services. Start with what the business wants each category to do, then define the permitted surfaces and actions. A public catalogue can be broadly discoverable while account recovery remains tightly controlled. A booking assistant can receive inventory information without receiving unrestricted access to loyalty points, saved payment methods or private account history.

The agent can be genuine and still do the wrong thing

The awkward case is the useful assistant that becomes a vehicle for someone else’s instructions. University of Washington researchers reported in June 2026 that four of seven agentic browsers they studied created paths around protections associated with the same-origin policy. They demonstrated a proof-of-concept attack on one browser and identified conditions for related attacks in three others. The work also examined how agents could mix information from different origins as they processed or compressed their memory.^[2] This was a study of particular implementations and tested conditions, not evidence that every current agentic browser behaves identically. Its central warning is nevertheless easy to understand: a browser can isolate websites at one layer while an assistant with access across those websites becomes a bridge between them.

For a business allowing agent traffic, that changes the meaning of “known visitor”. The agent may still belong to a recognised provider and hold the customer’s valid session. A hostile page can attempt to redirect what it does with that access. The attack does not need to steal the provider’s identity if it can persuade the authorised assistant to misuse its own capabilities. Page content should therefore remain evidence or task data, with no authority to expand the user’s mandate. A claim in a listing that the user must complete an unrelated identity check should not acquire permission merely because it appears during a legitimate booking. The relevant boundary is between reading an instruction and being authorised to execute it.

This problem is now prominent well beyond browser research. On 19 October 2026, Microsoft’s Securing the agentic insider argued for continuously assessing enterprise agents and adjusting what they can do as their risk changes, with controls spanning identity, permissions, data and runtime.^[3] ASD’s guidance on agentic AI similarly recommends minimum necessary permissions, oversight for sensitive actions and monitoring of tool use. Its discussion of models acting beyond an evaluation environment also explicitly says that normal deployment safeguards were intentionally not enabled during that test.^[4] The useful lesson is the need for enforced limits around capable systems. Turning an unusual evaluation into a claim that every consumer assistant can freely break into live systems would obscure that lesson.

A signed identity is the start of the decision

There is real progress on identifying agents without relying entirely on a user-agent string. Cloudflare’s Web Bot Auth uses cryptographic HTTP message signatures, with published keys and verification procedures, to support bot and agent authentication.^[5] Visa’s Trusted Agent Protocol goes further into commerce: its specification describes agent recognition, linked consumer recognition and signed payment containers, with controls against replay and relay.^[6] These mechanisms deserve a serious place in the architecture. They give merchants stronger material to verify than an unauthenticated claim that a request came from a particular assistant. They also make it possible to carry more context into the interaction. But the merchant still has to decide what the verified material permits on its own service.

Keep the questions separate. A valid signature supports a conclusion about the signed message and its relationship to a trusted key, under the protocol’s validation rules. A consumer recognition object can help establish which account relationship is relevant. A payment object can carry protected transaction information. None should be treated as a general exemption from business controls. The website must check that the request is current, intended for the right service and consistent with the action being attempted. It must also consider limits on amount, recipient and scope where those are part of the customer’s authorisation. A valid identity should make the next check more reliable, rather than cause the remaining checks to disappear.

The older signals still have a place, provided they are asked to do the right job. A user-agent declaration can help classification. A rate limit can protect scarce capacity. A challenge can address a particular risk. The robots exclusion standard itself says its rules are not a form of access authorisation.^[7] Likewise, successfully completing a human-oriented challenge does not establish that a purchase is honest, and a request from a known provider does not identify every person who can operate its service. Build the decision from the evidence available for this interaction. A blanket exception for a fashionable AI brand is a particularly fragile substitute for that work: it groups together the provider, the customer, the task and the current action as though they were one trustworthy thing.

Purpose is the hardest row because nobody can read an operator’s intentions from an HTTP request. The practical task is narrower: compare what was authorised with what is happening. If an assistant was allowed to compare hotel rooms, a request to change a recovery address is outside that task. If it was allowed to make one booking within a stated budget, repeatedly creating accounts or moving to a different payment recipient needs a new decision. Behaviour adds context, but thresholds need to account for ordinary automation too. A fast sequence is not automatically hostile, and a human-looking sequence is not automatically safe. The policy should be able to permit one action, slow another and refuse a third within the same session.

The checkout needs a different answer from the catalogue

Consider how this should work for the travel request at the start. Reading room information needs comparatively little authority. Signing into a loyalty account exposes private information and should use an appropriate delegated access mechanism where available. Changing account settings requires separate authority. Making the booking requires the agreed room, dates, total price and merchant to remain within the permitted scope. A redirected payment recipient is a material change, even if the page describes it as routine. An approval mechanism should show those material details through a trustworthy channel and bind the resulting authority to them. A generic “continue” button can leave a person approving a task description while the software executes a different transaction.

This does not require a person to approve every click. It requires the authority to become more specific as the consequences increase. A customer can delegate a bounded purchase in advance. The system should enforce the boundary and ask again when the action falls outside it. Controls also need to handle ordinary agent mistakes. If an assistant times out after submitting an order, its next attempt must not silently create a second booking. If it mistakes a page response for failure, it needs a way to check the actual order state. Agent access policies that discuss only malicious bots miss these mundane failure modes, even though duplicate charges and unintended changes can create the same customer-facing dispute.

There are two sides to this arrangement. A merchant controls what an incoming assistant can do on its site. The assistant’s operator controls which sites, credentials and tools the assistant may use. Neither side should assume the other has checked everything. A merchant does not necessarily see the original user instruction, and an assistant does not necessarily know whether the merchant’s latest page contains compromised content. Exchange verifiable task and transaction context where the integration supports it, and reject unsupported expansions of authority. Treat access as an ongoing set of decisions made at concrete points, with enough recorded evidence to explain what was allowed and why.

The attacker may build a second entrance outside your website

Click to view full size

A well-controlled official website is only part of the customer’s route. Someone can encounter a cloned storefront, an impersonated support profile or an advertisement that leads into a parallel buying process. An assistant doing research can encounter the same material. In August 2026, ASIC warned that investment scammers were constructing supporting footprints of fabricated news, fake reviews and AI-generated endorsements, making a quick online search unreliable as a verification method.^[8] The warning concerned investment scams, but it exposes a broader verification problem: several reassuring pages can share one deceptive origin. For an agent comparing merchants or checking a payment request, counting positive mentions is weaker than checking where the claims came from and whether the destination matches the expected business.

Imagine an assistant finding a convincing copy of the hotel’s website. The spelling is right, the photographs look familiar and the page offers the room the customer requested. A support message then directs payment elsewhere. The assistant can be genuine, the customer can approve the amount and the payment can complete through a legitimate service. The unresolved question is whether the money went to the business the customer meant to pay. This is why external impersonation evidence belongs alongside session and transaction signals. A clone finding may justify warning the customer or reviewing a destination before a loss occurs. Waiting for the event to arrive as a post-payment dispute wastes the information gathered at the beginning of the journey.

Authentication is often overstated in this discussion. A successful login tells the service that its authentication requirements were satisfied. It does not, by itself, explain who shaped the customer’s decision or establish that the recipient is legitimate. Even direct approval by a real customer can follow deception. Repeating the same authentication step may therefore leave the central fraud question unanswered. Where the evidence points to a false merchant or scam-linked beneficiary, the intervention needs to address that context. Show the verified discrepancy, use an appropriate review path and retain the evidence behind the decision. The problem is especially sharp when a legitimate agent executes a deceptive journey cleanly: the absence of account takeover does not mean the customer received what they intended to buy.

A useful trust decision needs evidence from outside the session

External intelligence should arrive in a form that the access or payment workflow can actually use. A suspicious domain needs an observation time, the relevant evidence and a clear statement of what is known. A beneficiary association needs its source and enough context to distinguish a verified connection from a tentative match. An analyst’s inference that two pages belong together should not harden into a permanent block because another system received only a risk label. Separate verified observations from hypotheses, refresh findings that can change and provide a correction route. Latency matters too. Intelligence delivered after a transaction completes may support an investigation, but it cannot influence that already completed decision.

Large language models can help turn screenshots and messages into proposed structured findings, but they should not invent the missing link. A model that reads a digit incorrectly can associate the wrong account with a scam. A plausible explanation can conceal that the source never mentioned the beneficiary at all. Preserve the original artefact, validate the fields that drive decisions and keep untrusted page content from issuing instructions to the analysis workflow. Where an agent can trigger an external action, the permission boundary needs to sit outside its prose. The ability to explain a finding in fluent language is useful for review; it does not establish that the finding is correct or authorise a block.

This is where Cyberoo’s service areas connect to the problem. NothingPhishy focuses on external digital risk and infrastructure disruption. Scams.Report supports explainable verification of suspicious material and reporting. MuleHunt focuses on evidence-supported intelligence about scam-linked payment destinations before a transfer.^[9] These are sources of context for decisions made by the organisations controlling websites and payments. They do not replace agent identity protocols, account authentication or the customer’s mandate. Their value is in making a deceptive external journey visible before an apparently normal interaction ends in a loss.

A sensible first exercise is to choose one customer journey that agents are likely to use, such as a reservation or account purchase, and test it end to end. Give an assistant a clear task and record where the site permits access, requests authority and verifies the final transaction. Then introduce an unrelated account change, a different destination and an ambiguous retry. Include a cloned entrance in a controlled test so that the official site’s protections are not the only thing being assessed. Check whether the teams responsible for web access, customer accounts and fraud can explain the combined result. The work is specific enough to start now, and the failures are easier to fix than a vague promise to make the whole website “AI-ready”.

The awkward question for the next review is whether a recognised assistant can do something the customer never meant to permit. Look at the signed identity, the scope of the authority and the actual outcome separately. Ask where a page could have introduced a new instruction, where a merchant or beneficiary changed and which control had enough context to notice. A system that recognises the visitor but never revisits its permissions has only solved the first part of the problem. When the machine reaches the payment button, can you show that this is still the action its customer authorised, going to the destination that customer intended?

FAQ