WebMCP Makes Tool Metadata A Trust Boundary

A June 2026 preprint, WebMCP Tool Surface Poisoning: Runtime Manipulation Attacks on LLM Agents, describes a class of attacks against AI agents that discover and use tools exposed by websites. The authors focus on WebMCP, a web-facing pattern where a site can register tools for an agent during a browsing session. Their key finding is practical: the tool list itself can become an attack surface when third-party scripts, dynamic registration, and persuasive metadata shape what the agent believes it can safely call.

This is not the same issue as a local agent control plane accepting commands from localhost. It is a browser-session problem. If a page can change which tools exist, how they are described, when they appear, or which origin they seem tied to, an agent may be steered toward the wrong action even before ordinary prompt injection begins. Teams building MCP-like browser integrations should treat tool identity, tool lifecycle, and metadata as security boundaries, not as UI hints.

The paper describes mid-session tool injection, where an attacker manipulates the set of tools visible to an agent after a session has already started. It separates the problem into tool hijacking and tool framing. Tool hijacking changes which tools are registered or available. Tool framing leaves a tool in place but changes how the agent interprets it through metadata such as the tool name, description, input schema, or read-only hint.

That distinction is useful because many agent reviews still focus on the final action: what command was run, what API was called, or what data was sent out. The WebMCP threat model moves attention earlier. If the agent chooses the action partly from a dynamic menu supplied by the web session, then the menu needs integrity. A malicious or compromised script does not have to break the model. It can try to make an unsafe tool look routine or make a safe tool disappear.

Developers often treat tool metadata as documentation for the model. A concise description helps the model decide when to call a tool. A schema tells it which arguments are acceptable. A read-only flag can suggest whether a call should be low risk. In ordinary software, labels and descriptions may be secondary to the code. In an agent system, those labels can affect control flow.

That means metadata should not be trusted just because it is formatted as configuration. A tool called safe lookup can still perform a write if the implementation permits it. A read-only hint can be wrong. A schema can omit important side effects. A description can be crafted to push an agent toward a sensitive call. Teams should review metadata changes with the same suspicion they apply to authorization policy changes, because both can change what the system is willing to do.

Web pages are not single-author documents. They often include analytics, tag managers, embedded widgets, ad scripts, support tools, payment code, and content delivered from separate origins. A browser-exposed tool system has to decide which parts of that page are allowed to register or modify tools. If the answer is effectively any script that runs on the page, the agent has inherited the page's entire third-party JavaScript risk.

That risk is different from a normal prompt-injection article hidden in page text. The attack surface is the runtime tool surface. The page can present a tool, race another registration, adjust metadata, or alter the agent's view during the session. Defenses that only tell the model to ignore untrusted page content are not enough if untrusted page code can change the list of trusted tools.

The Model Context Protocol security guidance emphasizes authorization, consent, and confused-deputy controls. Its OAuth proxy example warns that a server using static client identity and weak per-client consent can let an attacker skip meaningful user approval and obtain access tokens. The details differ from WebMCP tool injection, but the principle is the same: a convenience layer between a client and a powerful resource can become the place where consent gets blurred.

Browser-facing agent tools should make consent specific. The user or administrator should be able to see which origin is exposing the tool, which client is requesting it, which resource it can touch, whether it can write, and where any token or result will go. A generic browser approval or one-time workspace install should not silently cover every tool that appears later in the session.

Start with origin binding. A tool should have a stable identity tied to the origin, package, extension, or server that registered it. If the identity changes, the agent should treat the tool as new. If the metadata changes in a meaningful way, the system should create an auditable event and, for sensitive scopes, require approval again. Tool registration should be deterministic enough that a race or late script cannot quietly replace a safer option.

Then limit agency by default. Tools that read public information, read private data, write to external systems, send messages, alter access control, move money, create credentials, or execute code should not share one risk tier. The agent should receive the least powerful tool set needed for the current task. High-risk tools should require explicit human confirmation with the concrete action, destination, and affected resource visible outside the model's own generated prose.

Logging has to cover more than the final API call. Record tool registration time, origin, version, metadata hash, schema hash, permissions, requested scopes, user approval, invocation arguments, result class, and whether a third-party script participated in registration. If an incident happens, those records let a team answer whether the agent chose a bad tool, received poisoned metadata, or correctly used a tool whose backend did something unexpected.

The logs should also support revocation. If a tool description or schema is later found to be misleading, administrators need to know which sessions saw that version and which actions followed. Without lifecycle logs, teams are left reviewing chat transcripts and final outputs while missing the moment the tool surface changed.

The WebMCP paper shows a plausible class of attacks and proposes mitigations, but it does not prove that every MCP deployment has this flaw. MCP can be used in local, server-side, enterprise, and browser-adjacent ways. The risk depends on who can register tools, whether tools are origin-bound, how metadata is validated, which scripts run on the page, and what permissions the agent receives.

The safe conclusion is narrower and more useful: agent builders should stop treating tool discovery as harmless setup. Dynamic tools are part of the authorization surface. A secure design needs stable identity, consent that survives browser complexity, least privilege, lifecycle logging, and confirmation for actions that can affect accounts, data, systems, or money.