The Tool List an Agent Trusts Can Change Mid-Session

A June 2026 paper demonstrates that WebMCP, a protocol for exposing website tools directly to AI agents, can be manipulated after a session begins, not just at its start.

On June 4, 2026, a four-author group posted an arXiv preprint identifying a new attack class against WebMCP, a protocol the paper describes as enabling "websites to expose tools directly to AI agents, bypassing traditional user interfaces and introducing new security risks." WebMCP lets a website declare a set of callable tools that an agent operating on a user's behalf can invoke directly, without the agent needing to parse and interact with a rendered user interface the way a human would. That directness is the protocol's value proposition. It is also, per the paper, the source of a previously uncharacterized vulnerability.

The paper's diagnosis is structural: "the dynamic exposure of agent-accessible tools in WebMCP expands the attack surface of web sessions, especially when third-party scripts are involved." Because the tool set a website exposes to an agent can be dynamic, generated or modified by scripts running within the page, an agent's understanding of what tools are available and what those tools do is not fixed for the duration of a session. It can change while the session is in progress.

Naming the attack class

The paper introduces a specific term for this threat: Mid-Session Tool Injection, or MSTI, defined as attacks "in which attackers leverage third-party scripts to inject malicious tools during an active session." The word "mid-session" is the operative distinction from more familiar categories of prompt injection or tool poisoning, which typically describe manipulation occurring at the point a tool is first registered or a prompt is first constructed. MSTI describes manipulation that occurs after an agent has already begun operating, potentially after it has already established some level of trust in the tool environment it started with.

The paper further classifies MSTI into two distinct mechanisms, "distinguishing between Tool Hijacking and Tool Framing." Tool Hijacking, the paper explains, "modifies the set of tools visible to the agent through mechanisms such as the AbortSignal API or race conditions during tool registration." This is a manipulation of which tools exist from the agent's point of view, exploiting timing and lifecycle mechanisms in how tools are registered with the browser or runtime environment. Tool Framing operates differently, "influencing the agent's perception of tool roles through metadata fields such as tool name, description, readOnlyHint, and inputSchema." Rather than adding or removing tools, Tool Framing leaves the tool set intact but alters how the agent interprets what each tool does, potentially causing an agent to treat a tool marked with a read-only hint, or described innocuously, as safer or more limited in effect than it actually is.

Why metadata-level manipulation is the harder problem

Tool Hijacking exploits mechanisms, the AbortSignal API and registration race conditions, that are specific and in principle patchable through more careful lifecycle management. Tool Framing is a subtler problem because it does not require exploiting a timing bug at all. It exploits the fact that an agent's decision about whether and how to use a tool depends heavily on metadata the tool's own registration supplies, description text, a name, a schema, a hint about whether the tool is read-only. If a malicious or compromised third-party script controls that metadata, it can shape the agent's behavior without needing to break any lifecycle mechanism, simply by describing a dangerous tool in reassuring terms.

The paper reports that its "implementation demonstrates that both Tool Hijacking and Tool Framing can successfully disrupt the intended functionality of WebMCP." Both mechanisms, distinct in method, arrive at the same practical outcome: an agent acting on a tool surface it does not accurately understand.

The mitigations proposed, and what they presuppose

The paper outlines specific design recommendations, "binding tool identity to its origin, ensuring lifecycle consistency, enforcing data boundaries for third-party tools, and maintaining traceable logs of tool registration and invocation." Binding tool identity to origin would prevent a third-party script from injecting a tool that impersonates one declared by the first-party site itself. Lifecycle consistency addresses the race-condition vector directly, ensuring the tool set an agent perceives cannot silently change through timing manipulation. Data boundaries for third-party tools would limit what a third-party-supplied tool can access or affect, independent of how it describes itself. Traceable logs of registration and invocation would, after the fact, allow reconstruction of what tools were actually available and invoked at each point in a session, addressing the forensic gap MSTI otherwise creates.

Each of these recommendations presupposes infrastructure that does not yet broadly exist for WebMCP deployments. Binding tool identity to origin requires a verification mechanism most current implementations were not built with. Traceable logging of tool registration requires an audit layer sitting outside the page's own JavaScript execution context, since a compromised or malicious script is precisely the entity that cannot be trusted to log its own tool injection accurately.

Convergence with prior tool-identity findings

The paper's authors situate this work as extending prior findings on Model Context Protocol vulnerabilities, describing MSTI as arising from "WebMCP's unique tool lifecycle and structured metadata, making the tool surface itself an emerging security concern." The framing, that the tool surface itself, rather than any single tool or any single prompt, is the object requiring security attention, mirrors a broader pattern across concurrent research on agent-tool interfaces published in the same period: the point of failure is increasingly the binding between an agent's belief about what a tool is and what that tool actually does, rather than any flaw internal to the agent's own reasoning.

Open Questions

• What verification mechanism would allow an agent to confirm that a tool's declared origin matches its actual origin, in a way that a compromised third-party script cannot spoof?
• How would traceable logging of tool registration and invocation be implemented without trusting the same page execution context that a malicious script already controls?
• Does binding tool identity to origin fully address Tool Framing, given that a legitimately originating tool can still supply misleading metadata about its own effects?
• What is the practical cost, in latency or complexity, of enforcing lifecycle consistency for tool registration at the scale WebMCP is intended to operate, across arbitrary third-party scripts on arbitrary websites?
• If an agent cannot distinguish a read-only hint that is accurate from one that is falsified metadata, what fallback behavior should the agent adopt when a tool's declared safety properties cannot be independently verified?
• How does this attack class interact with the broader question of who is accountable when an agent takes a harmful action based on tool metadata that was manipulated by a third party neither the agent's operator nor the first-party website directly controlled?

The governance artifact is retained. The governance function is not.