Separate read-only, network, write, shell and administrative tools.
The biggest MCP risk is not merely an open port; it is unclear authority. Filesystem, shell, Git, email and database tools belong to different security classes.
Do not expose shell or file-write tools in production without a low-privilege service identity, allow-lists and an isolated working directory.
Before exposing an MCP server, define data class, permission level, user confirmation, network access and audit requirements per tool. The tool list is an API surface; “local” does not mean safe.
Before exposing an MCP server, define data class, permission level, user confirmation, network access and audit requirements per tool. The tool list is an API surface; “local” does not mean safe.
Threat-model shadow MCP servers, over-privileged tools, prompt injection, secret leakage, SSRF and remote-command risks with a production hardening checklist.
Separate read-only, network, write, shell and administrative tools.
Binding a development server to all interfaces can create unintended exposure without a firewall.
For shell tools, allow-listed commands and argument patterns are safer than a blacklist.
Correlate each tool call with user, client, tool name and a trace identifier.
Before tuning security controls, know which MCP server reaches which data and system. Shadow MCP is often an inventory problem.
| Tool type | Example | Default risk |
|---|---|---|
| Read-only information | Documentation search | Low-Medium |
| External network | URL fetch / webhook | Medium-High: SSRF |
| File write | Repository editing | High |
| Shell / exec | Command execution | Very high |
A tool that fetches user-supplied URLs can reach metadata endpoints and internal services, not just public websites.
The model usually does not need to see a secret. The server-side tool should use credentials and return only the result.
“Execute command” is one of the most powerful and abuse-prone MCP surfaces. Avoid passing free text directly to a shell.
| Control | Weak approach | Safer approach |
|---|---|---|
| Command selection | Free-form shell string | Predefined action IDs |
| File path | Any path accepted | Jailed working root |
| Privilege | root/admin | Dedicated low-privilege user |
| Confirmation | Every call automatic | User confirmation for destructive actions |
Before trusting an MCP client status, inspect listening ports, processes and reverse-proxy routes at the operating-system level.
ss -lntupsystemctl --faileddocker ps --format "table {{.Names}} {{.Ports}} {{.Status}}"journalctl -u mcp-server --since "30 min ago" --no-pagerIn an MCP incident, first cut authority and preserve evidence rather than swapping the model.
Reverse proxies, private networking, firewalls, low-privilege identities and centralized logging matter as much as the MCP server itself.
Primary documentation and technical references used by this guide.
Continue with related infrastructure and implementation guides.
MCP Server Security
A practical term for MCP servers or integrations operating outside the organization’s approved inventory and security governance.
It reduces exposure but is not sufficient by itself. Same-host processes, reverse proxies and local privilege scenarios still matter.
No single filter can guarantee this. Reduce impact with server-side authorization and parameter boundaries independent of model instructions.
No, but treat them as high risk in production. Prefer constrained actions and low-privilege identities over free-form shell access.