How to Detect a Malicious MCP Server

A malicious MCP server is one that intentionally uses its code, tools, resources, prompts, credentials, or network position to produce an unauthorized effect. Detection needs more than a vulnerability alert: identify the exact component, show how it can reach a protected target, and retain evidence that supports allow, isolate, or remove.

Establish what malicious means

Start with an approved purpose and boundary. Write down which host will connect, which tools are needed, what data may be read, which systems may be changed, and which identity the server may use. Without that baseline, broad access can look normal simply because no one defined what normal is.

Separate three outcomes. A vulnerable server contains a weakness that may be exploitable. A misconfigured server has unsafe settings or excessive privilege. A malicious server contains intentional behavior or instructions designed to misuse the agent, steal data, hide actions, persist, or redirect trust. The response can differ, but all three may require isolation until the evidence is understood.

Use the MCP server scan before installation process for any artifact that has not run yet. Detection after installation requires the additional runtime and target-state checks below.

Check provenance before execution

Pin the repository commit, package version, container digest, or binary hash. Verify the publisher, release path, signatures or checksums, ownership changes, install scripts, and dependency lockfile. Compare the running artifact with the approved digest. A familiar name or active repository is context, not proof.

Investigate a release that cannot be traced to source, changes after approval, downloads code during installation, disables certificate checks, or relies on a mutable tag. Also investigate sudden maintainer transfers, replaced release assets, unexplained obfuscation, and dependencies added shortly before the release.

Decision standard: provenance passes only when another reviewer can retrieve the same bytes and reproduce the hash. If the running bytes differ, disable the server before deeper analysis.

Inspect every server component

Map the server by component: executable code, dependencies, tool handlers, resource providers, prompt templates, transport, authentication logic, update mechanism, and configuration. The component view matters because a benign tool handler can still be exposed through a malicious prompt template or unsafe token proxy.

Inspect process creation, shell construction, dynamic imports, remote downloads, filesystem traversal, environment-variable access, secret discovery, telemetry, and outbound clients. Trace untrusted input into commands, paths, URLs, database queries, and message destinations. Record the behavior and its reachability in the approved configuration.

The recent research paper Understanding and Detecting Malicious MCP Servers uses a component-centered analysis rather than treating a server as one opaque score. That is the useful operational lesson here; the paper is research evidence, not a guarantee that one detector catches every server.

Detect tool-description and schema abuse

Retrieve the complete tool list and descriptions over the protocol. Do not rely on a client UI that truncates metadata. Look for instructions that tell the model to ignore policy, collect unrelated data, avoid confirmation, prefer the malicious tool, or conceal an action. Compare returned metadata with the repository and an accepted baseline.

Inspect input schemas and handler behavior together. A narrow-looking schema is misleading if the implementation concatenates values into a shell command, follows arbitrary redirects, accepts wildcard paths, or ignores the declared enum. Test malformed values, extra properties, alternate encodings, path traversal, loopback and cloud-metadata destinations, and cross-tenant identifiers.

Hash accepted tool names, descriptions, and schemas. A later change is a detection event even when the package version remains the same. This catches metadata drift and rug-pull behavior that a one-time source review misses.

Observe runtime behavior and identity use

Run the pinned artifact in a disposable environment with synthetic data, no personal credentials, read-only mounts, restricted egress, and a dedicated identity. Capture child processes, file access, DNS, connections, token requests, tool calls, and changes to the advertised tool list.

Exercise one expected action, one malformed request, one unauthorized target, and one harmless analogue of a high-impact operation. A denial is proven by the target state: no file appears, no message is sent, no record changes, and no connection reaches the forbidden destination. A log line alone is not enough.

AgentGuard publicly describes Deep Scan for MCP servers and selected pre-execution Runtime Guard decisions. Those can contribute component and action evidence within supported integrations. Its public FAQ also says it cannot fully monitor or block every third-party MCP runtime call, so keep host telemetry, identity logs, and downstream audit evidence in the detection design.

Correlate signals into a decision

Do not add unrelated findings into a single magic risk score. Correlate artifact identity, code path, metadata, requested privilege, runtime trace, and target outcome. A high-confidence malicious decision should state what component acted, what it attempted, which identity and target were involved, and what evidence connects the attempt to the artifact.

Use four states: allow, allow with a time-bound exception, isolate for investigation, and remove. Unknown evidence belongs in isolate, not allow. Document who owns each exception, its compensating control, and its expiry.

Keep the minimum evidence record compact and reproducible:

• artifact digest, package source, version, and retrieval time;
• server component and code path associated with the signal;
• full tool metadata hash and the specific changed field;
• validated identity, requested tool, normalized arguments, and destination;
• process, file, network, token, and downstream target-state observations;
• decision, reason, owner, exception expiry, and containment result.

Separate observed facts from conclusions. “The process connected to an undeclared domain” is evidence. “The package is malicious” is a conclusion that also needs attribution to the artifact, reachability, intent indicators, and an unauthorized effect. This separation lets another reviewer challenge the decision without losing the underlying trace.

The wider AI agent security controls page helps place server findings beside model, host, credential, and downstream controls. Keep link-bearing evidence paragraphs separated so a reader can follow the decision rather than a list of references.

Contain a suspected server

Stop new connections and revoke the server's credentials before analyzing it on the original host. Preserve the artifact, configuration, tool metadata, process tree, relevant logs, network destinations, and hashes. Rotate secrets the server could read, not every organizational secret by default. Search for the same digest, package, endpoint, and identity across other hosts.

Do not delete the only copy of the evidence or run the suspect package again with production access. Rebuild affected hosts when persistence or integrity cannot be excluded. Notify owners of downstream systems that received an unauthorized request and verify target state directly.

Use the official MCP Security Best Practices for authorization and confused-deputy checks, while keeping malware, package provenance, and incident response in your own control set.

Validate detection and regression

Create a small regression corpus: an approved server, a server with a changed description, an undeclared network destination, a path traversal attempt, a token with the wrong audience, and a harmless high-impact request. Expected results must name the evidence and containment action, not merely “alert generated.”

Re-run after artifact, dependency, tool metadata, permissions, identity, network destination, host integration, or detector-rule changes. Confirm both false-negative and false-positive paths: malicious analogues are isolated, while the approved server action still completes within its boundary.

Add bypass cases when the server exposes more than one transport or execution route. A protected HTTP handler is not enough if a local command, streaming path, cached session, background queue, or direct internal call reaches the same tool without the detection point. Verify each route with an unchanged forbidden target, not only a common alert message.

Detection also needs an availability failure path. If telemetry, identity resolution, policy lookup, or evidence storage is unavailable, decide which operations fail closed and which narrow reads may continue. Record that behavior in the test suite so an outage does not silently convert an investigated server into a trusted one.

When selecting supporting controls, compare their evidence surfaces in the MCP security tools guide. A scanner, gateway, host hook, identity system, and downstream audit log answer different parts of the detection question.