MCP security: how to assess servers and govern access

Updated November 1, 2026. Includes the July 2026 MCP specification and research published through October 2026.

An approved vendor can still introduce an unapproved way to access your data. An employee connects an AI assistant to a document store, gives it permission to read files, then adds a tool that sends messages. Each connection may look reasonable on its own. Together, they let the assistant move information between systems.

That is the practical MCP security question for governance, risk, and compliance teams: what can this workflow read, change, and disclose? Our recommendation is to approve a defined use of MCP: the host application, server, identity, tools, and data destinations involved. A vendor approval alone leaves too much unspecified.

What is MCP security, and who is responsible?

The Model Context Protocol (MCP) is an open protocol that lets AI applications connect to tools and data sources. The host is the AI application. It manages clients that communicate with MCP servers, which expose tools, resources, and prompts. A server may run locally or as a remote service. The official architecture assigns the host responsibility for connection permissions, consent, and security policy; each client communicates with one server.

MCP gives applications and tools a shared interface. The host configuration and access controls determine which connections and actions are allowed.

An MCP security review checks the software you connect, the identity it uses, the tools it exposes, and where data can go. It also tests whether those limits hold when the agent reads malicious content or a connection changes. A secure server cannot compensate for an assistant that sends sensitive results to an unapproved destination.

MCP has authorization controls. Verify the implementation.

The July 28, 2026 specification defines an OAuth-based authorization framework for HTTP deployments. Authorization is optional at the protocol level; implementations that support it have explicit requirements, including validation that an access token was issued for the intended MCP server. Local stdio deployments use a different credential model.

The July release also hardened authorization and deprecated Dynamic Client Registration in favor of Client ID Metadata Documents, while retaining it for compatibility. Ask which protocol and SDK versions the deployment actually uses. A link to the latest specification is not evidence that a running integration follows it.

For sensitive enterprise access, require demonstrated enforcement: reject the wrong user, the wrong token audience, and an action outside the approved scope. The MCP security guidance separately addresses token passthrough, confused-deputy attacks, malicious discovery URLs, and local server compromise. These require different controls; grouping them all under prompt injection obscures what needs fixing.

What recent MCP security research changes about the review

Tool descriptions and results can carry instructions

Tool poisoning places malicious instructions in metadata the agent reads when discovering tools. Indirect prompt injection can also arrive through a tool result, document, or message. Authentication can verify an identity; it does not make a returned document or tool description trustworthy.

MCPTox, revised in September 2026, evaluates tool poisoning using 45 servers, 353 tools, and 20 agent settings. It shows that metadata can redirect an agent toward unauthorized actions using legitimate tools. Its attack-success figures describe that benchmark, not the probability that a particular enterprise deployment will be compromised.

Server-supplied descriptions and results cross a trust boundary. Treat their contents as external input when deciding what the agent may do next.

A correct answer can hide an unauthorized action

The Log-To-Leak preprint, submitted October 26, 2026, tested five MCP servers and four agents. The attack induced a separate logging call to an attacker-controlled tool after legitimate work. Task completion could remain largely intact while information was disclosed. This is an experimental result, not a survey of production incidents.

For a GRC workflow, that distinction matters. A correct assessment summary does not tell you whether the agent also sent the source report elsewhere. Test the complete sequence of actions, including secondary calls and destinations, alongside answer quality.

The host’s configuration is part of the attack surface

In an October 2026 disclosure, Johann Rehberger demonstrated how a path-validation flaw in Visual Studio Copilot and SQL Server Management Studio could let an injected agent change protected configuration and enable command execution. Microsoft issued a fix under CVE-2026-103572. This was an implementation vulnerability, not evidence that every MCP server permits remote code execution.

The review should therefore include the AI application’s version, patch status, and ability to change its own connector configuration. Reviewing only the server would miss that failure path.

Classify the deployment before sending a vendor questionnaire

MCP can create third-party risk, but not every server is a new vendor. Separate who supplies the code, who operates it, and who receives the data. A self-hosted open-source server needs software supply-chain and runtime review. A vendor-hosted service also needs supplier and data-handling review. An internal server needs an accountable engineering owner and access-control review.

Then record the use case: employee AI on a workstation, an internal business workflow, or a production service used by customers. These labels help assign ownership, but they are not risk ratings. An employee assistant with customer records and a messaging tool may warrant more scrutiny than a production tool that only searches public documentation.

Local execution deserves particular attention. As Anthropic explains in its containment research, an MCP server running on the local machine can have capabilities outside the agent’s own sandbox. Verify the server process’s filesystem, network, and credential access separately. Remote hosting changes the boundary; it does not remove the need to review permissions and data handling.

For external providers, connect this review to third-party risk management (TPRM) and your AI vendor assessment. Keep the deployment-specific decision attached to the supplier record so approval of one use is not mistaken for approval of every integration.

An MCP security review: questions and evidence

Use the following as a review record. Ask engineering to demonstrate the controls in the intended environment. GRC should retain the decision, evidence, exceptions and person accountable for accepting the remaining risk. A generated explanation is useful context, but reasoning-faithfulness research shows why it cannot replace an independently recorded action and outcome.

This record turns guidance into something testable. CoSAI’s MCP security report supports maintaining an inventory, reviewing the software supply chain, tracking versions, and testing updates. A completed questionnaire should point to those records and tests.

Apply controls to the workflow’s actual reach

Start with the smallest useful permission set. Separate read access from modification and export capabilities. Enforce authorization in the host, server, and downstream service as appropriate; do not rely on a prompt asking the model to stay within scope. For sensitive actions, the approval should identify the target, data, and consequence so the reviewer can make a real decision.

Tool-description checks, process isolation, restricted network destinations, and change detection address different failure paths. OWASP’s MCP security guidance covers these controls and recommends treating servers as separate security domains. Test combinations of tools too: a document reader and an outbound messaging tool create a disclosure path that neither tool has alone.

A gateway can centralize enforcement and logs for traffic routed through it. Confirm that local processes and alternative connections cannot bypass that route. NSA’s May 2026 guidance examines security across the agentic environment, including trust boundaries and agent misuse. An endpoint check alone cannot establish that the whole workflow is controlled.

Read-only access still needs an evidence-integrity review

Consider an assistant collecting access-review evidence. Restricting it to reads prevents it from changing the source records, but it may still retrieve the wrong period, omit a population, or treat text in a ticket as an instruction. Our recommended acceptance test checks the source system, organization, reporting period, collection time, and completeness of the returned records.

Keep the retrieved evidence separate from the agent’s interpretation. A tool returning data does not establish that the control operated effectively. The reviewer needs enough provenance to reproduce the finding and see where collection failed or coverage was incomplete.

Keep approval current as the integration changes

Record an approval for a specific workflow and its limits. For example: an internal assistant may read a designated evidence folder and draft an assessment for review. Adding an email tool, expanding the folder scope, or allowing the assistant to change access rights should reopen the relevant part of that decision. A hosted server can also change its implementation without changing its tool descriptions. Keep a provider change-notification and reassessment process; a saved manifest cannot establish that behavior stayed the same.

Our recommendation is to assign engineering the configuration and tests, security the technical review, the data owner the permitted use, and GRC the evidence and decision record. Name the person authorized to accept residual risk. Test disablement while a workflow is active, including queued or delegated work. Removing a visible connection is not proof that its credentials can no longer be used.

That gives the organization a concrete answer when someone asks whether an MCP integration is approved: which workflow, which data, which actions, and under whose authority. Use that record within your broader AI agent governance program.