4 minutes
How to secure MCP servers
Linda Vu Nguyen
Securing an MCP server requires layered controls across authentication, input handling, execution isolation, transport, secrets management, tool classification, and runtime enforcement. No single control is sufficient. The checklist below covers each layer, followed by how to scan before you connect and enforce at the app runtime.
Part of the MCP Security cluster. See also: MCP security best practices and how to detect shadow MCP servers.
Why MCP servers need explicit security controls
MCP servers sit at the boundary between agent intent and system action. They receive tool call requests from agents, translate those requests into operations against real infrastructure, data stores, and external services, and return results that influence subsequent agent decisions. That boundary position makes them a concentrated risk surface.
From a corpus of 12,000+ MCP servers scanned through the MCP Trust Registry (as of June 2026, N=12,000+):
6% have critical vulnerabilities
33% have unbounded URI / SSRF vulnerabilities
42% have command injection flaws
20,000+ new MCP servers publish monthly, faster than security review can keep up
These are not edge cases. They represent common implementation patterns that appear repeatedly across the corpus.
Security checklist: layered controls
Work through each layer in order. Each builds on the one before.
Control 1: Authentication and authorization
Every tool call must be authenticated. MCP servers that accept unauthenticated requests expose full tool capability to any client that can reach the server.
Require authentication on every inbound tool call request; no anonymous endpoints.
Implement per-tool authorization: a caller authorized to invoke a read tool is not automatically authorized to invoke a write or destructive tool.
Validate caller identity against a known identity provider, not just a shared secret.
Rotate credentials on a defined schedule; treat long-lived static tokens as a critical finding.
Authentication gaps are among the most common findings in the scanned corpus. A server that accepts unauthenticated requests grants full tool access to any agent, or any adversary, that can reach it.
Control 2: Least-privilege tool scopes
Classify every tool by its scope before deployment, then grant callers only the scope they need.
Class | Description | Examples |
|---|---|---|
read | Returns data, no side effects | List files, query records, fetch status |
write | Creates or modifies state | Insert record, update config, post message |
destructive | Irreversible deletion or overwrite | Drop table, delete file, purge queue |
admin | Elevates privilege or changes access controls | Grant role, modify permissions, add user |
iam | Identity and access management operations | Create credential, rotate key, assign policy |
cost-impact | Triggers billable or resource-intensive actions | Provision instance, trigger large batch job |
Assign every tool a class at build time. Enforce those classes at the authorization layer: an agent with read scope cannot invoke a write tool. Human approval gates are appropriate for destructive, admin, iam, and cost-impact tools in production (see Control 7). This classification model maps directly to the taxonomy BlueRock uses for classification-aware governance; see the MCP Trust Registry for how it surfaces in scan results.
Control 3: Input validation
Every parameter arriving in a tool call is untrusted input.
Validate type, format, and length for every parameter before passing it downstream.
Reject or sanitize parameters before constructing SQL, shell commands, or filesystem paths.
Enforce strict allowlists on URI and URL parameters; open-ended URI acceptance is the direct cause of the 33% SSRF finding above.
Do not trust parameter values even when the calling agent is authenticated; agents can themselves be prompt-injected into passing unexpected input.
Common failure patterns from the corpus: unrestricted network fetch (URL passed directly to an HTTP client with no allowlist), command injection (shell command built by string interpolation of tool parameters), and path traversal (filesystem path built from parameters without normalization). The MCP Trust Registry applies 22 rules mapped to OWASP MCP Top 10, MAESTRO, and MITRE CWE to surface these down to the line of code.
Control 4: Sandboxed execution
Agents running untrusted or partially trusted MCP servers can trigger execution paths that escape the intended boundary. Isolate execution at the process and network level.
Run MCP servers in isolated execution environments with explicit process, filesystem, and network boundaries.
Restrict outbound network access to a defined allowlist (deny by default).
Prevent filesystem access outside a defined working directory.
Capture and inspect MCP and A2A protocol traffic during development.
BlueRock's Next-Gen Sandbox deploys in under 5 minutes via CloudFormation with zero application code changes and provides full Agentic Action Path visibility during development. In controlled testing it contained poisoned tools during MCP server initialization and prevented an agent from independently adapting exploit techniques. For evaluation criteria when connecting agents to a new server, see how to choose the right MCP server.
Control 5: Transport security and TLS
MCP tool calls carry tool parameters, authentication tokens, and often the return values of data queries. Encrypt all of it in transit.
Enforce TLS 1.2 minimum on all MCP server endpoints; prefer TLS 1.3.
Validate server certificates; do not accept self-signed certificates in production.
Reject plaintext connections rather than downgrading silently.
For private or internal deployments, treat transport configuration as part of the security posture review.
Transport layer security gaps appear consistently across the corpus and are one of the 22 categories BlueRock's rules evaluate in private repo scanning.
Control 6: Secrets hygiene
MCP servers often need credentials to reach downstream systems. How those secrets are managed determines whether a server compromise also becomes a credential compromise.
Never hardcode secrets in source code or configuration committed to version control.
Use a secrets manager (AWS Secrets Manager, HashiCorp Vault, or equivalent) and retrieve secrets at runtime.
Scope secrets to the minimum access the specific tool needs.
Audit rotation frequency; static long-lived credentials in MCP servers are a supply-chain risk.
Dependency and supply chain risk, including secrets in dependencies and build artifacts, is one of the vulnerability categories the MCP Trust Registry evaluates.
Control 7: Human-approval gates for write, destructive, and admin tools
Not all tool calls should execute immediately. Tools with write, destructive, admin, iam, or cost-impact classifications should pause for human review before execution in production, especially during early deployment.
Implement an approval workflow for tool classes above read.
Define explicit timeout and fallback behavior if no approval arrives.
Log every approval decision alongside the tool call that triggered it; this is the audit trail.
For destructive and admin tools, require explicit human confirmation even in automated pipelines unless the approval pattern is well established.
Human approval gates are a runtime control, enforced at the point of execution. See Guardrails for how pre-execution enforcement works at the app runtime.
Control 8: Monitoring and runtime observability
Controls 1 through 7 reduce attack surface. Control 8 tells you when something still slips through, and gives you the context to understand it.
Log every tool call with caller identity, tool name, sanitized parameters, timestamp, and outcome.
Connect tool call logs to a trace that spans the full agent action path: model decision through MCP invocation through data access through execution outcome.
Alert on anomalous patterns: unexpected tool-class escalation, unusual call frequency, parameters outside normal bounds.
Maintain a durable agent identifier across the full execution chain so you can correlate a sequence of tool calls to the agent session that generated them.
Without a durable identifier, log correlation is manual and unreliable: gateway logs here, application logs there, MCP server logs somewhere else, and no way to reconstruct what the agent actually did. See how to detect shadow MCP servers for the monitoring patterns that surface unauthorized MCP deployments.
Quick-reference checklist
Control | What to implement | Priority |
|---|---|---|
Authentication | Require auth on every tool call; no anonymous endpoints | Critical |
Authorization | Per-tool scope enforcement; deny by default | Critical |
Input validation | Validate all params; allowlist URIs; reject before constructing commands | Critical |
Tool classification | Classify every tool as read/write/destructive/admin/iam/cost-impact | High |
Sandboxed execution | Process, filesystem, network isolation; protocol inspection | High |
Transport / TLS | TLS 1.2+ enforced; no plaintext; validate certs | High |
Secrets hygiene | Secrets manager; no hardcoded credentials; scoped access | High |
Human-approval gates | Required for write, destructive, admin, iam, cost-impact classes | High |
Runtime monitoring | Full tool call logging; durable agent identifier; anomaly alerting | High |
How BlueRock helps
Scan before you connect: MCP Trust Registry. Before connecting an MCP server to an agent in production, run it through the MCP Trust Registry. It applies 22 security rules mapped to OWASP MCP Top 10, MAESTRO, and MITRE CWE and surfaces findings at the code level, not just a pass/fail score: authentication gaps, command injection, SSRF / unrestricted network fetch, dependency and supply chain risk, transport layer security, and path traversal. For internal servers, private repo scanning applies the same rule set against your repository. The data above (6% critical, 33% SSRF, 42% command injection) comes from this corpus, 12,000+ servers as of June 2026.
Enforce at the app runtime: Guardrails. Scanning tells you what a server looks like before deployment. Guardrails enforce at the point of execution in production: blocking privilege escalation via expansive tool arguments, preventing SSRF at the MCP layer, and enforcing tool classification policies in real time, with under 5ms latency overhead and no application code changes. For the full Agentic Action Path that gateways miss, see technical limitations of MCP gateways.
For the broader picture, start at the MCP Security pillar.
FAQ
What are the most critical security controls for MCP servers?
The three highest-priority controls are authentication (require auth on every tool call, no anonymous endpoints), input validation (treat every parameter as untrusted; allowlist URIs to prevent SSRF), and least-privilege tool scopes (classify tools as read, write, destructive, admin, iam, or cost-impact, then enforce at the authorization layer). These address the most common vulnerability classes found across 12,000+ MCP servers scanned by the MCP Trust Registry: 33% had SSRF vulnerabilities and 42% had command injection flaws.
What is MCP tool classification and why does it matter for security?
Tool classification assigns every MCP tool a scope (read, write, destructive, admin, iam, or cost-impact) based on what it actually does. It lets you enforce least-privilege at the authorization layer: a caller with read scope cannot invoke a write or destructive tool. It also drives human-approval gates, where tools in write, destructive, admin, iam, and cost-impact classes pause for explicit human review before executing in production. BlueRock's MCP Trust Registry surfaces tool classifications as part of its scan results, enabling classification-aware governance.
How do I scan an MCP server for vulnerabilities before connecting it to an agent?
Use the MCP Trust Registry at mcp-trust.com. It applies 22 security rules mapped to OWASP MCP Top 10, MAESTRO, and MITRE CWE to publicly listed MCP servers and surfaces findings at the code level. For internal or enterprise servers not listed publicly, private repo scanning applies the same rule set directly against your repository. The scan evaluates authentication gaps, command injection, SSRF / unrestricted network fetch, dependency and supply chain risk, transport layer security, and path-traversal vectors.
What runtime controls does BlueRock Guardrails apply to MCP server traffic?
BlueRock Guardrails enforce controls at the point of execution at the app runtime, with under 5ms latency overhead and no application code changes. They block privilege escalation via expansive tool arguments, prevent SSRF attacks at the MCP layer, and enforce tool classification policies in real time. Guardrails work alongside the MCP Trust Registry: the registry scans before you connect, Guardrails enforce after deployment. Both are powered by the Trust Context Engine.
What is SSRF in the context of MCP servers, and how do I prevent it?
Server-Side Request Forgery (SSRF) occurs when an MCP server accepts a URL or URI parameter and passes it to an HTTP client without validating the target. An agent, or a prompt-injected agent, can supply a malicious URI that causes the server to make requests to internal infrastructure, metadata endpoints, or other restricted targets. The MCP Trust Registry found 33% of scanned MCP servers have unbounded URI / SSRF vulnerabilities. Prevention: enforce a strict allowlist on all URL and URI parameters, and reject private-range IPs before passing the value to an HTTP client.
