Anthropic introduced the Model Context Protocol (MCP) on 25 November 2024 as “an open standard that enables developers to build secure, two-way connections between their data sources and AI-powered tools”. In practice, MCP lets an AI assistant call local programs, called MCP servers, that read files, query databases, or reach the web on its behalf. That is genuinely useful, and it is also a new kind of attack surface: the model decides which tool to call based on text it read, and it cannot always tell your instructions apart from someone else’s.
How an MCP server actually runs
The MCP specification defines two transports. Over stdio, “the client launches the MCP server as a subprocess” and the two talk over standard input and output. Over Streamable HTTP (which replaced the original HTTP+SSE transport from the November 2024 spec), the server runs as its own local process and the client sends it HTTP requests, optionally receiving a stream of Server-Sent Events back (MCP specification, transports). Either way, a local MCP server usually runs with the same file and network permissions as the person who started it, because nothing in the protocol requires otherwise.
The specification itself flags the risk of the HTTP variant directly: it requires servers to validate the Origin header, recommends binding to 127.0.0.1 rather than 0.0.0.0 when running locally, and calls for authentication on every connection, warning that without these, “attackers could use DNS rebinding to interact with local MCP servers from remote websites.”
The mechanism: a confused deputy
The classic name for this failure mode is the confused deputy problem: “a computer program that is tricked by another program (with fewer privileges or less rights) into misusing its authority.” An AI agent with MCP tool access is a deputy with real authority — to read your files, to make network requests — acting on instructions that can arrive from content it was only asked to summarize or analyze. When that content contains its own instructions, the agent may follow them instead of, or in addition to, yours. This is what OWASP’s Top 10 for LLM Applications class of risks calls prompt injection and excessive agency: OWASP: Top 10 for LLM Applications; OWASP LLM01:2025, Prompt Injection.
A demonstrated case: the GitHub MCP server
This is not theoretical. On 26 May 2025, Invariant Labs reported a proof-of-concept against the official GitHub MCP server, which had roughly 14,000 GitHub stars at the time. Their setup: an agent with access to a public and a private repository was asked to review open issues on the public one. A crafted issue in the public repo carried hidden instructions; the agent, reading it as part of its normal task, followed them, and in the demonstration went on to expose private-repository details, including information the researchers describe as personal, to the attacker-controlled issue thread. Invariant Labs was explicit that this was a demonstrated proof-of-concept on test repositories, not an attack observed in the wild, and that “this is not a flaw in the GitHub MCP server code itself, but rather a fundamental architectural issue that must be addressed at the agent system level.” The model used in the demonstration was Claude 4 Opus.
The lethal trifecta
On 16 June 2025, Simon Willison named the pattern behind cases like this the “lethal trifecta”: an agent that has (1) access to private data, (2) exposure to untrusted content, and (3) a way to communicate externally. “If your agent combines these three features, an attacker can easily trick it into accessing your private data and sending it to that attacker.” He names MCP specifically as a contributor: “The problem with Model Context Protocol — MCP — is that it encourages users to mix and match tools from different sources that can do different things,” which makes it easy to end up with all three properties active in one session without deciding to.
Why this is hard for endpoint tools to see
From the operating system’s point of view, nothing unusual happened in the GitHub MCP case: a signed, trusted application read some text and made a network request through a local helper process it was configured to use. There is no malicious binary to flag and no exploit of a memory-safety bug. The request that matters — the one carrying data out — is the same shape as any other tool call the agent makes correctly a hundred times a day.
What actually reduces the risk
- Give each MCP server the narrowest tools and file scope it needs, not broad filesystem or shell access, so a hijacked tool call has less to do.
- Treat any content an agent reads from outside your control (issues, web pages, downloaded files) as untrusted input, the same discipline you would apply to user input in any other system.
- Follow the transport-level guidance the MCP spec itself gives: bind local servers to localhost, require authentication, validate the Origin header.
- Watch, or control, the one step every version of this attack shares: the outbound connection that would carry data to the attacker. That step happens after the model has already been fooled, which is why it is the most reliable place to catch it.
How FireAI and HisnLabs fit in
The step an injected agent cannot skip is the outbound connection that carries your data out, which is exactly what a per-app firewall like FireAI is built to see and stop, whether the process asking to connect is a familiar app or an MCP server it has never seen before.
FireAI is HisnLabs’ own product: an on-device AI firewall for Mac. It shows every connection your apps make, in plain language, and lets you decide what leaves your Mac — its AI runs locally, so your traffic is never sent to us or anyone else. HisnLabs’ security research team is the group that keeps that decision-making accurate: cataloguing which domains are ordinary telemetry versus a real product, tracking the country and network behind a connection, and training the on-device model (its Autopilot feature) on real traffic patterns, all without any of it leaving your Mac.
You can read the technical decisions behind it, or try FireAI for 17 days, at FireAI, by HisnLabs.