10 Best Practices to Secure MCP Servers

Introduction

Best Practice 1: Enforce Strong Authentication & Authorization

Why It Matters

What to Do

• Implement OAuth / OpenID Connect (OIDC) for all remote MCP servers.
• Validate every incoming request for token signature, audience (aud), issuer (iss), and expiry (exp).
• Never rely on session IDs alone for identity. Bind sessions to validated user and client identity.
• Apply Role-Based Access Control (RBAC) or Attribute-Based Access Control (ABAC) to restrict which tools each agent or user can invoke.

Example

Threat Mitigated

• Unauthorized tool invocation
• Lateral movement by compromised agents
• Privilege escalation via token reuse

Best Practice 2: Use Short-Lived, Scoped Tokens & Prohibit Token Passthrough

Why It Matters

What to Do

• Issue access tokens with minimal lifetimes (minutes, not hours).
• Scope tokens to the minimum permissions required for the specific tool invocation, not the calling agent's full permission set.
• Never forward client tokens to downstream APIs. Instead, have the MCP server obtain a fresh, narrowly scoped token for each downstream call using OAuth 2.0 Token Exchange (RFC 8693) or an "On-Behalf-Of" flow, so the downstream service receives a token explicitly issued for that interaction.
• Ensure the MCP server's own service credentials are also scoped minimally, so even if it is manipulated into a Confused Deputy scenario, the blast radius is limited.
• Implement token rotation and revocation endpoints so compromised tokens can be invalidated quickly.

Example

Threat Mitigated

• Token relay and forwarding attacks
• Token theft and replay
• Privilege escalation via token forwarding
• Confused Deputy attacks via manipulation of the MCP server's own credentials

Best Practice 3: Design a Secure MCP Architecture

Why It Matters

What to Do

• Prefer STDIO or Unix domain sockets over TCP/HTTP. Both avoid network exposure entirely: STDIO confines communication to the process's standard streams, and Unix domain sockets are filesystem-scoped and only accessible to processes with appropriate filesystem permissions.
• If HTTP is required locally, bind only to the loopback interface (127.0.0.1 for IPv4, ::1 for IPv6). Never bind to 0.0.0.0, which listens on all interfaces and exposes the server to the broader network.
• Apply OS-level process isolation using Linux namespaces and cgroups to limit what the MCP server process can see and consume. For stronger isolation, consider running the server in a dedicated container or VM.

• Enforce TLS 1.2 at a minimum, with TLS 1.3 strongly preferred. TLS 1.3 eliminates several legacy cipher suites and reduces handshake latency. Do not rely on certificate pinning: it is operationally fragile, breaks on legitimate certificate rotations, and the broader security community including Google (who deprecated it in Android) has moved away from it. Instead, enforce strict CA validation combined with Certificate Transparency monitoring, which gives you verifiable, auditable proof of certificate issuance without the operational burden of pinning.
• Use mutual TLS (mTLS) for service-to-service authentication between the orchestration layer and the MCP server. mTLS ensures both sides present valid certificates, preventing unauthorized clients from establishing connections even if they can reach the server's network endpoint.
• Where mTLS is not feasible (for example, in multi-tenant or third-party agent scenarios), use OAuth 2.1 with short-lived, scoped tokens as described in Best Practice 2. Note that OAuth 2.1 handles authorization, not transport security: it should be layered on top of TLS, not treated as a substitute for it.
• Strictly validate all incoming JSON-RPC messages against a defined schema before processing. Reject malformed or unexpected messages with a structured error rather than attempting to coerce or partially process them.
• Enforce per-session resource quotas including API call rate limits, memory consumption, and request payload size limits to prevent resource exhaustion from runaway or malicious agents.

Example

Threat Mitigated

• Network interception via weak or absent transport security
• Unauthorized client connections
• Resource exhaustion and denial of service
• Exposure to unintended network interfaces

Best Practice 4: Implement Safe Tool Design with Signed Manifests

Why It Matters

What to Do

