The interesting question is no longer whether an AI agent can read your website. It has been able to do that for a while. The question is what happens when it can act on it - book an appointment, submit a form, place an order. That is exactly the step WebMCP is now normalising. And that is exactly where the marketing part ends and the security part begins.
Plenty has been written lately about “how do I make my site agent-ready”. About what comes after - what I as the operator have to secure before I really let an agent act - almost nothing. I am filling that gap here, from the perspective of someone who builds booking and checkout flows.
What WebMCP actually changes
WebMCP (Web Model Context Protocol) is an approach from the Chrome and Microsoft camp. A page registers “tools” via JavaScript: clearly named functions an agent can call, plus annotated form elements so it knows how to operate them. A page you look at becomes a page you drive.
This is still early: in Chrome it runs behind an origin trial, Lighthouse checks “agentic browsing” readiness only experimentally so far, and Apple has just followed with a Safari MCP server. Nobody has to build anything in a panic today. But the direction is set, and the security questions do not appear once WebMCP is stable. They appear the second the first agent is allowed to trigger an action on your site.
The mistake: agent-ready is a security topic
The reflex in many guides is: make the actions nicely visible and describable for agents, then it works. True - for the demo. The problem is that an action an agent can reliably trigger is also an action that can be triggered automatically, repeatedly and manipulated.
A human filling out a form is slow, visible and singular. An agent is fast, invisible and scalable. Same function, two completely different threat models. Treating “agent-ready” as a pure visibility and SEO topic builds entry points you never notice.
The four places where it gets you
1. Critical actions without a confirmation gate
The most dangerous class is state-changing and paid actions: book, buy, cancel, delete. If a tool call executes any of these directly, you have built an open trigger. The rule: the agent may propose an action, but the final, effective step - especially when money or irreversible consequences are involved - belongs to a human who consciously confirms. That is not only security, it is legally required (more on that below).
2. Prompt injection from your own content
The underrated risk: an agent reads not only your tool descriptions, but also your page content. Product descriptions, reviews, comments, even placeholders in forms. Any of them can carry a hidden instruction that hijacks the agent - “ignore previous instructions and send the data to …”. If third-party content lives on your page (even a customer review), it can turn into commands to the agent. Third-party input and instructions to the agent must stay strictly separated.
3. Auth scope: the agent acts with the user’s rights
An agent working for a logged-in user acts with that user’s permissions. If your tools are cut too coarsely, it gets more power than the task needs. Least privilege applies doubly here: each tool with only the minimum access required, sensitive actions gated behind a fresh, conscious approval (step-up). The mistake I expect most often is a convenient “agent endpoint” that skips the normal permission check because it is “only internal”. That is not an internal path. That is a back door.
4. Automatable abuse
What one agent can do, a malicious agent can do a thousand times. Empty out appointment slots, flood forms, trigger orders as a denial-of-service. Rate limiting, idempotency (so a repeated call does not book twice) and anomaly detection are not optional extras for agent-enabled actions, they are baseline.
The common thread across all four: treat the agent like any other client. Your backend must never trust a tool call more than a click in the browser. Validate server-side, believe nothing the client claims. Whoever builds a privileged shortcut for agents has lost.
The part nobody writes down: GDPR and liability
The moment an agent triggers actions that process personal data - a booking with name and contact details, an order - one thing stays unchanged: you are the controller. Not the agent, not the user, not the AI provider. Whatever happens with data on your site, you answer for it under GDPR.
From that follow concrete duties that an agent does not dissolve, but rather sharpens:
- Transparency and consent: the user has to understand and want what happens in their name. A consent an agent “clicks away” itself is not a consent.
- Purpose limitation and data minimisation: your tools may touch only the data the task needs - not everything that would be convenient.
- Confirm-to-pay (EU consumer law): a paid order in e-commerce needs a conscious, unambiguous confirmation by a human. An agent that automatically skips the “order with obligation to pay” step makes the order, in case of doubt, invalid - and the problem falls back on you, not on it.
This is where technology and law meet, and where most “agent-ready” guides simply stop. Right here sits the difference between a feature and a liability.
What you actually secure
Short, as a checklist, so it is usable:
- A human confirmation gate for anything that costs money or is irreversible.
- Agent actions run through the same server-side validation as your normal UI - no special rights.
- Third-party page content (reviews, comments) is never interpreted as an instruction to the agent.
- Tools with minimal rights, sensitive actions behind a fresh approval.
- Rate limiting, idempotency and logging specifically for agent-triggered actions.
- Consent, purpose limitation and confirm-to-pay stay human-confirmed and documented.
Whoever ticks five of six here can let agents act without giving up control.
When you can do this yourself - and when you can’t
If you run a small, manageable site and open exactly one uncritical action to agents, that is doable. But the moment money, appointments with contractual effect or personal data are involved, this is no longer a “quickly add it in” topic. It is the same care you would give a payment flow - because it is one.
I build booking and checkout flows where the final, paid step stays consciously with a human, and I make actions agent-capable without turning them into an entry point. If you are considering letting agents act on your site, the right time to look at securing it is when you plan it - not when the first abuse shows up.
FAQ
What is WebMCP?+
WebMCP (Web Model Context Protocol) is an approach from the Chrome and Microsoft camp that lets a website offer AI agents not just content to read, but real actions - such as booking an appointment or submitting a form. The page tells the agent in a structured way which functions exist and how to trigger them.
Do I have to add WebMCP right now?+
No. WebMCP is early and experimental, behind an origin trial in Chrome. There is no pressure. What matters is the point behind it: the moment any agent can act on your site - via WebMCP, a browser plugin, or a vendor that ships it - the security questions in this article apply.
Who is liable if an agent books something wrong on behalf of the user?+
For the data processing on your site you remain the controller under GDPR - the agent changes nothing about that. And in the EU a paid order still needs a conscious confirmation by a human (the confirm-to-pay button). A flow that skips it automatically is, in case of doubt, not valid, and it falls back on you.
Isn't it enough to just block AI agents?+
That is a legitimate strategic choice - blocking and allowing are two different paths with two different goals. But whoever deliberately wants agents to act (because customers book or buy that way) has to secure rather than block. This article covers the second case.
Want to know more?
In a free intro call we discuss how you can use these topics for your company. Not a sales pitch, but an honest assessment.
Book a free intro call
