MCP Security: The Real Risks of Connecting AI to Your Systems, and the Controls That Work
MCP security is mostly about two things: what an AI assistant can be tricked into doing, and what it is allowed to reach when it is. The documented risks are prompt injection through tool output, poisoned tool descriptions, shared or over-broad tokens, confused deputy flaws in proxy servers, unvetted community servers and no record of what happened.
The controls that work are plain ones: each person signs in with their own login, access is read-only until there is a reason for more, only approved servers are allowed, every call is logged, and a person confirms anything that writes or sends.
Why MCP changes the security question
MCP, the Model Context Protocol, is the open standard that lets Claude, ChatGPT and Copilot connect to other software: the CRM, the inbox, the file store, an internal database. Before connectors, the worst an employee could do with a chatbot was paste the wrong thing into it. With connectors, the assistant reads and acts in your systems on that person’s behalf.
That shift moves the risk. The question is no longer only “what did someone type into the AI?” but “what can the AI read, what can it change, and who decided that?”. The model itself cannot reliably tell an instruction from you apart from an instruction hidden in an email it was asked to summarise. So security has to come from the permissions around it, not from the model behaving well.
The MCP project publishes its own security best practices alongside the specification, and the OWASP Top 10 for LLM Applications ranks prompt injection (LLM01) first and lists excessive agency (LLM06), meaning an AI given more functions, permissions or autonomy than the task needs. Both sources point at the same answer: limit what each connection can do.
The seven documented MCP security risks
These are the risks that have been demonstrated or written into the specification’s guidance, not hypotheticals.
| Risk | What happens | Documented by |
|---|---|---|
| Prompt injection through tool output | An email, document, web page or ticket the AI reads contains instructions, and the AI follows them with the user’s access. | OWASP LLM01; Invariant Labs, GitHub MCP |
| Tool poisoning and shadowing | A malicious server hides instructions in its tool descriptions, which the AI reads but the user rarely sees. It can also change how the AI uses other, trusted tools. | Invariant Labs, WhatsApp MCP |
| Over-broad tokens and shared keys | One API key or token with wide access is shared by everyone, or held by a server that can do far more than any one user needs. | MCP security best practices |
| Confused deputy | A proxy MCP server uses its own authority with a third-party service to act for a client that was never meant to have that access. | MCP security best practices |
| Unvetted community servers | Someone installs a server from a public list. Local servers run with that person’s own privileges on their machine. | MCP security best practices |
| Data exfiltration | The AI is steered into sending data somewhere: a public pull request, an email, a link with the data in it. | Invariant Labs, GitHub MCP |
| No audit trail | Calls go straight from each person’s assistant to each system, so nobody can say afterwards what the AI read or changed. | The gap every incident review runs into |
The GitHub case is the clearest example. In May 2025 Invariant Labs showed that a crafted issue on a public repository could make an agent using the official GitHub MCP server read data from the user’s private repositories and publish it in a pull request on the public one. Nothing in the server was broken in the usual sense. The token simply had access to both public and private repositories, and the agent did what the text in the issue told it. Invariant’s advice was least privilege: give the agent access only to the repositories it needs.
The WhatsApp case shows tool poisoning. Invariant connected an agent to a legitimate WhatsApp MCP server and to a second, malicious server. Instructions hidden in the malicious server’s tool description changed what the agent did with the WhatsApp tools, including who messages went to. The attacker never touched the WhatsApp server. Being connected to both at once was enough.
The specification names two server-side flaws. The MCP security guidance calls “token passthrough” an anti-pattern, where a server accepts a token that was not issued for it and forwards it to another service, and the authorization specification forbids it. It also says proxy servers that connect to third-party APIs must get consent per client, to avoid the confused deputy problem.
The combination that turns a risk into a leak
The developer Simon Willison gave the pattern a useful name in June 2025: the lethal trifecta. An AI that has all three of these at once can be made to leak data:
- Access to private data, such as a CRM, inbox or private repository.
- Exposure to content someone outside the company wrote, such as an email, a ticket or a web page.
- A way to send data out, such as sending email, posting, creating a link or opening a pull request.
Each connector on its own may be harmless. The risk comes from a person having the inbox, the CRM and a tool that sends, all in the same conversation. That is why MCP security is a question of which combinations you allow, per group, rather than a yes or no per tool.
MCP security best practices that work
None of these need new technology. They need someone to decide them once, for the whole company.
| Control | What it stops | How to do it |
|---|---|---|
| Per-user OAuth instead of shared keys | One leaked key exposing everything; actions nobody can trace to a person | Each person signs in to each system with their own account, so the AI can reach only what that person can |
| Read-only by default | Exfiltration and damaging writes from injected instructions | Grant write access per system and per group, where the time saved is clear |
| Least privilege in scopes | Wide tokens like the one in the GitHub case | Ask for the narrowest scopes, limit to the repositories, folders or records needed |
| An approved list of servers | Tool poisoning and unvetted community servers | Only servers someone has reviewed; everything else blocked or kept out of company accounts |
| Human approval for writes | An injected instruction becoming an email, a payment or a deleted record | The person sees what will be sent or changed and confirms it |
| A log of every call | Not knowing what happened | Who, which assistant, which system, which tool, when; exportable to your own tools |
| Separate risky combinations | The lethal trifecta | Groups that read outside content do not also get tools that send data out without approval |
Two notes on the list. First, the MCP specification includes tool annotations such as a read-only hint, but it is explicit that annotations from an untrusted server are only hints and should not be relied on for security decisions. A malicious server can label a destructive tool as harmless. Read-only has to be enforced by the permissions, not by the label. Second, the specification also recommends that a person can always deny a tool call. Most assistants ask before a tool runs, but people click through prompts they see fifty times a day. Keep approvals for the actions that matter, so the prompt still means something.
The quickest way to connect a system is one admin API key pasted into a server configuration. It works, and it means every user acts with the admin’s rights, and the system’s own logs show one account doing everything. If you fix one thing this quarter, replace shared keys with each person’s own login wherever the system supports it.
If you build or run an MCP server
If your developers build MCP servers for internal systems, the specification sets the bar. Remote servers that use authorization follow OAuth 2.1, must publish protected resource metadata so clients find the right authorization server, and must check that each token was issued for that server. Our guide to MCP governance and authentication walks through how that works in plain language.
- Validate that every token was issued for your server. Never pass a client’s token on to another service.
- If your server is a proxy to a third-party API, get consent per client before using your own credentials.
- Check permissions per tool on the server, not only from the scopes in the token.
- Ask for the smallest scopes first and request more only when a tool needs them.
- For local servers, prefer the stdio transport and do not leave an unauthenticated port open on the machine.
- Treat everything a tool returns as untrusted text, including content from your own systems that outsiders can write to.
Where a gateway helps, and where it does not
An MCP gateway sits between the assistants and the servers. Because every call passes through it, it is the natural place to keep the approved list, map access to groups, hold the connections and keep the log. It turns the controls above from a policy into the default.
What a gateway cannot do is make prompt injection go away. No product reliably detects every hidden instruction, and vendors who claim to are worth questioning. What it can do is shrink the damage: if the group that reads support tickets cannot send email without approval, an injected “forward this to” instruction goes nowhere. Pair it with a short AI policy so people know which tools and which data are allowed, and with the wider practice of AI agent governance as assistants start acting on their own.
A one-week start
- Day 1: inventory. Ask each team which MCP servers and connectors they use, in which assistant, with whose login. Expect some shadow AI.
- Day 2: find the shared keys. List every connection that uses one account or API key for many people.
- Day 3: decide the approved list. Which servers, for which groups, read or write.
- Day 4: mark the sending tools. Email, messaging, publishing, payments. These get human approval.
- Day 5: name an owner and turn on logging. One person who adds and removes servers and can answer “what did the AI touch?”.
Data terms matter too, but they are a separate question: on business plans Claude, ChatGPT and Copilot do not train on your content. See whether your data is safe in Claude and our guide to AI data governance.
Where Deployed OS fits
Deployed OS is an MCP gateway that puts these controls in one place. Your systems are connected once and used from Claude, ChatGPT and Copilot. Each person signs in with their own login where the system allows it, user groups decide who may read or write in which system, and every call is logged and can be exported. Company guardrails come with every question, so a rule such as “never delete anything in the CRM” applies to everyone. It is built by an EU company, and you choose where the data is stored.
Want to see what each person in your company could reach through AI before a wider rollout? We connect Deployed OS to your own systems with your team and show it, system by system. See every connector.
Frequently asked questions
What are the main MCP security risks?
The documented risks are prompt injection through content the AI reads, poisoned tool descriptions from malicious servers, shared or over-broad tokens, confused deputy flaws in proxy servers, unvetted community servers, data exfiltration and the lack of an audit trail. Most of them do damage because a connection has more access than the task needs.
What is MCP tool poisoning?
Tool poisoning is when a malicious MCP server hides instructions in its tool descriptions, which the AI reads but the user rarely sees. Invariant Labs showed in 2025 that such a server could change how an agent used a separate, legitimate WhatsApp server, including who messages were sent to. The defence is to allow only MCP servers someone has reviewed.
How do you secure an MCP server?
Use OAuth so each person signs in with their own account, request the narrowest scopes, check that every token was issued for your server and never pass a client token on to another service. Check permissions per tool on the server, and treat everything a tool returns as untrusted text. These points follow the MCP specification and its security best practices.
Can prompt injection be prevented in MCP?
Not reliably. No current model or product detects every hidden instruction in an email, document or web page. What you can control is the damage: read-only access by default, no tools that send data out without a person approving, and separate groups for people who handle outside content.
What are MCP security best practices for a company?
Replace shared keys with each person’s own login, make read-only the default, keep an approved list of MCP servers, require a person to confirm anything that sends, publishes or deletes, and log every call with who, which assistant, which tool and when. An MCP gateway puts these controls in one place for every assistant.
Does an MCP gateway make MCP secure?
It makes the controls enforceable rather than optional: one approved list, access per group, credentials held centrally and a log of every call. It does not stop prompt injection on its own. It limits what an injected instruction can reach, which is where most of the real protection comes from.
Found this useful? Send it to someone who needs it.