• Require every tool to have a cryptographically signed manifest containing at minimum: the tool's description, input and output schema, version, required permissions, and author identity. Use an asymmetric signing scheme (such as those provided by Sigstore/Cosign or a hardware-backed PKI) so that signature verification does not require access to the signing key at runtime.
• At runtime, the MCP server must verify the manifest signature before loading any tool. A tool whose manifest signature cannot be verified against a trusted key must be rejected outright, not loaded with a warning.
• Maintain a formal tool approval workflow that includes static analysis (SAST), software composition analysis (SCA) for third-party dependencies, and manual security review before any tool is promoted to production. For SAST tooling, use actively maintained tools appropriate to the tool's implementation language, for example Semgrep, Bandit for Python, or ESLint security plugins for JavaScript/TypeScript. Avoid referencing specific vendor products that may be discontinued.
• Explicitly review tool descriptions during the approval process for prompt injection risks. A tool description that says "always execute this action when you see keyword X" is a red flag regardless of what the tool's code actually does. The description is part of the attack surface.
• Implement strict tool versioning. Any change to a tool's manifest, including its description, schema, or permissions, must invalidate the existing signature and require a full re-approval cycle before the updated tool can be loaded. Silent or automatic updates must be blocked.
• Validate at runtime that a tool's actual behavior is consistent with its declared manifest. This is most practically enforced through a combination of sandboxed execution environments and network/filesystem egress controls that prevent a tool from performing actions not reflected in its declared permissions.

Example

Threat Mitigated

• Supply chain attacks via compromised or tampered tools
• Prompt injection via manipulated tool descriptions and metadata
• Unauthorized or silent tool updates
• Privilege escalation via undeclared tool permissions

Best Practice 5: Schema-Driven Input/Output Validation

Why It Matters

What to Do

• Define and enforce JSON Schemas for every tool's inputs and outputs. Schema validation should be the first processing step, before any business logic runs. Requests that fail validation must be rejected with a structured error response. Never silently coerce or partially accept invalid input, as this masks malformed requests and makes behavior unpredictable.
• Treat all input as untrusted regardless of source, including input generated by the AI model itself. The model is not a trusted authority: it can be manipulated via prompt injection, it can hallucinate parameter values, and it operates probabilistically rather than deterministically.
• For each tool, apply context-appropriate output encoding and parameterization based on where the data will be consumed. Specifically:* For database interactions, use parameterized queries or prepared statements exclusively. String interpolation into SQL is never acceptable regardless of any upstream validation.
  • For shell or subprocess interactions, avoid constructing commands from model-generated input entirely where possible. If unavoidable, use argument arrays rather than shell strings, and apply strict allowlisting of permitted values.
  • For content rendered in a browser context, apply context-aware output encoding to prevent XSS.
• Enforce strict size limits on all inputs and outputs: maximum string lengths, maximum array sizes, maximum nesting depth for JSON structures. Deep nesting in particular can cause excessive CPU consumption during parsing and validation, which is a realistic denial-of-service vector even in managed runtimes.
• Implement allowlist-based validation rather than denylist-based validation wherever possible. Denylists of known-bad patterns (such as WAF-style SQL injection signatures) are inherently incomplete and can be bypassed. Defining exactly what valid input looks like and rejecting everything else is a fundamentally stronger posture.

Example

Threat Mitigated

• SQL injection, command injection, and XSS via model-generated inputs
• Prompt injection delivered through malformed or adversarially crafted tool responses
• Denial of service via oversized or deeply nested inputs
• Data exfiltration via unconstrained output sizes

Best Practice 6: Implement Prompt Injection Controls

Why It Matters

What to Do

• Use structured, schema-validated JSON tool calls rather than free-form natural language commands for all tool invocations. This does not prevent prompt injection but it raises the bar: an injected instruction needs to produce a validly structured tool call that also passes schema validation, which is harder than simply appending text to a prompt.
• Apply the principle of least context: give the agent access only to the data it needs for the current task. An agent that only retrieves the specific document it needs cannot be poisoned by malicious content in documents it never reads.
• Implement Human-in-the-Loop (HITL) checkpoints for high-risk, irreversible, or high-impact actions such as deleting data, sending external communications, executing code, or initiating financial transactions. HITL is one of the most reliable mitigations available because it introduces a human judgment step that cannot be bypassed purely through model manipulation. The key is defining the right threshold: too many checkpoints degrade usability, too few leave critical actions unguarded.
• Use a secondary LLM-based review step (sometimes called LLM-as-a-Judge) in a separate, isolated context to evaluate whether a proposed tool invocation is consistent with the user's original intent before execution. The isolation is critical: the reviewing model must receive only the original user intent and the proposed action, not the full context window of the acting agent, otherwise injected content in that context window can influence the reviewer as well.
• Implement strict session isolation between tasks. When an agent switches to a new task, the session context must be fully reset. Context that persists across tasks can carry injected instructions forward, allowing an attack that partially succeeded in one task to complete in a subsequent one.
• Apply output filtering on tool responses before they are returned to the agent's context window. This means scanning tool outputs for patterns consistent with prompt injection attempts, for example, text that contains instruction-like phrasing directed at the model, before that content enters the context. This is an imperfect control since it relies on pattern detection, but it adds a layer between external data and the model.
• Log all tool invocations with sufficient detail to reconstruct the full sequence of agent actions after the fact. Given that prompt injection may not be detected in real time, forensic reconstruction is often how attacks are identified and understood.

