MCP Server Security Checklist (2026)

What You'll Learn

• How MCP servers turn model-selected tool arguments into calls that can touch data, files, networks, and processes.
• Which controls address command injection, path traversal, SSRF, token misuse, prompt injection, and tool poisoning.
• How to separate authentication, authorization, input validation, network policy, sandboxing, and human approval.
• How to test, log, review, and release an MCP server without treating a passing demo as a security result.

What MCP Server Security Actually Covers

MCP Server Security Checklist 2026 is not a single library setting. It is a review of the boundary between an LLM host, an MCP client, an MCP server, the tool handler, and the systems that handler can reach. MCP standardizes how tools are described and called. It does not decide whether a tool may read a private file, reach an internal service, run a process, or mutate a production record.

An MCP server can expose a typed interface while the implementation still accepts a dangerous path, URL, shell fragment, or identifier. The client may see a friendly description. The backend sees a string that reaches a file API, a network client, a database call, or a process launcher. That difference is the security problem. A safe review follows every externally influenced value from the tool schema to its final sink.

The protocol documentation says servers must validate tool inputs, implement access controls, rate-limit invocations, and sanitize tool outputs. It also recommends that clients show tool inputs, validate results, use timeouts, and log usage. The official MCP tools specification is the baseline for those controls. Treat its tool annotations as untrusted unless they come from a trusted server.

This is why an MCP review should cover both code and deployment. A handler can validate a parameter correctly and still be exposed through an unauthenticated HTTP transport. A client can require approval for a tool while the server accepts a token issued for another resource. Security belongs at every boundary, not only inside the function that performs the final action.

Why MCP Changes the Threat Model

Traditional APIs usually receive an HTTP request whose route and parameters are selected by application code. In an agent workflow, a user or external document can influence the model, and the model can select a tool and construct arguments. This adds a semantic step between the attacker-controlled text and the backend operation. The extra step does not make the value safe. It can make the path harder to see during ordinary code review.

The VIPER-MCP paper, published on arXiv on May 20, 2026, studied this problem through static taint analysis and agent-mediated testing. It reports a scan of 39,884 real-world open-source MCP server repositories, 106 0-day vulnerabilities confirmed through end-to-end exploit traces, and 67 CVE IDs assigned at the time of the paper. Those are research findings from a defined sample. They are not a claim that every MCP repository contains a vulnerability.

Its useful lesson is methodological. A security assessment should ask whether attacker-controlled natural language can cause the agent to select a vulnerable tool, preserve control over a relevant argument, and carry that argument into a dangerous sink. The VIPER-MCP research paper separates static code findings from demonstrated agent-triggered behavior, which is a better model for testing than a checklist that only counts exposed functions. For a broader look at AI tooling, see the site's Technology archive.

The related OWASP agentic AI security guide is useful for connecting MCP-specific controls to broader risks such as excessive agency, prompt injection, and sensitive-data exposure. Keep the distinction clear. A taxonomy helps prioritize tests. It does not replace an inspection of the actual server and its runtime permissions.

The Two Attack Paths This Checklist Must Separate

Start by separating a tool-handler flaw from a transport or deployment flaw. A handler flaw occurs when a tool argument reaches a dangerous operation without a boundary check. Examples include a download path that can point outside an approved directory, a URL that can target an internal service, or a string interpolated into a shell command.

A transport flaw can be just as serious even when every tool function looks reasonable. An HTTP endpoint with no authentication may expose the server’s own downstream credentials to anyone who can reach the port. A proxy may accept a token intended for another resource. An authorization flow may trust a redirect target without exact matching. Those issues live in middleware, identity configuration, or network placement.

Do not test only the happy path. Build two maps. The first shows every tool argument and the sink it can reach. The second shows every identity, token, scope, network route, process, secret, and storage location that surrounds the server. The release decision should fail if either map contains an unreviewed path to a high-impact operation.

Tool Input and Output Validation

Validate the meaning of an argument, not only its data type. JSON Schema can require a string, but it cannot by itself prove that a string is an approved repository, a safe URL, a permitted file, or a record the caller may change. After schema validation, apply operation-specific checks in code. Reject unexpected fields where possible, cap sizes, normalize safely, and keep a clear allowlist of accepted values.

