Every tool you connect is a tool your inbox can be talked into using
Connecting a tool server to an agent is a two-line change, which is exactly why it deserves more thought than it gets. Every server an agent connects to can return text into its context, and an agent that also has an inbox can be persuaded to send that text somewhere.
4 min read
Three distinct risks
Tool results as injection. Anything a server returns lands in the model's context, so a compromised or hostile server can attempt exactly what a hostile email attempts, per prompt injection by email. Fetched web pages, shared documents, ticket bodies, and search results are all attacker-writable in the general case.
Tool descriptions as injection. Less obvious and more interesting: the descriptions a server advertises are also text the model reads, and it reads them as instructions about how to behave. A server whose tool description says "always call this before send_email" has influenced your agent without returning anything at all.
Exfiltration through a tool you trusted. An agent with mail read access and a connected server that accepts arbitrary text has a data path out that does not look like sending email. A "log this" or "save note" tool on a third-party server is an exfiltration channel with good intentions.
Why email raises the stakes
Two reasons that compound.
An inbox is an untrusted input channel anyone can write to, so the attacker does not need to compromise a server at all: they can send a message that tells the agent to use one. And an inbox is an output channel to arbitrary recipients, so anything the agent can read from any connected tool can leave.
That combination means the interesting question for an agent with email is not "is this server trustworthy" but "what could this server make my agent send, and to whom".
Connecting a server safely
| Before connecting | Ask |
|---|---|
| Who operates it | A vendor with a security posture, or a weekend project |
| What it returns | Data you control, or arbitrary text from the internet |
| What it advertises | Read the tool descriptions, since the model does |
| How it updates | Can its tool set change under you without a version pin |
| What it needs | The narrowest credential that does the job |
| What it would cost | If it returned hostile text tomorrow, what is the worst outcome |
The fourth row is the one that gets missed. MCP servers can change their advertised tools at any time, so a server you audited in June may present different capabilities and different descriptions in September. That is a supply chain in the ordinary sense, and it deserves the ordinary answer: pin what you can, and re-check what you cannot.
The architecture that contains it
The defences are the ones already argued for email, applied one layer out.
Untrusted text never shares a call with privileged tools. Extract with a tool-free call, decide in your own code, then act with a call that never sees the raw text. That single split neutralises most of both injection paths, per prompt injection by email.
Least privilege per agent. The agent connected to third-party servers should not be the one holding vault grants or the ability to reach every mailbox, per deciding what each agent is allowed to see.
First contact is visible. Exfiltration by email almost always means sending to an address the agent has never corresponded with, which is the alert worth having above all others, per what to monitor in production.
Separate agents for separate risk levels. An agent that browses the web and an agent that emails customers can be two agents with two keys, and the one holding the inbox does not have to hold the browser.
What good practice looks like
- Connect the fewest servers that do this week's job.
- Read every tool description before connecting, and again after an update.
- Give each server the narrowest credential it can work with.
- Keep browsing and inbox capabilities on different agents where you can.
- Alert on first sends to new domains, always.
- Review connected servers quarterly alongside grants and keys, per the security review.
None of this is exotic. It is dependency hygiene applied to a dependency that talks.
The mirror image: being a server
If you publish an MCP server, the same trust runs the other way, and two things are worth doing for your users. Describe tools plainly, without instructions about when the model must call them, since that is the behaviour a hostile server exploits. And return data rather than prose, because structured output is harder to weaponise than a paragraph.
Our own surface is built that way deliberately: refusal reasons are stable strings rather than sentences, and the tool descriptions in the reference say what a tool does rather than telling the model what to do next.
Questions
- Can a connected MCP server attack my agent?
- Yes, in two ways: text it returns lands in the model's context, and the tool descriptions it advertises are read as guidance about behaviour. Both are injection paths.
- Why is email specifically risky here?
- An inbox is both an untrusted input channel anyone can write to and an output channel to arbitrary recipients, so anything readable through any connected tool has a path out.
- What is the most effective defence?
- Separating the call that reads untrusted text from the call that holds privileged tools, plus alerting on first sends to addresses the agent has never contacted.
- Should one agent hold every tool?
- No. An agent that browses the web and an agent that emails customers can be two identities with two keys, so a hostile page cannot reach the inbox directly.
- What changes when a server updates?
- Its advertised tools and their descriptions can change without warning. Re-read them after updates, and pin versions where the server supports it.
- What should a well-behaved server do?
- Describe tools plainly without telling the model when it must call them, and return structured data rather than prose. Both make the server harder to weaponise against its users.
Give your agent an address it can answer from.
Create an inbox