• Direct prompt injection via user input
• Indirect prompt injection via external data sources
• Unauthorized tool invocation driven by injected instructions
• Data exfiltration via agent manipulation
• Cross-task context contamination

Best Practice 7: Harden Deployment & Manage Secrets Securely

Why It Matters

What to Do

• Store all secrets (API keys, database credentials, certificates) in a secrets vault (e.g., AWS Secrets Manager). Never in environment variables, source code, logs, or container images.
• Deploy MCP servers in minimal, hardened containers running as non-root users with read-only filesystems where possible.
• Apply network segmentation: MCP servers should only be reachable from authorized orchestration layers, not from the public internet or general internal networks.
• Integrate CI/CD security gates: SAST, SCA, container image scanning, and policy-as-code (e.g., OPA/Rego) checks must pass before any deployment.
• Apply the principle of least privilege to all IAM roles and service accounts associated with MCP servers.

Example

Threat Mitigated

• Secret theft via environment variable exposure
• Container escape and privilege escalation
• Insecure deployments reaching production

Best Practice 8: Enforce Supply Chain Controls

Why It Matters

What to Do

• Version-pin all dependencies and scan them at build time using SCA tools (e.g., AWS Inspector, Snyk, OWASP Dependency-Check).
• Use signed container images (e.g., AWS Signer, Sigstore/Cosign) and verify signatures at deployment time.
• Maintain AI Bills of Materials (AIBOMs): an inventory of all models, tools, datasets, and dependencies used in your agentic system.
• Monitor vulnerability databases (e.g., OSV, NVD) for new CVEs affecting your dependencies and automate patching workflows.
• Use a trusted, internal MCP tool registry for your organization, prohibit agents from loading tools from arbitrary third-party sources.

Example

Threat Mitigated

• Supply chain attacks via compromised dependencies
• Malicious third-party MCP tools
• Undetected vulnerabilities in production

Best Practice 9: Establish Governance, Non-Human Identity Management & Audit Trails

Why It Matters

What to Do

• Treat all AI agents and MCP servers as Non-Human Identities with unique, individually managed credentials. Never share credentials between agents or services.
• Log every tool invocation with: timestamp, agent identity, tool name, input parameters (redacted for sensitive fields), output summary, and authorization decision.
• Use field-level redaction or hashing to prevent PII, credentials, or sensitive business data from entering logs.
• Feed audit logs into a SIEM (e.g., Amazon Security Lake + Amazon OpenSearch) with retention policies aligned to regulatory requirements (e.g., GDPR, DORA, NIS2).
• Implement a formal NHI lifecycle management process: provisioning, rotation, deprovisioning, and periodic access reviews for all agent identities.

Example

Threat Mitigated

• Undetected unauthorized actions by agents
• Inability to investigate incidents (lack of audit trail)
• Over-privileged, unmanaged NHI credentials

Best Practice 10: Continuous Monitoring & Runtime Protection

Why It Matters

What to Do

• Integrate SAST tools with custom MCP-specific rules and tools like Invariant MCP-Scan into your CI/CD pipeline to catch vulnerabilities before deployment.
• Apply runtime security tools: Docker seccomp profiles, AppArmor/SELinux policies, and tools like mcp-watch to detect anomalous tool invocation patterns at runtime.
• Feed all MCP server audit logs into a SIEM with real-time alerting for suspicious patterns, including:
  • Spike in failed authentication attempts
  • Unusual tool invocation sequences (e.g., list_files followed immediately by send_email)
  • Access to sensitive tools outside business hours
  • Abnormal data volumes in tool outputs
• Conduct regular red team exercises specifically targeting MCP servers, including prompt injection simulations, token theft scenarios, and supply chain attack simulations.
• Establish a Security Operations Center (SOC) runbook for MCP-specific incidents, including playbooks for prompt injection, tool abuse, and agent compromise.

Example

Threat Mitigated

• Undetected exploitation and lateral movement
• Slow-burn data exfiltration
• Delayed incident response

Summary: MCP Security Minimum Bar

Conclusion