Path validation needs a real directory boundary. Resolve the candidate path with a trusted library, compare the resolved result with the approved root, and reject traversal, alternate encodings, symbolic-link escapes, and unexpected absolute paths. Do not rely on a description such as “save inside downloads” when the implementation accepts any path. The GitHub advisory for CVE-2026-27825 documents an MCP Atlassian case where an unconstrained download path enabled arbitrary file writes and code execution. The affected and patched release boundary in that advisory is below and at version 0.17.0.

Output handling needs the same care. Tool results can contain instructions, links, file content, credentials, or data from a compromised source. Mark external content clearly and avoid allowing tool output to silently become a new system instruction. Validate structured results before returning them to the model. Redact secrets and personal data from errors, logs, and diagnostic messages.

Validation failures should be boring and observable. Return a safe error, include a correlation identifier in the audit trail, and avoid echoing the rejected secret or payload. A security test should cover malformed types, oversized values, traversal forms, encoded separators, redirects, duplicate fields, and values that are valid for one tenant but not another.

Authentication and Authorization

Authentication answers who is calling. Authorization answers what that caller may do. An MCP server that protects user data, administrative actions, or paid APIs should make both decisions at the server boundary. Do not treat the model’s selection of a tool as authorization. Do not treat the possession of a state handle as authorization. Do not let a client-side approval screen be the only control.

The official MCP authorization guidance describes OAuth 2.1 authorization code with PKCE for HTTP-based remote servers, along with protected-resource metadata, authorization-server discovery, client registration, consent, and bearer-token validation. The exact flow will depend on the deployment, but the core rule is stable: validate the received token and then enforce the permissions required by the requested operation.

For a proxy that connects to a third-party API, record consent per client and per user before forwarding the authorization flow. Match redirect URIs exactly. Protect state values against cross-site request forgery and make them short-lived and single-use. Show the requesting client, requested scopes, and registered redirect target on the consent screen. A generic “allow access” button hides too much of the decision.

Local stdio servers need a different control set from remote HTTP servers, but they still need boundaries. Review how the host launches the process, which operating-system user owns it, which environment variables it receives, and whether another local process can reach it. If a proxy spawns local servers, use process isolation and require additional approval for commands that can alter the host.

Token Audience, Scope, and Secret Handling

Token passthrough is a specific anti-pattern. An MCP server must not accept a token merely because another service issued it or because it can be forwarded to a downstream API. The server should verify that the token was issued for the MCP resource, is active, has the required scope, and belongs to the expected issuer. The audience check protects the trust boundary between the client, MCP server, and downstream service.

Scope design should follow the operation. Read-only discovery, data retrieval, and mutation should not share one broad permission when separate scopes are possible. A stolen token with broad access can turn a small disclosure into a wider incident. Review scope changes as code changes. Record which scope was requested, which subset was granted, and which tool operation required an elevation.

Secrets should live outside source code, tool descriptions, prompts, and ordinary logs. Use a secret store or protected environment configuration, grant only the process that needs the value, and rotate credentials when a log, prompt, or tool result may have exposed them. Never print bearer tokens in validation errors. Never ask the model to carry a long-lived downstream secret when the server can perform the authenticated call itself.

Short-lived credentials reduce exposure time, but expiry is not a substitute for access control. A server still needs to distinguish users, tenants, resources, and operations. If a workflow uses an explicit handle, bind it to the authenticated principal in server-side state. A random-looking handle is not permission to access another user’s data.

SSRF and Network Egress Controls

SSRF is not limited to a tool named fetch. It can appear in OAuth metadata discovery, webhooks, attachment downloads, image processing, repository imports, browser automation, and any function that accepts a destination. An MCP server or client may be tricked into contacting an internal service, a cloud metadata endpoint, or a management interface and returning the response through the agent.

