{"id":11488,"date":"2026-07-12T20:29:41","date_gmt":"2026-07-12T12:29:41","guid":{"rendered":"http:\/\/longzhuplatform.com\/?p=11488"},"modified":"2026-07-12T20:29:41","modified_gmt":"2026-07-12T12:29:41","slug":"the-webmcp-tools-you-expose-to-agents-can-be-used-to-hijack-them-via-sejournal-slobodanmanic","status":"publish","type":"post","link":"http:\/\/longzhuplatform.com\/?p=11488","title":{"rendered":"The WebMCP Tools You Expose To Agents Can Be Used To Hijack Them via @sejournal, @slobodanmanic"},"content":{"rendered":"<p><\/p> <div id=\"narrow-cont\"> <p>Add WebMCP to your website, and you hand visiting AI agents a set of named tools to call. Those same tools can be used to turn the agents against the people who sent them. Chrome\u2019s developer site now carries the security guidance for WebMCP, and much of it is written for the websites exposing the tools rather than the companies building the agents. Make your website agent-ready with WebMCP, and you have also opened an attack surface, and closing it is your job, not the agent\u2019s.<\/p> <p>For two years, the agent-readiness conversation has been about access: Can an agent reach your content, read your page, finish your checkout? WebMCP is the version where you stop hoping an agent figures your website out from the markup and start handing it named tools to call. That is the more useful protocol, and it is the direction the agentic web\u2019s protocol layer is moving. It is also where being legible to an agent and being safe for an agent stop being the same property.<\/p> <p><iframe class=\"sej-iframe-auto-height\" id=\"in-content-iframe\" scrolling=\"no\" src=\"https:\/\/www.searchenginejournal.com\/wp-json\/sscats\/v2\/tk\/Middle_Post_Text\"><\/iframe><\/p> <h2>Chrome Named Two Ways Agents Get Hijacked Through WebMCP<\/h2> <p>Chrome\u2019s agent-security guidance describes two attack vectors, and both arrive through the tools a website exposes. The first is the malicious manifest. In Chrome\u2019s words, \u201cWebsites may have tool definitions with hidden instructions, in tool names, parameters, or descriptions, designed to hijack the agent.\u201d A tool\u2019s description is text the agent reads to decide how to use the tool, so a description can carry an instruction the agent was never meant to follow.<\/p> <p>The second vector is the one most websites will actually hit, and it needs no malicious website at all. Chrome calls it a contaminated output: \u201cReal-time tool responses from otherwise trustworthy sites might include malicious instructions as part of third-party data, such as user comments.\u201d A tool on your own website that returns your product reviews, your comment threads, your forum posts, or your support replies is returning text other people wrote. If one of those people planted an instruction inside a review, your legitimate tool has handed it to the agent as if it came from you. The payload is your own user-generated content, and you invited it in.<\/p> <p>This works because of something that is not a bug and will not be patched. \u201cLLMs treat all text, instructions and user data, as a single sequence of tokens,\u201d the guidance says, so the model cannot reliably separate the part you meant as data from the part an attacker meant as a command. That is why Chrome says \u201cthe probabilistic nature of LLMs makes it impossible to guarantee safety inside the model itself.\u201d This is the same prompt-injection problem that has no clean fix inside the model, now wearing a protocol. WebMCP gives that attack a clean, structured delivery route through the tools you published on purpose.<\/p> <h2>Making A Website Agent-Ready Now Includes Making It Agent-Safe<\/h2> <p>Chrome\u2019s guidance puts the obligation on the website, not only on the agent. Chrome\u2019s tool-security document opens with a line aimed straight at whoever exposes the tools: \u201cOnly expose your tools to origins that you trust. This is particularly important when tools manage user data or otherwise impact the user.\u201d That line is written for whoever ships the tool. That means you.<\/p> <p>The defenses are concrete, and they are annotations you attach to the tools you ship. <code>untrustedContentHint<\/code> \u201cexplicitly labels the payload as untrusted, to help protect your site\u2019s integrity while providing a signal to the agent that this data requires heightened scrutiny,\u201d and Chrome says when to use it: \u201cIf a tool returns user-generated content (UGC) or externally sourced data, consider adding the untrustedContentHint to the tool.\u201d <code>readOnlyHint<\/code> marks a tool that does not change state, which \u201callows the agent to make better decisions about when to ask for user confirmations.\u201d <code>exposedTo<\/code> restricts a tool to an array of origins you trust, written into the registration itself:<\/p> <pre><code>document.modelContext.registerTool({...}, {&#13; exposedTo: [' });&#13; <\/code><\/pre> <p>Chrome caps the character budgets too, a tool description at 500 characters and a single tool output at roughly 1,500, and adds a <code>requestUserInteraction()<\/code> path for confirming an action before it fires. Take the obvious example, a tool that surfaces product reviews to a shopping agent. Securing it is not exotic work: mark its output with <code>untrustedContentHint<\/code>, set <code>readOnlyHint<\/code> because it reads rather than buys, and limit <code>exposedTo<\/code> to the origins you actually serve. None of that is the agent\u2019s job. It is the tool author\u2019s job, which on most teams is the web, CRO, or marketing people adding WebMCP to look current, not the security people who read threat models. That gap is where this goes wrong. Marking which of your content is data and not commands is now part of shipping a tool, the way sanitizing input became part of shipping a form.<\/p> <h2>Adopt WebMCP, But Threat-Model Every Tool First<\/h2> <p>Handing an agent explicit, callable tools beats making it guess your website from the DOM, and the capability is worth having. None of this is a reason to avoid WebMCP. The point is narrower and more boring than \u201cnew protocol, new danger\u201d: the capability arrives with a bill attached, and the bill is yours.<\/p> <p>So the line is simple. Do not expose a tool to an agent that you have not threat-modeled the way you would threat-model a public API endpoint. For every tool you are about to register, answer one question before it ships: What untrusted content can this return, and have you marked it? If you cannot answer that, the tool is not ready, however agent-ready the rest of your website looks.<\/p> <p>WebMCP is early. It sits in a Chrome origin trial, the specification is still moving, and most websites have not exposed a single tool. That is the window to decide agent-safe is part of agent-ready, before the first tool you ship turns out to be the one that hands an agent your reviews and whatever someone hid inside them.<\/p> <p><strong>More Resources:<\/strong><\/p> <hr\/> <p><em>This post was originally published on No Hacks.<\/em><\/p> <hr\/> <p><em>Featured Image: Roman Samborskyi\/Shutterstock<\/em><\/p> <\/div> <p>Generative AI,SEO#WebMCP #Tools #Expose #Agents #Hijack #sejournal #slobodanmanic1783859381<\/p> ","protected":false},"excerpt":{"rendered":"<p>Add WebMCP to your website, and you hand visiting AI agents a set of named tools to call. Those same tools can be used to turn the agents against the people who sent them. Chrome\u2019s developer site now carries the security guidance for WebMCP, and much of it is written for the websites exposing the [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":11489,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[16],"tags":[2126,35772,38647,80,18507,675,11085],"class_list":["post-11488","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-accessibility","tag-agents","tag-expose","tag-hijack","tag-sejournal","tag-slobodanmanic","tag-tools","tag-webmcp"],"acf":[],"_links":{"self":[{"href":"http:\/\/longzhuplatform.com\/index.php?rest_route=\/wp\/v2\/posts\/11488","targetHints":{"allow":["GET"]}}],"collection":[{"href":"http:\/\/longzhuplatform.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/longzhuplatform.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/longzhuplatform.com\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"http:\/\/longzhuplatform.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=11488"}],"version-history":[{"count":0,"href":"http:\/\/longzhuplatform.com\/index.php?rest_route=\/wp\/v2\/posts\/11488\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"http:\/\/longzhuplatform.com\/index.php?rest_route=\/wp\/v2\/media\/11489"}],"wp:attachment":[{"href":"http:\/\/longzhuplatform.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=11488"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/longzhuplatform.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=11488"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/longzhuplatform.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=11488"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}