The agentic web is arriving with the liability pre-assigned

There are two stories running in the SEO trade press this week, and almost nobody is reading them together.

The first is Chrome's WebMCP security guidance, published on developer.chrome.com and covered by Search Engine Journal. It tells websites — not agent builders — how to defend themselves and their visitors from prompt-injection attacks that arrive through the tools those websites voluntarily expose to visiting AI agents. The second is the new IQRush research showing that AI visibility dashboards produce rankings so unstable that thirty to ninety citation-carrying answers may be needed before you can distinguish a real difference from statistical noise.

These are the same story. They are both about a protocol layer being built at speed, sold to marketing departments as a discovery opportunity, with the failure modes quietly reassigned to whoever's most eager to be "agent-ready."

The industry framing right now is: get onto the agentic web early, expose your tools, get cited, win. What almost nobody is saying is that being early on this specific protocol layer means you are the one absorbing the liability, the measurement error, and the operational cost of a system designed to be attacked through you and measured by dashboards that cannot yet tell you whether it's working.

This is a piece about what that actually means, and what a serious operator does about it.

The state of play, briefly

WebMCP is the next-generation version of a question that's been running since ChatGPT started browsing: how does an AI agent actually interact with your website?

The old answer was "it reads your HTML and hopes." Some of the SEO industry called this crawlable-and-parseable, some called it llms.txt, John Mueller — as I wrote about last week — called most of the parallel-content-for-agents playbook a waste of time. WebMCP is the more useful direction. Instead of an agent scraping your product page and guessing whether the "add to basket" button will do what it says, you register named tools on your own site: `search_products`, `add_to_cart`, `check_delivery`, and so on. The agent calls those tools directly. It stops guessing.

That's genuinely progress. It's also a much larger attack surface than a static HTML page.

Chrome's security guidance describes two ways that surface gets exploited. The first is a malicious manifest — a tool whose description contains hidden instructions the agent reads and follows. That one is obvious enough. The second is subtler and much more common. Chrome calls it contaminated output: a legitimate tool on your own trusted website returns text that other people wrote — reviews, comments, forum posts, support messages — and one of those people has planted an instruction inside. Your tool hands that instruction to the agent as if it came from you. The payload arrives through your infrastructure, wearing your credibility.

The line from the Chrome documentation is the one that matters: *"the probabilistic nature of LLMs makes it impossible to guarantee safety inside the model itself."* This isn't a bug that gets patched. Language models cannot reliably separate the data you meant them to have from the commands an attacker slipped inside that data. That's the shape of the problem forever. The protocol layer just gives it a cleaner delivery route.

The liability has already been assigned. It's yours.

Read Chrome's guidance carefully and one thing becomes unambiguous: the security burden sits with the publisher, not the agent.

The security model of the agentic web is: publishers defend themselves and their visitors, agent-makers ship the interface.

The opening line of the tool-security document is written for whoever exposes the tools: *"Only expose your tools to origins that you trust. This is particularly important when tools manage user data or otherwise impact the user."* The defensive mechanisms — `untrustedContentHint`, `readOnlyHint`, `exposedTo` — are annotations you attach to your own tool definitions. The Chrome documentation politely reminds you that if your tool returns user-generated content, you *"should consider adding the untrustedContentHint."* The word "consider" is doing an enormous amount of work in that sentence.

The security model of the agentic web is: publishers defend themselves and their visitors, agent-makers ship the interface.

That is a genuinely important asymmetry, and it hasn't been priced into any of the "get agent-ready" pitches currently circulating in the UK mid-market. Every deck I've seen from vendors in this space frames WebMCP adoption as a growth opportunity. "Be discoverable by agents." "Win the citation race." What none of them mention is that once you register a tool called `book_appointment` or `apply_for_credit` on your website, you are the party responsible for making sure that tool cannot be turned against your visitors — and if it is, your name is on the manifest.

The parallel that keeps coming to mind is the early days of open-graph and structured data. When schema.org first shipped, the framing was "help Google understand your content." Ten years later the reality is: schema is now the primary substrate through which Google decides what your business *is*, and getting it wrong has direct commercial consequences. WebMCP tools have the same shape, but with attack surface bolted on. Getting the manifest wrong isn't a discovery problem. It's a security problem your legal team hasn't been briefed on because your marketing team hasn't finished being excited yet.

Why the measurement layer makes this worse

Now overlay the IQRush finding.

Most AI visibility dashboards are selling you a snapshot of a moving target and pricing it like a fact.

The Ron Sielinski paper — Sielinski runs IQRush, so there's a commercial motive, but the maths is corroborated by prior work from Rand Fishkin's team at SparkToro — asks a straightforward question. If your AI visibility dashboard says you get cited 9.5% of the time and your competitor gets 6%, is that a real difference or is that noise?

The answer, empirically, is: usually you can't tell. Across thirty platform-topic tests, the number of citation-carrying answers needed to produce a stable, meaningful ranking ranged from thirty-three to ninety-four. Three of the tests didn't produce a trustworthy ranking even after a hundred and twenty-five questions — all on SearchGPT, where the top sites clustered too closely to be distinguished at all.