The NVD record for CVE-2026-27826 describes an MCP Atlassian issue in which an unauthenticated attacker who could reach the HTTP endpoint could cause arbitrary outbound requests through custom headers. NVD maps the issue to CWE-918 and identifies version 0.17.0 as the fix. This is a useful reminder that middleware and dependency-injection layers can create risk even when tool-handler review finds no obvious flaw.

Use a positive network policy. Permit only the hosts, schemes, ports, and methods required for the operation. Resolve names safely, reject private and reserved address ranges where the deployment does not need them, validate redirect destinations, and consider an egress proxy. Check for DNS rebinding and time-of-check to time-of-use gaps. Network policy should remain effective if a model supplies a different URL than the description suggests.

Network controls should be tested from the real runtime, not only from a developer laptop. Containers, proxies, DNS settings, and cloud routing can change the result. A test that passes because the development network cannot reach an internal service is not proof that a production deployment is safe.

Filesystem, Shell, and Process Boundaries

Assume that a tool with filesystem or process access is high impact. Give it the narrowest directory, executable set, operating-system identity, and network access that its business function needs. A server that only formats a report should not receive a broad home directory or a general shell. A server that runs a compiler should not inherit credentials unrelated to the build.

Prefer direct library calls and fixed argument arrays over shell strings. If a process is unavoidable, use an approved executable path, a fixed working directory, a minimal environment, resource limits, and a timeout. Do not allow the model to select the executable, shell, interpreter, or redirection syntax. Treat filenames, archive members, repository content, and generated scripts as untrusted inputs.

Sandboxing reduces blast radius but does not make a dangerous operation acceptable by default. Review mounted volumes, device access, Linux capabilities, writable temporary directories, child-process permissions, and service-account credentials. Make the boundary visible in the deployment record. The question is not only whether the container starts. It is what the tool can do after a malicious argument is accepted.

File downloads deserve an additional review. Keep the destination inside a managed root, set safe file permissions, limit file size and archive expansion, and scan or quarantine content before another process loads it. Never allow a downloaded file to overwrite an executable, configuration file, scheduled task, startup script, or credential store merely because the caller supplied a path.

Prompt Injection, Tool Poisoning, and Human Approval

Prompt injection can arrive directly from a user or indirectly through a webpage, repository, file, tool result, or image. OWASP describes both forms and lists possible impacts such as sensitive-information disclosure, unauthorized function access, and arbitrary commands in connected systems. Its LLM01 Prompt Injection guidance recommends constrained behavior, clear output formats, filtering, least privilege, human approval for high-risk actions, separation of external content, and adversarial testing.

Tool poisoning is a related MCP-specific concern. A malicious or compromised tool description can influence which tool the model selects or how it fills arguments. A trusted tool can also change after approval. Pin versions, review descriptions as code, verify package provenance, and alert on changes to names, schemas, descriptions, endpoints, or required scopes. A tool’s annotation is a hint for the client, not proof that the tool is safe.

Human approval should be specific enough to be meaningful. Show the tool name, normalized arguments, target resource, requested scope, and likely side effect. Ask again when an operation crosses from read to write, from public to private data, or from a safe host to a privileged system. Avoid asking a user to approve a vague phrase such as “continue with task”.

Approval does not remove the need for server-side enforcement. A user can click the wrong button, a client can be compromised, and a model can misrepresent a tool result. Combine approval with authorization, validation, network policy, and a reversible workflow where possible. The MCP security best-practices page provides the protocol-specific discussion of these trust boundaries.

Dependencies, Supply Chain, and Shadow Servers

An MCP deployment includes more than its own source files. It may include an SDK, a transport package, an OAuth library, a container image, a connector, a model host, and configuration copied from a README. Track each component and its version. Prefer reproducible builds, lock dependencies, scan for known issues, and review changes that add a new network destination, tool, permission, or startup command.

OWASP’s MCP Top 10 labels software supply-chain attacks, dependency tampering, shadow MCP servers, token exposure, scope creep, tool poisoning, authentication gaps, and missing telemetry as separate risk areas. The OWASP MCP Top 10 project is identified as a living beta document, so treat its categories as a review map rather than a certification.

