The Model Context Protocol (MCP), introduced by Anthropic in November 2024 then opened and broadly adopted in 2025-2026, became in a few months the de-facto standard for exposing tools to an LLM. Claude, Cursor and most 2026 agents support it. Ergonomically a win. Security-wise, a new vector to audit — and most teams underestimate it.
An MCP server is foreign code that talks to your LLM, exposes functions to it, and receives its calls. It deserves the same scrutiny as an OAuth connector or third-party integration.
What an MCP server does
An MCP server exposes:
- A list of tools (functions the agent can call).
- A list of resources (data the agent can read).
- A list of prompts (templates the agent can use).
When the agent uses a tool, it calls the MCP server, which runs the code and returns a result. The result is integrated into the agent's context and used for the rest of the conversation.
That integration is precisely what creates the attack surface.
The 6 risks to examine per MCP server
1. Code origin
- Is it an official server maintained by the SaaS vendor it accesses?
- Or a community wrapper maintained by a third-party developer?
Community wrappers are the majority today. Many are excellent. Many aren't.
2. Data sent
When the agent calls an MCP tool, the relevant conversation can be sent to the server. Checks:
- Do tool parameters include sensitive data (PII, secrets, internal prompts)?
- Where does the server live — localhost, a third-party service, a cloud endpoint?
- What's the log retention server-side?
Worst case: a community MCP wrapper on a single developer's VPS, logging everything plaintext.
3. Output consumed as context
Every MCP server output becomes prompt content for the agent. A compromised server can inject prompts into every agent using it.
4. Authentication
- Static token in config: if exfiltrated, permanent access.
- OAuth flow: better, requires correct server implementation.
- No auth (local dev server): fine in dev, off the table in prod.
5. Operation permissions
A server exposing delete_file or send_email should require user confirmation on the agent side. Today it's up to the MCP client. Claude Desktop has confirmation prompts. Many custom wrappers don't.
6. Source code and dependencies
- Open source? You can audit it.
- If not, what does it claim vs what it does?
- For its own dependencies: same questions as any package — see supply chain attacks on npm/PyPI.
The 30-minute audit checklist per server
Before connecting a server to a production agent:
`` [ ] Origin documented (official or wrapper, who maintains) [ ] Server location (local / SaaS / VPS) [ ] Data sent documented [ ] Data returned documented [ ] Authentication mechanism reviewed [ ] List of exposed tools; for each: - Action performed - Data accessed - Reversibility - Confirmation required or not [ ] Source code review if available [ ] Dependency audit (npm/pypi) [ ] Quick-disable plan (kill-switch on agent side) ``
Special case: MCP servers that execute arbitrary code
Several popular MCP servers in 2026 expose execute_command or equivalent. Powerful, also an open door. If you allow it:
- Always in an isolated sandbox.
- No access to credentials.
- Exhaustive logging.
- Ideally human confirmation per command.
In most B2B contexts, the right default is not enabling those servers.
Emerging topic: enterprise MCP governance
The first 2026 teams industrializing MCP usage put in place:
- An internal registry of approved servers.
- An MCP proxy through which all calls pass (logging, validation, centralized rate limiting).
- A policy on what an employee can connect autonomously.
Same pattern as early enterprise SaaS approvals around 2010-2015. Anticipate it if you want to avoid shadow MCP.