MCP security: threat model, risks, and production tests

Model Context Protocol security is the preservation of authority boundaries while an AI application discovers tools, receives untrusted context, selects actions, and reaches external systems. A secure deployment does not depend on the model always making a good choice. It constrains what a bad or manipulated choice can do.

This distinction matters because MCP connects model reasoning to real capabilities. A tool can read files, query customer records, send messages, change infrastructure, or call another service. The official MCP specification therefore treats tools as powerful capabilities and says tool descriptions must be considered untrusted unless they come from a trusted server.

The practical test is simple: define what the principal is allowed to read and do. Then try to make the system cross that boundary through hostile tool metadata, retrieved content, tool output, state, credentials, and changed server behavior. A test passes when the prohibited effect is denied and the evidence shows where the denial occurred.

A normal API integration usually has application code that decides which endpoint to call and which parameters to send. In an MCP-enabled agent, the model can participate in tool selection and parameter construction. It can also see natural-language descriptions and returned content that may have been written by another party.

This creates a mixed control plane. Some inputs are data. Some inputs describe capabilities. Some inputs are intended as user instructions. The model must reason across all of them, but security policy cannot assume that the model will always keep those categories separate.

The NSA Artificial Intelligence Security Center highlighted this problem in May 2026 when it released MCP-specific security design guidance. The agency noted accelerated adoption across business, finance, legal, software development, and other sensitive workflows. The important implication is not that MCP is inherently unsafe. It is that MCP can connect probabilistic reasoning to privileged systems, so implementations need explicit controls around the connection.

The July 2026 MCP specification release also continued to harden authorization. That is another useful signal: production MCP security is not only prompt filtering. It includes identity, issuer validation, credential isolation, scope, transport behavior, and the lifecycle of the tools being exposed.

A useful MCP threat model starts with the path from the user to the final resource. The main components are the principal, the MCP host, the MCP client, the MCP server, the tool, and the downstream system. Untrusted content can enter at several points, and policy can be enforced at several points.

Do not start with a list of attack names. Start with the boundary that must remain true. This avoids a common failure mode where teams collect impressive prompt-injection examples but cannot say whether a security property was violated.

MCP-DPT makes a similar architectural point. The paper organizes threats by the layer responsible for enforcing a defense and reports that existing protections are uneven and often concentrated around tools. That matters because a control at one layer cannot automatically replace a control at another.

An invariant is a condition that must remain true even when context is hostile. Good invariants make security tests falsifiable. They also make failures easier to assign to the correct owner.

Identity binding means that state, resource handles, approvals, and downstream requests remain tied to the authenticated principal. Audience binding means that a token intended for one resource is not accepted by another resource. Authority separation means that tool metadata, retrieved text, memory, or tool output cannot grant a permission that policy did not grant.

Tool integrity means that an approved tool definition cannot change without detection or revalidation. Scope preservation means that model-selected parameters cannot escape the allowed resource, path, tenant, host, or action set. Consent integrity means that a sensitive action cannot execute when policy requires fresh user approval and that approval was not provided.

Server provenance means that the host can distinguish approved servers from unapproved or impersonating ones. Execution isolation means that a local or remote tool cannot reach filesystem, process, credential, or network resources outside its runtime policy. Evidence completeness means that investigators can reconstruct the principal, server, tool definition, parameters, policy decision, approval state, downstream action, and result.

Not every strange tool choice is a protocol vulnerability. MCP deliberately gives models access to tools. A model can choose an irrelevant tool, misunderstand a description, or produce a poor plan without crossing a security boundary.

The security question begins when the choice produces unauthorized access or action. If a model attempts a prohibited call and a downstream authorization check rejects it, the model made a bad decision but the boundary held. If the same call succeeds because the server trusted tool metadata more than authorization policy, the system has a security failure.

This separation prevents inflated findings. It also improves engineering decisions. Teams can address model quality with prompts, model selection, tool descriptions, or routing. They must address authorization failures with deterministic enforcement.

Tool poisoning places adversarial instructions in tool names, descriptions, schemas, or returned content. Indirect prompt injection places adversarial instructions in external data such as a document, message, page, or retrieved record. In both cases the attacker tries to convert untrusted content into model authority.

Microsoft has documented tool poisoning as a form of indirect prompt injection in MCP deployments. OWASP also treats tool descriptions and tool returns as untrusted surfaces. These controls are useful, but the most important design rule is broader: untrusted content must not be able to increase what the current principal is authorized to do.

A prompt filter can reduce the chance that the model follows hostile content. It cannot prove that a downstream resource enforces tenant boundaries. A tool-integrity check can detect changed metadata. It cannot replace action-specific authorization. Defense in depth works when each control protects the boundary it can actually enforce.

MCP authorization requirements make audience binding explicit. A protected server must validate tokens for the intended resource, and token passthrough is prohibited in the current authorization guidance. This prevents one service from treating a token for another service as transferable authority.

The same principle applies to state. A handle or task identifier is not proof of identity. If user B can present a handle created for user A and gain access to user A's data or action context, the implementation has converted an opaque identifier into an authorization credential.

Confused-deputy problems appear when a privileged MCP server acts on behalf of a less-privileged caller without rechecking the caller's authority at the target resource. The correct test is not whether the server has permission. The correct test is whether this principal has permission for this resource and action.

An MCP server can be safe when approved and unsafe after it changes. A tool definition can drift. A package can be replaced. A local server can run with broad filesystem or network access. A parameter can point to a prohibited destination. These risks exist even when the model follows the user's intent.

This is why a production test plan needs integrity and isolation checks. Capture a stable representation of approved tool definitions. Detect material changes. Restrict local server execution to the directories, processes, credentials, and network destinations it needs. Treat any expansion of capability as a reason to revalidate.