Shadow servers are easy to miss because a developer can launch a local process outside the central inventory. Require registration of server name, owner, source repository, build version, exposed tools, transport, network policy, and data access. Detect unexpected listeners and configuration files. Remove abandoned servers and revoke their credentials. A server that is not in the inventory cannot receive a meaningful security review.

Supply-chain review should include descriptions and examples, not just package hashes. A description can be changed to encourage a model to send secrets or bypass approval while the code remains unchanged. Compare the declared interface with the implementation, test the dangerous paths, and require review when a tool’s meaning changes. The Agentic AI explainer provides related context on delegated actions and model control.

Logging, Testing, and Incident Response

Logs should answer who invoked which tool, through which client, with which authorization context, against which resource, and with what result. Record normalized non-secret arguments, policy decisions, approval state, response status, duration, and a correlation identifier. Keep enough detail to investigate without copying passwords, access tokens, private documents, or full prompt content into an ordinary log stream.

Protect the audit trail from the same system it monitors. Restrict who can alter or delete it, synchronize time, retain records according to the business need, and send high-impact events to a separate destination. Alert on denied authorization, scope elevation, unexpected tools, unusual destinations, repeated validation failures, and changes to server configuration. Logging is useful only if someone can act on it.

Test the server as an untrusted user and as an untrusted document. Include unit tests for validation, integration tests for identity and policy, and adversarial tests that try to steer the agent into risky tools. Test both direct calls and realistic model-mediated calls. The AI agent identity discussion is a useful internal reminder that an agent’s apparent intent is not the same as a verified principal. Readers working on code workflows can also review the agentic coding guide.

When a vulnerability is found, disable the smallest affected capability first. Revoke exposed credentials, preserve relevant logs, identify the reachable data and systems, patch or pin the affected component, and retest from the attacker’s starting point. Do not declare resolution because a package upgraded cleanly. Confirm that the old exploit path is closed in the deployed environment.

A Practical MCP Security Release Checklist

Before release, assign an owner to each control and attach evidence. The checklist should be short enough to use and specific enough to fail. “Security reviewed” is not evidence. A passing item names the code path, configuration, test, or approval record that supports the decision.

Start with identity. Confirm the transport is protected where it needs protection, tokens are issued for the correct resource, scopes are narrow, and user or tenant authorization is enforced for every operation. Then review the tool surface. Remove unused tools, document side effects, pin dependencies, compare descriptions with code, and require approval for actions that can change data or systems.

Next test the sinks. Try traversal and alternate path forms. Try unexpected URLs, redirects, private destinations, oversized responses, malformed schemas, duplicated fields, shell metacharacters, and content that tells the model to ignore its task. Verify that errors do not leak secrets and that logs identify the decision without storing the secret itself.

Finally inspect deployment. Confirm the process user, container boundary, mounted files, environment variables, child-process rules, DNS behavior, egress policy, timeouts, rate limits, backup or rollback path, and alert routing. A secure source tree can become an unsafe service through one permissive volume or one unreviewed startup command.

A release should pause when a control is unknown. Mark the item as unverified, reduce the server’s permissions, or keep the affected tool disabled until the evidence exists. This is more useful than a green checklist assembled from descriptions. The goal is a narrow, inspectable trust boundary that remains safe when the model, user, document, dependency, or network behaves unexpectedly.

What to Verify Before Production:

An MCP server is ready for production only when its tool surface, identity model, input and output boundaries, network routes, filesystem and process permissions, dependency chain, and audit trail have been tested together. The protocol gives developers a common way to expose tools. The surrounding application must still decide which actions are allowed, who may request them, and how the system responds when a request is unsafe.

Use the official MCP security and authorization guidance as the control baseline. Use the VIPER-MCP paper and vulnerability advisories to design adversarial tests. Use OWASP categories to look for gaps in secrets, scopes, tool provenance, prompt handling, and telemetry. Then repeat the review whenever a tool, dependency, model host, transport, credential, or network route changes.

The most important release question is simple: if an attacker controls text that reaches the model, what is the most damaging operation the resulting tool call can still perform? Narrow that operation, require an explicit decision for it, and make the server reject anything outside the approved boundary. Security improves when the answer is specific, testable, and visible to the people who operate the service.