Guide
MCP security
MCP security means controlling which Model Context Protocol servers your AI agents can reach, what each tool is allowed to do, and what comes back. In practice it takes four controls: an inventory of servers, per-tool authorization, inspection of requests and responses, and an audit trail tied to an identity.
Where MCP goes wrong
Most MCP incidents come from a short list of causes. Several are named in the MCP specification's security best practices; the rest come from how teams adopt servers in practice.
| Risk | What happens | Control |
|---|---|---|
| Servers nobody approved | Developers add MCP servers to their own client config. No one has a list of which servers, and which tools, agents can reach. | An inventory of the servers agents actually call, and an allowlist |
| Local server compromise | A local server runs with the same privileges as the client. A malicious startup command or package can run any command on the machine. | Show and approve the exact command; run local servers sandboxed |
| Over-broad scopes and tools | A token granted every scope up front, or a server that exposes delete tools next to read tools, widens what a single mistake or stolen token can do. | Least-privilege scopes and per-tool policy |
| Token passthrough | A server forwards a client's token to a downstream API without checking it was issued for that server. The spec forbids this; it breaks audit and rate limits. | Accept only tokens issued to the server; one identity per call |
| Untrusted tool output | Tool descriptions and results go straight into the model's context, so text inside them can steer what the agent does next. | Inspect requests and responses, not just which tool was called |
| No audit trail | Calls aren't recorded with who made them, the arguments and the decision, so an incident can't be reconstructed. | Log every call with identity, arguments and the policy decision |
Where to enforce MCP policy
No single place sees everything. Client settings stop a server from loading on one machine; a gateway applies one policy to every routed call; cluster policy covers servers that run as workloads. Use the layer that matches where the server runs.
| Layer | What it covers | Where it stops |
|---|---|---|
| MCP client settings | Which servers one developer's agent can load | Per machine; a developer can usually change their own settings |
| Gateway in front of MCP and LLM traffic | Every call that routes through it: identity, per-tool policy, request and response inspection, audit | Only sees traffic that is routed through it |
| Kubernetes cluster | MCP servers that run as workloads: network egress, service accounts, admission policy | Doesn't see servers running on laptops |
Guides in this series
Step-by-step guides for each control, tested against the tools they cover. New guides appear here as they're published.
Published guides
- How to restrict which MCP servers Claude Code can useOctober 24, 2026
- How to control MCP servers in GitHub CopilotOctober 25, 2026
- How to audit MCP tool callsOctober 26, 2026
- How to find MCP servers in your codebase and clustersOctober 27, 2026
Coming next
- How to allowlist MCP servers in Cursor
- What is MCP tool poisoning and how do you prevent it?
- MCP authorization: how to enforce per-tool policies
- MCP security checklist for enterprises
- Running MCP servers on Kubernetes securely
- MCP gateway vs policy enforcement: what's the difference?
- How to detect shadow AI: unapproved model APIs and local LLMs
- Prompt injection defense for agents: what actually works
Enforcing MCP policy with AIControls
AIControls runs as the gateway for LLM and MCP traffic, so one policy applies to every routed call.
- Finds the MCP servers nobody registered.
AIControls builds a live inventory of every server your agents actually talk to — not just the ones your team knows about.
- MCP governance
Per-tool and per-datasource policy, argument validation, discovery scoped to identity.
- Request & Response Scanning + PII Redaction
Requests are checked for identity and privacy before they go out. Responses are checked for cost, security, and policy before they come back.
- Every action traces back to an identity, replayable step by step.
Scope the kill switch to MCP, LLM, egress — or everything.
Frequently asked questions
What is an MCP server?
An MCP server is a program that exposes tools, resources and prompts to an AI client over the Model Context Protocol. A server can run locally next to the client, usually over the stdio transport, or remotely over HTTP. Each tool it exposes is something an agent can call, so every server you connect widens what the agent can do.
Is MCP secure by default?
The protocol defines how clients and servers authorize each other, and the MCP security best practices list attacks such as token passthrough, confused deputy and local server compromise. Which servers and tools your agents may use is not something the protocol decides. That policy has to be set and enforced by each organization.
Where should MCP policy be enforced?
In more than one place. Client settings control which servers a developer's agent loads. A gateway applies one policy to every call routed through it, with the caller's identity. Cluster policy covers MCP servers that run as Kubernetes workloads. A single layer leaves gaps the others close.
How do I find the MCP servers already in use?
Start with the client configuration files in repositories and on developer machines, then compare them with the servers your agents actually call. Traffic is the more reliable source, because local configs miss servers added by hand. Nirmata Scanners find MCP servers in code, and AIControls builds an inventory from live traffic.