Two attack surfaces in one install
Lesson 1 of 5 in Supply Chain and MCP Security: Code You Run, Content You Trust.
You already know how to reason about a dependency: read who published it, pin the version, watch the CVE feed. Hold that instinct — you will need it — and then add the half that is genuinely new.
An MCP server — or any tool integration you hand an agent, including a plain function calling tool wrapping somebody else’s SDK — is code you run plus content you trust. Two attack surfaces arrive in one install, and they fail in completely different ways.
Code you run. The server is a process. A local stdio server is launched by your host application, on your machine, with credentials you pasted into its environment. A remote server is somebody else’s service holding a token you issued. Either way something executes that you did not write — ordinary supply-chain risk, with one unusual trigger: the model decides when it runs.
Content you trust. The server controls its own tool names, its tool descriptions, its schemas, and every byte of every result. All of it lands in the context window as authoritative-looking text, in the same channel your system prompt uses. That makes the publisher of a tool an author of your prompt — a prompt injection surface that opens the moment you install, before the model calls a single tool.
| Question | An ordinary library dependency | An MCP server or tool integration |
|---|---|---|
What executes? | Code you called, in your process, at the point your code calls it. | A separate process (stdio) or a remote service, plus whatever it calls downstream. |
What triggers execution? | Your control flow. You can read the call site. | The model’s judgement at runtime, shaped by text the server itself supplied. |
What credentials are in reach? | Whatever your process already holds. | A token you deliberately handed it — commonly the broadest one that made setup work first try. |
Does it write into the model’s context? | No. A library returns values to your code. | Yes — twice. Tool names and descriptions at discovery; tool results on every call (tool-output poisoning). |
What does review culture look like? | Lockfiles, dependency review, SCA scanners, a CVE feed, years of habit. | Frequently a copy-pasted config block and a click on “Always allow”. |
How would you notice misuse? | Code review, CI, static analysis. | Only if the tool calls land in traces somebody actually reads. |
The bottom two rows are the whole problem. We built two decades of habit around the left column and roughly eighteen months of habit around the right, while the right column is the one where an attacker gets to write in the model’s ear.
Trace the touch points of a single install and you can see both surfaces open in sequence.
Where one installed server actually touches you
- You add the server to host config
A command, a package spec, and an environment variable holding a credential. This step is usually a copy-paste from a README.
- Host launches the process / connects
Surface one opens: third-party code now runs with the environment you gave it (stdio), or holds a token you issued (remote HTTP).
- Client calls tools/list
The server returns names, descriptions, input schemas, optional output schemas and annotations — all attacker-controllable strings if the server is hostile.
- Names + descriptions enter the context window
Surface two opens. This happens whether or not any tool is ever called, and it happens in the same channel as your system prompt.
- Model decides to call a tool
Model-directed control flow means the description you skimmed is now competing with your instructions for the model’s attention.
- Server executes with your credentials
Whatever the process does — read files, hit an API, open a socket — happens under the identity you configured, not the model’s.
- Result flows back into the context
Both the server’s own output and any content it relayed from the outside world. Honest servers relay poisoned data all the time.
- Next iteration reasons over all of it
Every later decision in the run is downstream of both surfaces.
Key terms: MCP, tool, prompt injection, tool-output poisoning, least privilege, supply-chain attack
Interactive checkpoint quiz (2 questions) — open this page in a browser to take it.