MCP server security: a review checklist

Define the boundary and the protocol revision

A Model Context Protocol server exposes data or operations to an MCP client. In a business application, those operations may read customer records, retrieve documents, create drafts or change live state. The security review therefore starts with what the server can do and on whose behalf it can do it.

This guide references MCP revision 2026-07-28 and distinguishes its requirements from additional engineering recommendations. That revision removes protocol-level sessions from the core transport and uses explicit handles for application state spanning requests. If your implementation targets an older revision, review its own requirements and plan compatibility deliberately. Do not mix transport or authorization assumptions from different revisions.[1]

Draw the path from the user and host through the MCP client, authorization service, MCP server and downstream systems. Mark where identity is established, where permissions are checked, where credentials are stored and where data crosses a trust boundary. Identify local STDIO deployments separately from remote HTTP services; the specification’s HTTP authorization flow is not the prescribed flow for STDIO.[2]

Separate identity from permission to act

Authenticating the caller establishes an identity or credential. It does not establish that the caller may read a particular record or perform a particular operation. A token that permits access to a service is not automatically permission to act across every customer, project or object the service can reach.

For protected HTTP implementations using MCP authorization, validate tokens for the intended resource and reject invalid or expired credentials. The specification prohibits accepting or forwarding tokens intended for other resources. Use an appropriate downstream authorization design rather than treating the MCP server as a transparent tunnel for arbitrary credentials.[2]

• Derive the customer or project boundary from trusted identity and policy, not solely from a tool argument.
• Check the caller’s permission against the specific object and operation at execution time.
• Constrain downstream credentials to the required capabilities and protect them from tool outputs and logs.
• Test expired credentials, revoked access, wrong audience and insufficient permission separately.
• Recheck authority when executing a previously prepared action; approval or access may have changed since drafting.

These controls belong in the application and relevant downstream systems. A prompt that tells the model not to access another customer is useful behavioral guidance, but it cannot replace enforcement. The same principle applies to authorization rules embedded in tool descriptions.

Design tools around bounded business actions

A general-purpose “execute SQL,” “run shell” or unrestricted HTTP tool exposes a much broader capability than a task-specific read or draft operation. That may be intentional in a tightly isolated developer environment. It deserves a different review when the tool can reach live data or business systems.

• Define an input contract and validate it on the server, including identifiers, field lengths, accepted values and business constraints.
• Return only the data necessary for the task; avoid exposing raw credentials or unrelated customer content.
• Separate preparation from commitment when a consequential action needs review.
• Bind approval to the actual action and relevant parameters; a generic prior approval should not authorize a materially changed request.
• Specify what retry means for each write, including how duplicates are prevented or reconciled.
• Set execution, concurrency and resource limits appropriate to the operation.

Tool annotations can describe behavior, but the MCP specification warns clients to treat annotations as untrusted unless supplied by a trusted server. Labels such as read-only or non-destructive do not establish an enforceable security boundary. Inspect the code path and test the operation.[3]

Translate threats into tests and evidence

A passed test is evidence about the tested condition, not proof of complete security. Record the environment, revision, caller, inputs and observed result. Retain a reproducible finding when a control fails, with an owner and a verification step for the fix.

Treat external content as data, not authority

An agent may encounter hostile instructions in a document, web page, repository or tool response. The risk is not limited to text a user directly enters. OWASP describes prompt injection as an application risk when untrusted instructions influence model behavior.[5]

Reduce the consequences of that influence. Enforce permission boundaries outside the model, limit reachable operations, separate trusted instructions from retrieved material and require authorization for consequential actions. Validate structured outputs before they become inputs to another privileged operation. A content filter or stronger prompt can be one layer; neither justifies broad unrestricted tools.

Test for indirect paths as well as direct ones. A malicious document may try to alter a later tool argument, steer a URL fetch, expose a token through an error message or change what a reviewer sees. The test should inspect the resulting action and data flow, not only whether the final prose sounds compliant.

Review discovery, delegated access and state handles

Authorization can introduce its own network and consent boundaries. MCP’s security guidance describes confused-deputy risks in proxy designs, server-side request forgery during metadata discovery, and state-handle hijacking. Review these paths explicitly rather than assuming a successful sign-in proves the integration safe.[4]

For URL retrieval and discovery, constrain destinations and redirects according to the deployment’s trust model. Consider private networks, loopback addresses, cloud metadata services and changes in name resolution. A string check at the start of a request is not necessarily enough to control where it ultimately connects.

For delegated downstream access, make consent specific to the client and requested use. Keep redirect validation and authorization response validation aligned with the implementation’s protocol requirements. Do not route credentials through model-visible context as a convenience.

For the current stateless MCP core, a workflow ID or other explicit handle is application data, not authentication. Bind state access to the authorized caller and relevant customer boundary on each request. Apply expiration and lifecycle rules where appropriate. Guess-resistant identifiers can help reduce exposure, but possession of an identifier should not silently bypass authorization.

What should be ready for a release review?

• A dated architecture and data-flow diagram showing the trust boundaries.
• The protocol revision, transport, client compatibility and relevant dependency versions.
• A tool inventory with read/write behavior, caller roles, downstream authority and approval requirements.
• A record of authorization, isolation, retry, injection and recovery tests, including unresolved failures.
• A logging and retention policy with access controls and redaction behavior.
• A deployment record, credential-rotation process, disable procedure and recovery runbook.
• An owner for each material risk and a check that determines whether remediation is complete.

Run the relevant tests when tool behavior, authorization policy, dependencies or protocol support changes. Where the consequence warrants it, commission a scoped independent security assessment. A checklist is useful for organizing work; it is not a replacement for examining the specific system.