Most AI visibility dashboards are selling you a snapshot of a moving target and pricing it like a fact.

This matters directly to the WebMCP conversation because the entire business case for adopting the agentic web protocol layer rests on the assumption that you can measure whether it's working. If a client spends six months hardening their WebMCP implementation, adding tools, exposing structured commerce endpoints, and their dashboard says their AI citation share rose from 4% to 7%, the honest answer — under the IQRush methodology — is that this could be a real gain, a real loss, or nothing at all. You cannot tell from the dashboard alone. You have to know how many answers underlie those percentages, how tight the margin of error is on each, and whether the gap between you and the reference point is wider than that margin.

Almost nobody's dashboard shows you that. Because if it did, most of them would have to admit they can't yet tell you anything statistically meaningful.

So the operational picture, spelled out: you're being asked to invest in a protocol layer that transfers liability to you, secured by defensive annotations most vendors won't help you configure, measured by dashboards that cannot yet distinguish signal from noise, all in service of a discovery channel that consolidated 92% of its trackable referrals into a single provider (ChatGPT) inside eighteen months.

That's the loop. And we built it.

The steelman: why do this at all, then?

The strongest version of the counterargument is worth taking seriously, because it isn't wrong.

The counterargument goes: yes, WebMCP shifts liability toward publishers. Yes, the measurement layer is immature. But the direction of the agentic web is fixed. Agents are how a growing share of commercial intent will be expressed within three years. The alternative to registering tools on your website is having agents scrape it clumsily and get it wrong, at which point they either buy from a competitor whose manifest is cleaner or they abandon the transaction. Being early to a hard problem is how you build the institutional muscle to run the hard problem well. Waiting until the measurement is clean means waiting until the market is closed.

I think most of that is right. The direction is genuinely fixed. Agentic commerce is coming, WebMCP or something like it will be the substrate, and businesses that treat this as an "wait and see" question will lose ground the same way businesses that ignored mobile in 2011 lost ground.

Where I diverge is on what "being early" should look like.

The default framing — the one being sold in decks — is: expose tools broadly, race for citations, measure with whatever dashboard your agency provides, sort it out later. That's not being early. That's being a beta tester who's paying the vendor for the privilege.

Being early done properly means something quite different: expose the narrowest possible set of tools that solves a real user problem, annotate every one of them defensively before shipping, log everything server-side so you can reconstruct actual agent behaviour without relying on third-party dashboards, and measure adoption in terms your CFO already trusts — orders completed, appointments booked, applications submitted — not citation-share vanity metrics.

The difference is between running toward the frontier with your eyes open and running toward it with a vendor telling you which direction to run.

What the sensible playbook looks like

I'm not going to pretend I have this fully worked out. Nobody does. But there are a handful of positions that I'd defend and that I think the industry is either avoiding or getting wrong.

Every tool you register on your website is, functionally, a public API. It has an interface, it accepts parameters, it returns data, and — critically — it's callable by any agent that lands on your page. The security posture required is the same one your engineering team would apply to a public API: input validation, rate limiting, output sanitisation, audit logging, and a threat model that assumes hostile input.

The marketing framing of WebMCP is that it's a discoverability upgrade. That framing is wrong in the way that "just add this pixel" was wrong about GDPR. It's a technical, security-first change that has discovery consequences, not the other way around.

If your web team isn't ready to treat tool registration as a full-blown API deployment — with the review process, security signoff, and monitoring that implies — you shouldn't be exposing tools yet. Wait. The people rushing you to be first almost universally aren't the people who'll be answering the incident report when a review-injection attack goes through your `redeem_credit` endpoint.

Chrome's guidance says to *"consider"* adding `untrustedContentHint` to tools returning user-generated content. Ignore the softening. Any tool that returns text sourced from anywhere other than a controlled internal system should carry that annotation from the day it ships. Reviews, comments, forum posts, chat transcripts, uploaded documents, third-party feeds — all of it.

The same goes for `readOnlyHint`. Every tool that doesn't change state should be marked as such. This gives the agent the information it needs to decide when to ask the human user for confirmation. Skipping the annotations doesn't make the tool more powerful — it makes the agent less able to protect the person you sent it to.

The `exposedTo` restriction, where you enumerate the trusted origins that can call your tools, is the strongest defensive lever and probably the most underused. If your tools only make sense in the context of specific agent providers, restrict them explicitly. The Chrome documentation cap of a few dozen characters isn't a limitation — it's a nudge to be intentional about which agent ecosystems you're serving.

Given what the IQRush research shows about dashboard reliability, and given what my last piece on the Google reviews bug argued about third-party citation monitors, the operational conclusion is straightforward: if you're serious about the agentic web, you need first-party logs.

Every WebMCP tool call hits your server. That's a log line. It has a timestamp, a caller identity (where available), the parameters passed, the response returned, and — with a little instrumentation — a session ID that lets you reconstruct what the agent was trying to accomplish. That's data no dashboard has, because it's data no dashboard can have. It's yours.

