On this page (8)
MCP is safe enough for business use when you control which servers are connected, what scopes they hold and which actions need a person's approval. The Model Context Protocol is a standard for passing tool calls and results, not a security boundary. The real risks are prompt injection through tool results, poisoned tool descriptions, untrusted or changed third-party servers, over-broad OAuth scopes and data leaving through one tool after being read through another. Each has known controls.
What actually changes when you connect an AI assistant to tools?
Without tools, an assistant such as Claude, powered by Anthropic, can only work with what a person pastes in. With MCP connectors it can read mail, documents, tickets and records, and it can act: send, update, create, delete. It does so with the permissions of the person or credential behind the connection. Two things follow. Anything the assistant reads may contain instructions written by someone outside your company. And any tool that can send data out is a possible path for that data to leave.
A simple test helps. Exfiltration through an assistant usually needs three conditions in the same session: access to private data, exposure to content an outsider controls, and a tool that can send information out, such as email, a web request or a write to an external system. Remove any one and the most damaging attacks stop working. Most of the controls below are ways of removing one of the three, or putting a person in front of it.
For how MCP works with Salesforce in particular, including the Salesforce-hosted servers and how they apply field-level security, see our separate guide on MCP and Salesforce. This article covers MCP risk in general.
What are the main MCP security risks?
| Risk | How it happens | Primary controls |
|---|---|---|
| Prompt injection via tool results | A document, email, web page, ticket or spreadsheet returned by a tool contains hidden instructions, and the model treats them as commands | Human approval for write and send tools; separate reading untrusted content from sending tools; inference hooks on Enterprise; user training on odd behavior |
| Tool poisoning | A server's tool descriptions or annotations contain instructions aimed at the model, or claim a tool is read-only when it is not | Use servers from parties you trust; review tool lists before approval; the MCP spec says clients must treat annotations from untrusted servers as untrusted |
| Untrusted or changed third-party servers | A server is malicious from the start, or a legitimate server later changes what its tools do | Approved server list; named owner per server; periodic review of tool lists; Anthropic warns server developers may update tool behavior unexpectedly |
| Over-broad OAuth scopes | A connector asks for every scope up front, so a stolen token or a confused model can reach far more than the task needs | Grant the smallest scopes; deny unnecessary requests at consent; prefer servers that ask for more access only when a privileged action is first attempted |
| Shared credentials | An admin connects a service with one credential that every member then uses | Use a credential limited to what all members may access, or per-user OAuth or managed authorization through the identity provider |
| Data exfiltration | Data read from one tool is placed in an outbound message, URL or write to another system | Block or require approval for outbound tools; restrict which connectors a role can combine; log tool inputs |
| Local server compromise | A locally installed server or a startup command in a config file runs arbitrary code with the user's privileges | Managed allowlists for Claude Code; approval prompts for project servers; sandboxing; no servers from untrusted packages |
| Token passthrough and confused deputy | A custom server accepts tokens not issued to it, or a proxy server skips per-client consent | For servers you build: follow the MCP authorization spec, validate token audience, implement per-client consent |
What do these attacks look like in practice?
Three scenarios show how the risks combine. None requires an exotic attacker.
- The support inbox. A rep asks Claude to summarize new messages in a shared inbox and draft replies. One inbound email contains text, styled to be invisible, telling the assistant to look up the customer's account details in the CRM connector and include them in a reply to a different address. Controls that stop it: the send tool requires approval, the CRM connector is read-only for this role, and the rep is trained to check recipients before approving.
- The vendor spreadsheet. An analyst opens a template downloaded from a vendor portal and asks Claude for Excel to populate it. Anthropic warns that files from external sources can carry hidden instructions that try to make the add-in extract data, modify records or take destructive actions, and that its own testing found such scenarios. Controls: use trusted copies of workbooks, read confirmation prompts for risky operations carefully, and keep untrusted files away from workbooks with sensitive data.
- The cloned repository. A developer clones a public repository that includes a project MCP configuration pointing at an unknown server. Claude Code asks for approval before using project-scoped servers, and a cloned repository cannot approve its own servers in an untrusted folder. An organization that deploys an MCP allowlist through managed settings blocks the unknown server regardless of what the developer clicks.
Which controls does Claude give administrators?
Controls exist at four layers: the Claude organization, Claude Code, the servers you build, and your own processes. As of October 2026, these are the ones that matter most.
| Layer | Control | What it does | Plan or requirement |
|---|---|---|---|
| Claude organization | Owner-only connector addition | Members cannot add organization connectors; on Enterprise, custom roles with Manage access to Libraries can | Team and Enterprise |
| Claude organization | Per-role connector tool permissions | Set each connector, or each tool, to Always allow, Needs approval, Blocked or Custom | Enterprise custom roles |
| Claude organization | Managed authorization | Authorize a connector once through the identity provider; access follows IdP groups; deprovisioning removes it; can require IdP-only connection | Team and Enterprise; Okta at launch |
| Claude organization | Inference hooks | Your service inspects prompts, tool call responses and uploaded file text before Claude processes them and returns allow or deny | Enterprise |
| Claude organization | Compliance API | Pull activity, chat data and files into your security and compliance tools | Enterprise; Primary Owner enables |
| Claude Code | managed-mcp.json | Deploy a fixed server set; users cannot add others; an empty map disables MCP | Deployed to a system path via MDM or Group Policy |
| Claude Code | allowedMcpServers with allowManagedMcpServersOnly | Approved catalog matched by server URL or exact command; anything else is blocked | Managed settings source |
| Claude Code | deniedMcpServers | Blocks matching servers from any source; nothing overrides a deny | Any settings scope |
| Servers you build | Spec requirements | Validate inputs, enforce access controls, rate limit, sanitize outputs; never accept tokens not issued to the server | MCP specification |
| Servers you build | Separate read and write tools with accurate annotations | Read-only tools marked readOnlyHint, destructive tools marked destructiveHint so Claude prompts before them | Anthropic Directory review criteria |
What does the MCP specification require?
The MCP specification puts duties on both sides. On tools, it says there should always be a human in the loop with the ability to deny tool invocations, and that clients should prompt for confirmation on sensitive operations, show tool inputs to the user before calling the server to avoid malicious or accidental data exfiltration, validate tool results before passing them to the model, set timeouts and log tool usage for audit. Servers must validate all inputs, implement access controls, rate limit invocations and sanitize outputs.
The specification's security best practices page covers the attacks that matter to teams building or hosting servers: confused deputy attacks against proxy servers, token passthrough (explicitly forbidden), server-side request forgery during OAuth discovery, state handle hijacking, local server compromise and scope minimization. Its scope guidance is the most useful for buyers: start with a minimal scope set and ask for more only when a privileged operation is first attempted. Common mistakes it lists include publishing every possible scope, using wildcard or omnibus scopes, and bundling unrelated privileges to avoid future prompts. Ask any vendor whose server you are evaluating how it handles each of these.
Does listing in the Anthropic Directory mean a server is safe?
No, and Anthropic says so. Its Claude Code documentation states that Anthropic reviews connectors against its listing criteria before adding them to the Anthropic Directory but does not security-audit or manage any MCP server. The criteria still help. Reviewers reject servers that combine safe and unsafe HTTP methods in one catch-all tool, require read-only and destructive annotations, and reject tool descriptions that contain hidden or encoded instructions, try to override system instructions, or tell Claude to call tools the user did not request. Listings carry a Community or Verified label; Verified review includes a functional test of each tool. Treat a listing as a quality signal and do your own review on top.
How should you evaluate a third-party MCP server?
- Who builds and hosts it? Prefer the vendor of the underlying system. A server for a vendor's API hosted on an unrelated domain needs extra scrutiny.
- What tools does it expose? Get the full tool list with descriptions and check that read and write operations are separate tools.
- What scopes does it request at consent, and can you grant fewer?
- Does it use per-user authorization or a shared credential? If shared, what can that credential reach?
- How are changes to tools announced? You want a changelog or version notice, not silent edits.
- What does it log, and what conversation data does it collect beyond what the tool needs?
- Where is it hosted, and what are its data retention and breach notification terms?
- Who inside your company owns it, and when will its tools and scopes next be reviewed?
What is a sensible rollout order?
- Inventory first: every connector and MCP server in use, including ones developers added locally.
- Start with read-only tools on low-sensitivity systems, and add write tools one at a time with per-action approval.
- Keep connectors that read outside content, such as email and web, away from roles that also hold outbound tools, or require approval on the outbound side.
- Deploy Claude Code MCP allowlists before broad developer rollout, not after.
- Turn on logging you will actually review, through the Compliance API or Claude Code OpenTelemetry export, and assign someone to review it.
Questions people also ask
Can a malicious MCP server steal data from my other connectors?
It can try. A malicious server can return results or tool descriptions with hidden instructions that push the model to read data through another connector and send it somewhere. Anthropic advises connecting only to servers built and hosted by parties you trust and watching tool inputs and outputs. Requiring approval for outbound tools is the most reliable backstop.
Is a remote MCP server safer than a local one?
They carry different risks. A local server runs code on the user's machine with the user's privileges, so a malicious one can do anything that user can. A remote server cannot touch the machine but holds tokens to your systems. Control local servers with managed allowlists and remote ones with scopes, approvals and vendor review.
Should we build our own MCP servers instead of using third-party ones?
Build when no trusted vendor server exists, when you need to expose only a narrow set of operations, or when the system holds sensitive data. Building means owning the security duties in the MCP specification, including token validation and per-client consent for proxy servers. For mainstream SaaS tools, a vendor-hosted server is usually the better starting point.
How do we stop developers from adding unapproved MCP servers to Claude Code?
Deploy managed settings. A managed-mcp.json file gives exclusive control over the server set, while allowedMcpServers with allowManagedMcpServersOnly creates an approved catalog. Match by server URL or exact command, because Anthropic warns that matching by server name is not a security control.
Does Anthropic audit the connectors in its directory?
Anthropic reviews connectors against published listing criteria and may run functional tests for Verified listings, but states that it does not security-audit or manage any MCP server. Do your own review of tools, scopes and the vendor's security practices.
