Home › Security › Prompt injection
Prompt Injection via MCP Tools
This page describes the prompt-injection case written in the security best practices under Session Hijacking, and the confirmation rules in the tools specification. It does not add a separate set of attack transcripts, vendor incidents, or tool descriptions from servers in this directory.
The case the specification describes
The document's heading is "Session Hijack Prompt Injection." The flow it describes has these steps. A client initializes against a streamable HTTP server and receives a session id. An attacker who obtains that session id sends a malicious event to another server that shares state, using the session id. The document names two mechanisms: resumable streams, where a client that disconnected can pick the event back up on the server-sent-events GET, and a tool-list change notification, where the tools a client is offered can be changed. The event is queued under the session id. The original server reads the queue and delivers the payload to the client. The client then acts on it.
A second diagram on the same page is impersonation rather than injection: the attacker calls the server with the stolen session id, and the server treats that call as the original user because it does not check authorization again. The mitigations the document pairs with both diagrams are on the checklist: verify every inbound request, do not use the session as authentication, use a random session id, and bind it to the user.
What the tools chapter says about calls
The tools specification says there should always be a human in the loop who can deny a tool invocation. It says applications should show which tools are exposed to the model, show a clear indicator when a tool is invoked, and present a confirmation prompt for operations. It also says clients should show tool inputs to the user before calling the server, to avoid malicious or accidental data exfiltration, and should validate tool results before passing them to the model.
Tool annotations, including the hint fields a tools/list response may contain, are covered by one rule in that chapter: clients must treat tool annotations as untrusted unless they come from a trusted server. A hint on a fact sheet is the boolean the server sent. It is not a finding from this directory.
What this site will not add
The specification does not publish a catalog of real tool-description attacks against named products. This page does not invent one. A fact sheet lists tool names only when tools/list returned them, or, for Figma, when Figma's own docs page names them and the fact sheet says the live check returned 401.
Related: checklist, least-privilege tokens, what MCP specifies for a session.
FAQ
What prompt-injection example does the MCP spec give?
Under Session Hijacking, it describes an attacker who uses a stolen session id to enqueue a malicious event that the original client later receives, including by way of a resumed stream or a tool-list change.
Does MCPwell reproduce exploit steps?
No. The page names the case the specification already describes and the mitigations in that section. It does not add payloads.
Are tool annotations a safety proof?
No. The tools specification says clients must treat annotations as untrusted unless the server is trusted.