TL;DR: Several public MCP security scanners returned clean or zero-finding results even when malicious servers could steal credentials or execute commands at runtime, according to Pluto Security research after testing five public MCP security scanners. The result shows that scan coverage, not just scan outcome, determines whether an MCP check is actually meaningful.
At a glance
What this is: This is a research note showing that MCP scanners can miss malicious servers when they inspect only metadata, partial source, or truncated evidence.
Why it matters: It matters because IAM, NHI, and agentic AI teams may mistake a clean scan for trust, even when the server can still expose credentials or trigger unsafe tool use at runtime.
Context
MCP security scanning is only useful when it answers the same question the operator is asking. A clean result can mean the scanner saw no obvious problem in the material it inspected, while the server still behaves dangerously once an agent calls a tool.
The governance gap is straightforward: teams often assume a pre-install check proves runtime trust. In practice, MCP servers can hide credential theft, command execution, or tool poisoning behind ordinary metadata, which means discovery and execution are not the same control problem. See MCP security as the baseline for that distinction.
This article tests that boundary directly by comparing metadata, static source, and LLM-based checks against servers that behaved normally to the user while performing unsafe actions in the background.
Key questions
Q: What breaks when an MCP scanner only checks metadata?
A: It misses the server’s real behavior at tool-call time. A malicious MCP server can look harmless in its description or schema while reading files, forwarding secrets, or executing commands later. That is why metadata-only checks should be treated as partial evidence, not as proof that the server is safe to run.
Q: Why does incomplete MCP scanning create false confidence?
A: Because the result reflects the evidence the scanner actually saw, not the whole server. If a file is truncated, skipped, or excluded from the model input, the scan can return a clean result while the risky code remains untouched. Incomplete analysis should be treated as an unfinished control, not a passing one.
Q: How should teams evaluate an MCP server before production use?
A: Check maintainer identity, documentation quality, update recency, and dependency posture, then validate that the client can be limited to specific tools and actions. A directory score or popularity rank is not enough for production decisions. The real test is whether the server can be governed as a bounded identity relationship.
Q: How do you know an MCP server scan is actually meaningful?
A: You know it is meaningful only when you can state exactly what the scanner covered and what it could not cover. A result that includes metadata but excludes source, runtime behavior, or oversized files cannot answer the full trust question. The useful question is coverage, not the badge on the result.
Technical breakdown
Why MCP scanners miss runtime abuse
Most MCP scanners observe the server before or outside tool execution. That means they can inspect names, descriptions, schemas, and even source code, yet still miss behavior that only appears when a handler runs. A server can present a harmless weather tool while reading secrets, fetching a command, or forwarding output once called. The technical issue is not that the scanner is broken. The issue is that the inspection surface is narrower than the execution surface, so the scan is answering a different question from the one operators care about.
Practical implication: Treat metadata-only and pre-execution scans as evidence, not proof of safety.
Why oversized or partial analysis creates false confidence
An LLM-assisted review can still fail if the tool never receives the code that contains the risky behavior. When truncation, file limits, or prompt budget issues exclude the relevant handler logic, the model may review the manifest and miss the actual attack path. That creates a dangerous asymmetry: the review looks complete in the output, but the most important code never reached the model. In security terms, incomplete analysis is not a weaker verdict. It is an incomplete control event.
Practical implication: Verify that the scanner reviewed the full executable surface, not just a partial excerpt.
How malicious MCP servers can stay useful while still being unsafe
A malicious MCP server does not need to fail visibly to be dangerous. It can answer the user’s request normally while doing something harmful in parallel, such as reading credential files, shipping data to a collector, or invoking a shell command fetched from another service. That dual behavior is what makes MCP trust boundaries hard: the user sees the intended result, while the hidden path turns the server into an exfiltration or execution mechanism. Static descriptions alone cannot prove intent or runtime safety. See the NHI Authentication Guide.
Practical implication: Assume a legitimate-looking tool can still be hostile unless you test its runtime side effects.
Threat narrative
Attacker objective: The objective is to hide credential theft or command execution behind a tool that appears benign during scanning and during normal user interaction.
- Entry occurs when a user or agent installs or connects to an MCP server that advertises a harmless tool such as weather lookup.
- Credential access or execution happens only when the tool is called, at which point the handler reads local secrets or runs a fetched command.
- Impact follows when the server sends stolen data to a collector or returns command output while the user still receives a normal response.
Breaches seen in the wild
- Smithery.ai MCP hosting breach 2025: A Smithery.ai build flaw gave GitGuardian a live fly.io token controlling 3,000+ hosted MCP servers and the API keys their clients sent.
- postmark-mcp malicious MCP server 2025: A fake Postmark MCP server on npm quietly BCC'd every email AI agents sent through it to an attacker, using victims' own Postmark tokens.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Clean scan results do not establish runtime trust for MCP servers. The scanner may have reviewed tool names, descriptions, or partial source, but MCP risk lives in what the server actually does when an agent invokes it. That gap is structural, not cosmetic. Security teams need to stop treating a zero-finding result as a trust decision and start treating it as one input into a broader review of runtime behavior.
Coverage, not verdicts, is the meaningful control signal. A scan that omits a file, truncates evidence, or avoids execution can still be useful, but only if the operator knows exactly what it inspected. The named concept here is scan coverage debt: the difference between what the tool claims to assess and what it can actually see. That debt becomes a governance problem when procurement or platform teams rely on the result as a release gate.
MCP trust boundaries now span metadata, source, client identity, and runtime side effects. The article shows that a server can tailor its behavior based on the client, hide payloads in helper code, or move the dangerous action behind a later tool call. That breaks the assumption that a single pre-install check can resolve trust. Practitioners should design review processes around observable behavior, not just declarative metadata.
Identity controls matter because MCP servers are privileged actors, not just software packages. Once a server can read files, receive credentials, or influence downstream agent decisions, it behaves like a non-human identity with access scope. That means governance must follow the access path as well as the code path. The right question is whether the server’s permissions are constrained to the minimum runtime surface it actually needs.
From our research library:
- 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
- Read next: MCP Security Guide
What this signals
Scan coverage debt: MCP teams should expect the gap between checked surfaces and executed surfaces to become a recurring governance issue. The practical response is to classify scanner output by coverage class, not just by result class, because a clean metadata scan and a clean runtime review are not equivalent.
Pre-install checks will remain useful, but only as part of a layered review model that includes runtime isolation, permission scoping, and post-install monitoring. That is especially true for servers that can touch secrets, file systems, or outbound network paths, where the trust decision is really about what the server can do after it is installed.
For practitioners
- Validate scan coverage before trusting results Record whether the scanner inspected metadata, source files, dependency context, tool output, and runtime behavior. Do not accept a clean label unless you know which surfaces were actually examined.
- Test unknown MCP servers in isolation Run new servers in a sandbox with fake credentials, a temporary home directory, and restricted network access so you can observe what they touch when tools are called.
- Pin and review the exact server version Track the commit, package hash, and update path for every server you allow, because behavior can change after installation even when the tool name stays the same.
- Separate metadata review from runtime review Use static analysis, dependency inspection, and live execution tests as different checks, not as substitutes for one another.
- Limit the files and credentials each server can see Grant only the local paths, environment variables, and outbound destinations the server genuinely needs, then watch for any attempt to expand that scope.
Key takeaways
- MCP scanners can miss malicious behavior when they inspect only metadata or an incomplete slice of source code.
- The article shows that a server may still steal credentials or execute commands at runtime even when the scan comes back clean.
- The control gap is not the absence of scanning but the assumption that one scan can certify trust across metadata, code, and runtime behavior.
Related NHI Mgmt Group resources: MCP Security Guide · NHI Authentication Guide · Smithery.ai MCP hosting breach 2025
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | The article centers on MCP servers that can expose credentials at runtime despite clean scans. |
| NHI-04 — Insecure Authentication | The article shows that scanner trust can be bypassed when servers and clients interact through incomplete identity checks. | |
| NHI-05 — Overprivileged NHI | The hidden servers only become dangerous because they inherit access to files, credentials, or outbound destinations. | |
| Recommendation — Treat runtime credential exposure as a secret leakage problem and verify that scanners inspect the paths where secrets can actually appear. Validate how MCP servers authenticate and authorize tool use, then test whether the review process sees those trust decisions. Reduce server privilege to the minimum runtime access needed and block any unnecessary file or network reach. | ||
| MITRE ATT&CK | TA0006; TA0010 — Credential Access; Exfiltration | The malicious MCP servers read credentials and send them to a collector, matching classic access and exfiltration stages. |
| Recommendation — Map MCP server abuse to credential access and exfiltration tactics, then hunt for file reads followed by outbound data transfer. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article is about whether MCP servers are allowed to touch data and tools beyond their declared purpose. |
| Recommendation — Align MCP server permissions to declared function and remove any entitlement that is not required for the approved use case. | ||
Key terms
- MCP scanner: A scanner that inspects a Model Context Protocol server for security issues before or during deployment. In practice, it may check metadata, source code, dependencies, or runtime signals, but its value depends entirely on which of those surfaces it can actually see.
- Runtime Trust: Runtime trust is the idea that access should remain valid only while current context justifies it. Instead of trusting a setup decision indefinitely, teams continuously re-evaluate whether a workload or agent still deserves privilege. This approach is especially important for AI agents that can change behaviour mid-task.
- Scan coverage: The portion of a server’s behavior that a security check can actually inspect. For MCP, coverage can be limited by file size, prompt budget, metadata-only review, or tools that never execute the server, which means a passing result may still be incomplete.
- Malicious MCP Server: A malicious MCP server is a tool endpoint that pretends to support Model Context Protocol while secretly abusing the trust placed in it. Technically, it can intercept prompts, steal credentials, exfiltrate data, inject unsafe tool responses, or redirect agent actions, turning an AI integration point into an attack surface.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an identity security programme, it is worth exploring.
Published by the NHIMG editorial team on October 22, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org