OWASP recommends sandboxing local MCP servers and monitoring tool-definition changes. The exact mechanism can vary by platform. The invariant should not: approval of one capability must not silently become approval of a broader capability later.

The following test suite is a method, not a claim that NullSquare ran these tests against a specific product. Run it in an authorized synthetic or staging environment. Use fake users, fake records, canary secrets, and controlled endpoints. Do not use real third-party data or public services as test targets.

Each case needs an expected decision before execution. Include a hostile case and a benign control. Record the exact versions of the host, client, server, model, tool definition, policy, and protocol. If model behavior is stochastic, repeat the case enough times to separate a stable control failure from a one-off model choice.

The test ends at the downstream effect. A blocked tool call is useful evidence. A model refusal is not enough if the prohibited action would still succeed when called. A suspicious model output is also not enough to prove a backend vulnerability.

A useful MCP security test has five parts. First, state the attack hypothesis. Second, name the invariant at risk. Third, identify the layer that must enforce the control. Fourth, state the expected decision. Fifth, define the evidence that proves the result.

For tool poisoning, the attack hypothesis is that hostile metadata can cause a forbidden action. The invariant is authority separation. A host may inspect tool integrity, but the downstream service must still enforce authorization. The expected result is denial of the forbidden action. The evidence should include the before-and-after tool definition, attempted call, principal, policy result, and absence of the prohibited downstream effect.

For cross-user state, the attack hypothesis is that possession of another user's handle becomes authority. The invariant is identity binding. The server is the primary enforcement point. The expected result is rejection. The evidence should show the authenticated principal, state owner, presented handle, and denial.

This structure is more valuable than a generic checklist because it makes ownership explicit. When a test fails, the team knows which control did not preserve the boundary.

A secure test environment can appear perfect if it rejects every tool call. That is not useful. The benchmark needs both security and utility measures.

Use Unauthorized Action Rate as the primary boundary metric: the fraction of trials where an adversarial condition causes a data disclosure or state-changing action that declared policy prohibited. Measure unauthorized data reads, approval bypass, out-of-scope access, and drift detection separately when those distinctions help diagnosis.

Also measure benign task completion and false denials. If a new control reduces unauthorized actions but breaks normal work, the result is a trade-off that needs an engineering decision, not a victory statement.

MCP Security Bench is useful context here. Its ICLR 2026 evaluation spans 12 attack categories, 2,000 attack instances, and 405 tools across realistic tasks. Its results are study-specific, not universal rates, but the benchmark demonstrates why MCP security evaluation should cover planning, invocation, and response handling rather than one prompt surface.

Semantic detection is useful for tool metadata, prompt injection, and suspicious returned content. It is weaker evidence for claims about backend execution. A string that looks like a credential can be a placeholder. A suspicious command fragment can be inert text. A claimed file read can be fabricated model output.

FlowGuard makes this evidence distinction explicit. The July 2026 preprint evaluates a design that combines semantic triage with schema-valid runtime probing and evidence adjudication. The paper reports results on its own 1,880-case benchmark and a real-world server set. Those numbers should be treated as study-specific findings, but the methodological lesson is broadly useful: use observable runtime evidence when the claim is about execution.

For an internal production gate, this means a finding should contain the artifact that proves the effect. Examples include a synthetic record identifier that was returned without permission, a policy denial tied to the tested principal, a sandbox rejection, or a canary marker reached only when an unauthorized action executed.

MCP security becomes hard to investigate when logs stop at the model message or tool name. A state-changing event should be traceable from identity to outcome.

For each tool invocation, record the authenticated principal, server identity, tool name, stable tool-definition hash or version, parameters after validation, authorization decision, approval requirement, approval event, downstream resource, downstream action, result category, and timestamp. Record the model, host, client, server, policy, and protocol versions for security-test runs.

Do not put secrets or unnecessary personal data into logs. Evidence completeness is not the same as copying everything. Keep the identifiers and decisions needed to reconstruct the chain, and apply normal data-minimization and retention rules.

A production checklist is useful only when each item maps to a boundary and a test. The following list is a release gate, not a substitute for the test cases above.

MCP security is not a one-time installation review. Tool metadata, server code, models, policies, connectors, scopes, and downstream systems can change independently.

Retest when a server or tool definition changes. Retest after model or host upgrades. Retest when authorization scopes expand, when a new connector is added, when a tool changes from read-only to state-changing, when a downstream API changes its permission model, or when a security control moves to a different layer.

Keep the old passing case as a regression test when possible. A stable set of boundary tests gives the team a release signal that is much stronger than rerunning an ad hoc collection of jailbreak prompts.

A passing MCP security suite does not prove that an agent is universally safe. It proves that defined boundaries held for defined cases under recorded versions and conditions.

The threat model can miss a boundary. A test corpus can miss an attack family. A policy can encode the wrong business rule. A model or server update can change behavior. Third-party services can enforce permissions differently from the synthetic environment.

Academic results cited here also have limits. MCP Security Bench, MCP-DPT, and FlowGuard evaluate specific datasets, systems, and methods. Their reported measurements should not be treated as population-wide vulnerability rates.

The right operational response is versioned evidence and repeatable retesting. State what was tested, what was not tested, what result was observed, and which control enforced the decision.

The strongest MCP security posture is not a longer list of prompt filters. It is a system where untrusted context can influence reasoning without silently increasing authority.

Define the boundaries first. Put deterministic controls at identity, authorization, resource, network, and runtime enforcement points. Test the controls with hostile and benign cases. Require runtime evidence for execution claims. Keep the versioned evidence so the same boundary can be tested again after change.

This is also the principle behind evidence-backed security testing more broadly: a finding is useful when the scope is authorized, the effect is reproducible, the evidence is retained, and the same condition can be retested after a fix.