MCP server security requires more than protecting an HTTP endpoint: you must verify identity, constrain tool authority, treat tool metadata and outputs as untrusted, and isolate every execution path. The practical baseline for 2026 is seven controls covering authorization, token handling, tool integrity, supply chain verification, runtime isolation, outbound requests, and audit telemetry.
The Model Context Protocol gives AI coding agents a standard way to call databases, APIs, filesystems, and developer tools. That standard also creates a trust boundary between the model, the MCP client, the server, the tool implementation, and the downstream service. If any one of those layers silently trusts the next, a malicious tool description, response, dependency, or authorization URL can become a path to data exposure or code execution.
This guide focuses on the controls a small engineering team can verify before connecting an MCP server to a coding agent. It follows the MCP security guidance and the OWASP MCP Top 10, with additional context from recent research on tool poisoning and runtime defenses.
What is MCP server security?
MCP server security is the set of identity, authorization, input validation, isolation, supply chain, and monitoring controls that prevent an MCP server from granting more access than intended. It applies to local stdio servers as well as remote HTTP servers, although the exact authentication and network risks differ.
The most important distinction is between the tool's advertised capability and the authority it should receive at runtime. A tool may be described as a read-only search helper while its implementation can reach a writable filesystem, a broad API token, or an unrestricted network. Security review must inspect the whole path from client request to tool process to downstream side effect.
MCP server security checklist at a glance
| Control | Threat reduced | Minimum verification |
|---|---|---|
| 1. Authenticate every request | Token confusion and unauthorized access | Validate issuer, signature, expiry, audience, and scope |
| 2. Protect OAuth consent flows | Confused deputy and redirect attacks | Use exact redirect matching, per-client consent, state, and PKCE |
| 3. Treat tools and outputs as untrusted | Tool poisoning and indirect prompt injection | Review metadata, validate responses, and gate high-impact calls |
| 4. Verify the server supply chain | Dependency tampering and rug pulls | Pin versions, review diffs, and record provenance |
| 5. Isolate tool execution | Command execution and privilege escalation | Use non-root processes, narrow mounts, limits, and egress rules |
| 6. Block SSRF and unsafe destinations | Internal network and cloud metadata access | Validate URLs and enforce a destination policy |
| 7. Log and rehearse response | Invisible misuse and slow containment | Record auth, tool calls, policy decisions, and revocation events |
1. Authenticate every MCP request and validate token audience
An MCP server should not treat possession of a bearer token as proof that the token is meant for that server. The official MCP security guidance explicitly forbids token passthrough and requires servers to reject tokens that were not issued for the MCP resource.
For every protected request, verify the token issuer, signature, expiration, audience, and granted scope. Bind the authorization decision to the authenticated principal and the requested tool. A valid token with the wrong audience is still the wrong credential for your server.
Do not forward a client token unchanged to a downstream API. Exchange or mint a credential for the downstream resource, or use a server-side credential with a narrowly defined scope. This preserves the audit trail and prevents a token accepted by one service from becoming a universal pass to another.
For local stdio servers, protect the process environment and its parent launcher. Do not place broad cloud credentials in a shared shell profile when the server only needs one read operation. Use a dedicated identity, short-lived credentials, and a separate process account wherever possible.
2. Protect OAuth consent and redirect flows
Remote MCP servers often rely on OAuth, which adds a second set of security decisions beyond ordinary API authentication. The MCP security best practices describe a confused deputy risk when a proxy uses a static third-party client ID, allows dynamic clients, and skips explicit per-client consent.
Before redirecting a user to a third-party authorization server, show which MCP client is requesting access, which scopes it wants, and where the authorization response will return. Store consent per user and per client. Do not infer consent from a generic cookie that only says the user has authenticated before.
Use exact redirect URI matching instead of wildcards. Generate a cryptographically secure, single-use state value for every authorization request, validate it on callback, and expire it quickly. Use PKCE for public clients and keep the code verifier unavailable to untrusted content.
Test the negative cases: a changed redirect URI, a missing state value, a reused authorization code, a token issued for another audience, and a client that has not received explicit consent should all fail closed. These checks belong in automated integration tests, not only in a security document.
3. Treat tool descriptions, arguments, and outputs as untrusted input
Tool poisoning occurs when an attacker changes tool metadata or tool responses so the model follows instructions that were never approved by the user or developer. The payload may be hidden in a description, an error string, a document returned by a tool, or a field that appears to be ordinary data.
Do not ask the model to decide whether a tool is safe based only on the tool's own description. Keep an approved registry containing the server identity, tool name, input schema, allowed side effects, and expected version. Compare the live definition with the approved record and stop when a high-risk field changes.
Validate arguments at the server boundary. Enforce type, length, path, URL, and allowed-value rules before invoking the implementation. Validate returned data as data, then present it to the model with clear provenance and delimiters. Never treat text inside a tool response as a new system instruction.
Require explicit confirmation for destructive or externally visible actions such as deleting records, writing to production, sending messages, publishing packages, or changing access controls. The confirmation should describe the actual normalized action and target, not merely repeat the tool name.
Recent MCP research has found that runtime interception can materially reduce tool poisoning and indirect injection success, but no filter is perfect. Pair content checks with least privilege, approval gates, and an isolated execution environment. The AI coding agent security checklist covers the broader permission and review boundary around this control.
4. Verify the MCP server and dependency supply chain
An MCP server is executable software, so its package and transitive dependencies belong in the same review process as application code. A trusted name or marketplace listing is not proof that the published artifact is safe.
Pin server and dependency versions in production. Review the lockfile, package provenance, release history, and permission requirements before installation. Generate an SBOM when the environment warrants it, scan dependencies for known vulnerabilities, and preserve checksums or attestations for the artifact that was reviewed.
Watch for rug pulls. A server can pass review and later change its tool definitions, network destinations, or dependency tree. Re-run the approval comparison after upgrades and before each deployment. Remove unused servers instead of leaving dormant credentials and listeners available.
Keep installation separate from execution. Build or install the server in a clean environment, inspect the resulting files, then run it with a minimal runtime identity. This limits the chance that an install script, package hook, or compromised cache can modify the trusted host around the MCP process. For related package risks in AI-assisted development, see the guide to preventing hallucinated dependencies.
5. Isolate tool execution and enforce least privilege
Assume that a compromised tool process will try to use every capability it can reach. Run it as a non-root user with a read-only filesystem wherever possible, narrow writable directories, CPU and memory limits, and no access to host sockets or developer credential stores.
Separate tools by authority. A read-only repository search tool should not share a process, token, or working directory with a deployment tool. If a tool must write files, give it a temporary workspace and copy approved results across a validation boundary. If it must access the network, use an explicit allowlist for destinations and ports.
For remote servers, isolate the service account and network segment from production systems. For local servers, inspect the exact command used to launch the process, including arguments and environment variables. A short executable name in an MCP configuration does not tell you what the process can actually read or execute.
Sandboxing reduces blast radius but does not replace review. An agent can still influence a trusted component through a file, hook, log, or generated configuration. The AI coding agent sandbox escape guide explains why those handoffs need their own controls.
6. Block SSRF and unsafe authorization destinations
MCP clients and proxy servers may fetch URLs supplied by a server during metadata discovery or authorization. If those URLs are not validated, a malicious server can attempt to reach internal services, cloud metadata endpoints, loopback listeners, or a local MCP proxy.
Parse and validate every URL before making a request. Decide whether the destination is allowed by scheme, hostname, resolved IP range, port, and redirect behavior. Block private and link-local ranges unless the workflow explicitly requires them. Re-check the destination after DNS resolution and after redirects, because a public hostname can resolve to a private address or change its answer.
Use TLS with certificate validation and avoid accepting arbitrary authorization endpoints from untrusted metadata. Keep the proxy process isolated from sensitive network segments, and log blocked destinations as security events. The official MCP guidance treats SSRF as a protocol-specific risk because the model integration can make a server-controlled URL look authoritative.
7. Build audit telemetry and an incident response path
Security controls are difficult to trust when you cannot reconstruct what happened. Record authentication attempts, token validation outcomes, consent decisions, tool definitions, normalized arguments, policy decisions, execution duration, destination hosts, and response sizes.
Keep secrets and unnecessary personal data out of logs, but preserve enough context to answer five questions: who invoked the tool, which client and server were involved, what capability was requested, what policy allowed or denied it, and what external side effect occurred.
Alert on changes to approved tool definitions, repeated authorization failures, unexpected destinations, unusual data volume, new child processes, and calls outside the normal task sequence. Send high-value events to an append-only or otherwise tamper-evident store.
Prepare a short response runbook. It should revoke the MCP server identity, rotate downstream credentials, disable the server, preserve logs and package hashes, identify affected tool calls, and restore from a known-good configuration. Test the runbook with a harmless compromised-server simulation at least once before connecting the server to sensitive data.
How should a small team review an MCP server before production?
Use this sequence for each new server or material upgrade:
- Record the server source, version, checksum, maintainer, tools, dependencies, and required permissions.
- Map every data flow from the agent to the MCP server and downstream APIs.
- Verify authentication, audience checks, scopes, redirect handling, and token non-passthrough.
- Compare tool definitions with an approved baseline and test argument validation.
- Run the server in an isolated account with minimal filesystem and network access.
- Exercise SSRF, prompt injection, tool poisoning, and destructive-action denial tests.
- Confirm that telemetry, credential revocation, rollback, and incident response work.
This process is intentionally repeatable. MCP specifications, clients, servers, and tool registries are evolving quickly, so a one-time approval should not become permanent trust.
Frequently asked questions about MCP server security
What is the biggest MCP security risk?
There is no single risk for every deployment, but tool poisoning, token mismanagement, excessive permissions, and command execution are common high-impact paths. The most dangerous combination is an untrusted tool with broad credentials and no approval or isolation boundary.
Should MCP servers accept OAuth tokens from clients?
They may accept tokens intended for the MCP server after validating issuer, signature, expiry, audience, and scope. They should not accept arbitrary tokens issued for another resource or pass a client token through to a downstream service without a separate trust decision.
How do you prevent MCP tool poisoning?
Keep an approved registry of tool definitions, detect changes, validate arguments and outputs, mark tool responses as untrusted data, and require confirmation for high-impact actions. Combine those controls with least privilege and runtime isolation because content filters alone can be bypassed.
Is a local stdio MCP server safer than a remote server?
Local stdio avoids some remote authentication and transport risks, but it can have direct access to the developer machine and its environment. Treat the launch command, filesystem, credentials, and child process as a local privilege boundary that still needs isolation and review.
How often should an MCP server be re-reviewed?
Re-review it whenever the server version, dependency lockfile, tool definition, authorization scope, launch command, or network destination changes. Also repeat the review after a client or protocol update that changes how tools, OAuth metadata, or responses are handled.
MCP makes agent integrations easier to build, but the integration layer is part of the security architecture. Start with narrow capabilities, verify every trust handoff, and make the safe path the path your tooling follows by default.
Sources: MCP Security Best Practices, MCP Authorization Specification, OWASP MCP Top 10, Microsoft MCP Security Controls, and ACL 2026 research on runtime MCP defenses.