A browser used to have a simple job: show a page and wait for a person to decide what to click. An AI browser agent changes that relationship. Give it an objective — find a refundable hotel near Berlin Hauptbahnhof for under €180, compare three electricity tariffs, reorder a specific coffee filter or book a train after 17:00 — and the software can work through the website instead of merely describing what the user should do next.
That distinction matters. A chatbot may tell you where to find a product. A search engine may send you to the shop. A browser agent can potentially open the shop, check stock, select a variant, fill in delivery details and move the transaction to the point of confirmation. Some systems can go further when the user has granted the necessary permissions.
This is no longer just a laboratory demonstration. Browser-based agents can already read pages, navigate between tabs, click controls, type into forms and operate inside authenticated sessions. Commerce platforms, payment networks and infrastructure providers are simultaneously working on machine-readable product feeds, delegated payment credentials and cryptographic methods for distinguishing an authorised shopping agent from an ordinary scraper or malicious bot.
The interesting change is therefore happening on both sides of the browser. AI is getting better at operating websites, but websites are also beginning to expose information and actions in forms that software can understand without guessing what a human-looking interface means.
An AI browser agent is more than a chatbot that can click
The easiest way to understand a browser agent is to separate five jobs that conventional software usually handles independently.
First, the agent observes the page. Depending on the system, it may use screenshots, the browser’s DOM, an accessibility representation of the page or specialised browser tools that expose buttons, fields and page text directly.
Second, it interprets the user’s objective. “Find me a hotel” is not an executable instruction by itself. The agent has to turn it into decisions about destination, dates, occupancy, budget, cancellation conditions, location and potentially dozens of secondary constraints.
Third, it performs actions: opening pages, changing filters, selecting products, entering data and moving between steps.
Fourth, it checks whether each action actually worked. This is an underrated part of browser automation. Clicking “Continue” means nothing if the page returned an error, changed the price, silently removed a discount or opened a modal asking for another decision.
Finally, a useful agent needs a permission model. It must know which actions it may take automatically and which ones require the person to return and approve them.
A typical purchase therefore looks less like one long automated click sequence and more like this:
-
search and comparison can run automatically;
-
a product may be added to the basket automatically;
-
personal or delivery details may be entered from previously authorised data;
-
a material change in price, delivery date or cancellation conditions should stop the process;
-
final payment may require separate approval or authentication.
This is also why an AI browser agent should not be confused with a crawler. A crawler primarily retrieves pages for indexing, analysis or training. A browser agent is acting on behalf of a particular user and toward a particular outcome. It may have a session, permissions, preferences, a basket and authority to make changes.
There are currently three main technical ways to give an agent that ability.
The first is visual computer use. The AI receives an image of the page and controls a virtual mouse and keyboard. This works almost anywhere, including old systems that expose no useful API. It is also the most fragile approach. Move a button, show a cookie banner or change the screen resolution and the agent may need to reinterpret the entire page.
The second is page-aware browser control. Instead of guessing coordinates, the agent can work with identifiable page elements, text fields, links and browser state. This is faster and generally more reliable.
The third is the direction that matters most for commercial websites: the agent stops pretending to be a human whenever a machine interface is available. It calls an API, uses a connector or communicates through an agent-oriented protocol. An inventory query that takes ten visual actions through a website may become one structured request returning product ID, price, stock status and delivery information.
That is the practical hierarchy. Use an API or dedicated tool when one exists. Use browser-native structured controls when it does not. Fall back to pixels and mouse clicks when there is no better route.
The last method looks spectacular in a demo but is often the least attractive one in production.
Websites are acquiring a second interface: one intended for machines
The traditional web page mixes information, presentation and interaction. A person can usually work out that “Only two left”, “€129.90” and a green button belong to the same product even if the underlying HTML is messy. Software has a harder job.
Agent-ready websites increasingly separate the meaning of a transaction from the way it is visually displayed.
For an online shop, the minimum useful machine-readable record is not simply a product name. It includes details such as:
-
unique product and variant identifiers;
-
current gross price and currency;
-
inventory or availability status;
-
size, colour or configuration;
-
delivery methods and expected dates;
-
shipping cost;
-
geographical restrictions;
-
return conditions;
-
seller identity;
-
whether the displayed offer is actually purchasable.
Google’s existing Product structured-data ecosystem already encourages merchants to expose price, availability, shipping and return information in structured form. Agentic commerce takes the same principle further: software needs not only to understand what exists, but also what it is allowed to do with it.
OpenAI’s current Agentic Commerce Protocol, for example, uses structured merchant catalogues and checkout interfaces rather than forcing an AI to visually scrape every product page. Its merchant documentation supports product feeds delivered through files or APIs, with structured identifiers, descriptions, prices, inventory, media and fulfilment information. Full catalogue snapshots are recommended at least daily, while API-based updates can be used to keep individual products and promotions current.
The checkout side is even more important. A serious machine-facing transaction interface needs explicit states such as:
created → awaiting information → ready for confirmation → payment required → confirmed → failed
An agent should never have to infer from a spinning icon whether €750 has already been charged.
APIs handling purchases also need idempotency. If a network request times out after the order was submitted, repeating the request must not accidentally create and charge a second order. This is mundane engineering, but it is far more important than giving an AI prettier buttons to click.
Bookings add another layer. A hotel or travel system needs to expose not just “available” but the exact conditions attached to that availability: check-in and check-out dates, number of guests, room type, taxes, breakfast, cancellation deadline, prepayment rules and the currency in which the final amount will be charged. Flight and rail offers add fare class, baggage rules, connection times and passenger data.
An ambiguity that is merely irritating to a human can become a transaction error for an agent.
Semantic HTML therefore matters more than it used to. A real button should behave like a button. A field should have a meaningful label. Errors should be associated with the field that caused them. Important state changes should be available in text rather than communicated exclusively by colour or animation.
This overlaps with accessibility work. The European Accessibility Act has applied to covered services since June 2025 and includes e-commerce, banking and payment services among its scope. Its purpose is accessibility for people with disabilities, not optimisation for AI, but the engineering disciplines frequently reinforce each other. Proper labels, keyboard-operable controls, clear states and understandable forms are also easier for software to operate than a page built from anonymous clickable containers.
For businesses, however, opening a site to machines creates the opposite problem as well: how do you know which machine is visiting?
Blocking every automated client is becoming commercially awkward. Allowing every automated client is a security problem.
This is driving work on authenticated agent traffic. Cloudflare’s Web Bot Auth, for example, can use cryptographic HTTP message signatures to verify automated requests. Its current implementation supports Ed25519 signing keys and a public key directory hosted under a /.well-known/ path. Payment networks are pursuing similar ideas at the transaction level. Visa’s Trusted Agent Protocol is designed to let merchants recognise a verified commerce agent and receive signed indications of its intent instead of treating it like an anonymous bot.
These systems are still evolving. There is no single universal protocol that every shop, browser agent and payment provider has agreed to use.
That distinction is important because several protocols are often mixed together in discussions about the “agentic web”:
-
MCP primarily connects an AI application to tools and data;
-
A2A addresses communication between agents;
-
ACP is focused on merchant catalogue and commerce workflows;
-
cryptographic bot and agent authentication addresses the separate question of who is making the request.
Installing one does not magically make a website “AI-ready”.
There are even early experiments with machine-native economics around ordinary HTTP access. Cloudflare’s Pay Per Crawl remains a beta product, but it demonstrates the direction clearly: an automated request can receive an HTTP 402 Payment Required response together with a machine-readable crawl price. The currently documented minimum is $0.001 per successful crawl. This is aimed at AI crawlers rather than consumer checkout, but the principle is significant. Machines are beginning to encounter not merely web pages, but prices, identities, permissions and payment conditions expressed directly at protocol level.
Buying and booking expose the limits of autonomous browsing
Research is easy to delegate. Spending money is different.
A shopping agent can compare fifteen laptops with relatively little risk. Allowing it to choose one, accept a three-year subscription, use a stored payment credential and agree to a non-refundable delivery option creates several distinct liabilities.
This is particularly visible in Europe.
Under PSD2 strong customer authentication rules, payment service providers must apply SCA in defined situations including access to payment accounts, initiation of electronic payments and certain remote actions presenting a fraud risk, unless an applicable exemption is available. In practice, this means a browser agent can often prepare a purchase but still encounter a boundary where the user has to confirm the transaction through a bank, payment application or other authentication mechanism.
That interruption is not a design failure. For consequential actions it is often exactly where the boundary should be.
The same principle applies before an agent books travel. Price is only one variable. The agent needs to understand the legal and commercial consequences of pressing “Confirm”.
An ordinary online purchase by an EU consumer will often carry a 14-day right of withdrawal, but important exceptions apply. Plane and train tickets, hotel bookings, car rentals, concert tickets and catering services tied to specific dates are among transactions for which the normal 14-day cooling-off period does not apply.
An agent that treats “book now and cancel later” as a universal European rule will eventually make an expensive mistake.
For booking workflows, I would therefore treat the following as mandatory confirmation data before an irreversible action:
-
final amount, including mandatory fees and taxes;
-
exact dates and times, including the relevant time zone;
-
cancellation deadline and penalty;
-
whether the reservation is refundable;
-
payment timing — now, later or at the property;
-
renewal or subscription conditions;
-
identity of the actual seller or service provider;
-
any material change compared with the instruction originally given by the user.
This is also where agentic interfaces need transaction limits rather than a binary “allowed/not allowed” permission.
“Buy things for me” is a bad permission.
“Buy replacement printer toner from these three merchants, up to €60 per order, maximum twice per month, and ask before purchasing if delivery takes longer than three working days” is a useful delegated authority.
Payment companies are already building around that idea. Agent-specific credentials and tokens can be tied to an agent, merchant, amount or instruction instead of handing software an unrestricted card number. The long-term model is likely to look more like controlled delegation than giving an AI access to a conventional wallet and hoping it behaves correctly.
There is clear market pressure to solve this. A Mastercard report published in September 2026 combined consumer research with futurist analysis and projected that more than one in ten online shoppers could routinely use AI agents to shop and pay by 2030. Its underlying consumer study covered 13,000 parent-and-teen pairs — 26,000 respondents — across 13 markets including Poland.
That is a forecast, not evidence that one in ten Polish consumers are already buying autonomously through agents. Present-day deployment remains much less uniform. Product discovery and comparison are considerably easier than reliable end-to-end purchasing across arbitrary websites.
The obstacles are practical.
CAPTCHAs and bot protection can block an otherwise legitimate agent. A merchant may see a helpful shopping assistant and a credential-stuffing script as essentially identical automated traffic unless the agent can prove its identity.
Session expiry is another irritating failure mode. An agent can spend several minutes configuring a booking only to find that the price hold has expired before payment.
Then there is prompt injection. A browser agent has to read untrusted websites in order to do its job. A page can contain text or other content crafted to influence the AI rather than the human shopper. The agent therefore has to distinguish between information it is supposed to analyse and instructions it is authorised to follow. Current browser-agent systems use various safety checks and classifiers, but this attack surface has not disappeared.
The correct security assumption is that anything an agent reads on the open web is untrusted input.
For users, that means financial and account permissions should be narrow. Do not give a general-purpose browser agent unrestricted access to banking, email and payment accounts merely to save a few clicks during shopping.
For merchants, it means the system should verify the transaction independently of the language model. A checkout backend must still validate the price, inventory, shipping method, payment authority and order state. The AI’s statement that everything is correct is not a security control.
There is another consequence that retailers sometimes overlook. When an AI agent becomes the interface, a large part of conventional website persuasion loses value.
The agent does not care that the “Premium” package has a gold border. It may care that it costs €19 more, renews automatically after 30 days and adds only two features relevant to the user’s instruction.
That pushes competition toward clean product data, transparent terms, availability, fulfilment quality and total price. Dark patterns designed to steer a distracted human become less effective when an agent can compare the underlying conditions directly. Conversely, inconsistent or incomplete data can make a perfectly good offer effectively invisible to software.
The web is not about to lose its human interface. People will still want photographs, reviews, maps, editorial explanations and the ability to browse without knowing exactly what they want. But commercial websites are acquiring a second customer at the same time: software representing the customer.
Serving that software reliably requires a different discipline.
FAQ
Is an AI browser agent the same thing as ordinary browser automation?
No. Conventional automation normally follows a predefined script: open page A, click element B, enter value C. An AI browser agent can interpret a higher-level objective, adapt its plan when the page changes and decide which actions are necessary. The trade-off is lower predictability, which is why consequential steps still need strict controls.
Can a browser agent make a purchase completely without human approval?
Technically, yes, if the system has sufficient permissions and an appropriate payment mechanism. That does not mean unrestricted autonomous purchasing is a sensible default. European authentication requirements, merchant risk controls and user-defined approval rules can all require human involvement before payment. Low-value recurring purchases are much easier to delegate safely than an expensive, non-refundable booking.
Does a website need a separate version built specifically for AI agents?
Usually not. Start with clean semantic HTML, structured product or service data, explicit prices and availability, understandable forms and reliable APIs. A dedicated agent interface becomes useful when transaction volume justifies exposing structured actions directly rather than forcing software through the visual website.
Should an online shop implement MCP, A2A or ACP first?
Not until its underlying data is reliable. MCP is useful when exposing tools or data to AI applications. A2A addresses agent-to-agent communication. ACP is designed around commerce integration. None will repair a catalogue in which the product feed says “in stock”, the product page says “delivery in 24 hours” and checkout says “unavailable”. Fix the source of truth first, then choose the protocol that matches the distribution channel.
Is robots.txt enough to control AI agents?
No. robots.txt remains useful for declaring crawler preferences, but transactional agents introduce identity, authentication, permission and payment questions that crawl directives do not solve. A merchant needs to distinguish an authorised user-driven agent from scraping, abuse and malicious automation.
What is the biggest security problem with browser agents?
Over-broad authority is the first problem to remove. Prompt injection and malicious web content become much more dangerous when the agent can also read private data, modify accounts or spend money. Use least-privilege permissions, spending limits, domain restrictions, explicit approval for irreversible actions and an audit trail showing what the agent actually did.
For a Polish retailer, booking platform or service company, the first move should not be to launch an AI chatbot or add an agent protocol because competitors are doing it. Audit the highest-value transaction path first: product or offer page → availability → basket or reservation → payment → confirmation → cancellation or return. Check whether a machine can obtain one unambiguous answer for price, currency, stock, mandatory fees, delivery or booking conditions and cancellation rules at every stage.
If those values disagree between the visible page, structured data, product feed and checkout backend, fix that inconsistency before doing anything else. An AI agent can survive an unattractive website. It cannot reliably transact when the same purchase has four different versions of the truth.