Log everything. Analyse it monthly. The signal you'll find in your own server logs is worth ten of anything a vendor sells you as an AI visibility metric. It's also the only reliable way to catch the attack patterns Chrome describes. If an agent starts calling your `submit_form` tool with parameters that look suspiciously like the injected instructions from a review, you want to see that in your logs before you see it in a compliance email.

I wrote about this at length in the CFO piece, but the WebMCP context sharpens it. The temptation with any new channel is to invent new metrics that flatter early progress. "AI citation share up 40%." "Agent visibility index rose to 12." These metrics exist because the underlying commercial outcome hasn't yet moved enough to be worth reporting.

Don't do this. If you're investing meaningful budget in WebMCP adoption, tie the reporting to the same outcomes you'd report on any other channel: transactions initiated, conversions completed, revenue attributed. If the agentic web is going to matter commercially — and I think it is — it will show up in outcomes eventually. If it doesn't show up in outcomes for eighteen months, that's information worth having, not something to paper over with a proxy metric.

WebMCP as it exists today will not be WebMCP in three years. The security model is under active revision, the specification is still forming, the browser support is uneven, and the enforcement patterns are being figured out in real time. Anyone telling you to build a permanent competitive advantage on the current version of the protocol is selling optimism as strategy.

The competitive advantage on offer isn't "be first on the current spec." It's "build the internal capability to adapt to whatever the protocol becomes." That capability — clean tool-definition practices, defensive annotation by default, server-side logging, security review as part of shipping — is durable. The specific tools you register today are not.

Design your implementation so that the tools themselves can be added, removed, and rewritten quickly. Version everything. Deprecate cleanly. The teams that will look best in 2028 are the ones who can retire an entire manifest and rebuild it in a week, not the ones who spent six months hand-crafting a manifest that the protocol subsequently reshaped underneath them.

The bit the industry keeps skipping

There's a specific class of business that is going to get hurt by this that nobody's talking about: the mid-market UK business with a decent website, no in-house security team, and an agency partner who's just discovered WebMCP as a service line.

That business doesn't have a threat model. It doesn't have a security review process. Its logs are, generously, patchy. Its agency's WebMCP proposal will present the work as an SEO upgrade — "make your site agent-ready, capture the emerging citation surface" — with a five-figure price tag and a case study from a fictional or heavily-anonymised client.

Six months in, one of two things happens. Either the implementation quietly does nothing measurable because the measurement layer can't yet detect what it did, or it does something bad — an injection attack through a review-return tool, an agent-driven form submission that bypassed a captcha, a support-ticket tool being used to exfiltrate other users' data. Either way, the agency's contract has language that puts the liability on the client, the client's insurance policy doesn't cover agent-mediated attacks because they're a new category, and the resulting mess sits with a business owner who was told this was a marketing initiative.

I'm not writing this to be melodramatic. I'm writing it because this is the entirely predictable shape of the next eighteen months for a chunk of my client base, and the SEO trade press is treating WebMCP as a citation-share opportunity rather than what it actually is: a shift in the protocol layer with real legal and operational consequences that most of the businesses being sold it don't understand.

The asymmetry between what agent-builders ship and what publishers absorb is not a niche technical concern. It's the central fact of this whole conversation. And it interacts badly with the measurement problem the IQRush research just documented — because if you can't reliably measure whether the risky thing you did paid off, the honest business calculation is very different from the one being presented in the pitch decks.

What I'd actually tell a client this week

If a mid-market UK business asked me on Monday whether to adopt WebMCP, my answer would be conditional and probably disappointing to whoever's trying to sell them the service.

I'd say: the protocol layer is real, the direction is right, and the businesses that eventually run this well will benefit. But "eventually" is doing serious work in that sentence. Right now, in mid-2026, the honest position is that the security model is publisher-hostile by default, the measurement layer isn't good enough to tell you whether your work is paying off, and 92% of trackable AI referrals go through a single provider (ChatGPT, per the consolidation data from earlier this year) which means the "diversify across agents" pitch is largely fictional at current volumes.

The sensible move for most mid-market businesses is a narrow, defensive pilot: one or two tools, all read-only, all defensively annotated, all server-side logged, all reviewed by whoever handles your security posture. Run it for six months. See what actually appears in your logs. See whether any of it converts. Then decide whether to expand, based on evidence you gathered rather than a dashboard someone sold you.

The businesses that will win the agentic web are not the ones who moved fastest. They're the ones who built the institutional capability to move well when moving matters, and who resisted the pressure to move poorly in the meantime.

That's an unfashionable position. The industry incentive right now is to sell urgency, because urgency is what gets budget released. But if my job is to give clients the advice that leaves them better off in three years rather than the advice that gets me the biggest project fee this quarter, the advice is: slow down, log everything, annotate defensively, measure what a CFO trusts, and don't let anyone tell you that being early is the same thing as being ready.

Most of the businesses being pitched WebMCP right now aren't ready. That's not a failure. That's an honest starting position, and it's the one to work from.