A buyer-decision guide for security leaders: a plain self-qualifier for whether your AI agents need a dedicated MCP server security assessment, the five things one actually tests, and why an automated scanner cannot cover the connector layer.
The National Security Agency now publishes formal guidance on how to secure Model Context Protocol deployments. In a 2026 Cybersecurity Information Sheet, the NSA's Artificial Intelligence Security Center warned that MCP's proliferation "outpaced the development of its security model," and that its risks "cannot be patched at isolated endpoints and must be addressed across the entire MCP environment" (NSA AISC, 2026). When a signals-intelligence agency writes design guidance for a connector protocol, that protocol has become production infrastructure. The open question is no longer whether MCP is a real attack surface, but whether your MCP servers sit inside the scope of anything you currently test.
Here is the direct answer to the question most teams are asking. The AI agents connecting to your internal tools and data need a dedicated MCP server security assessment when they can act, not just chat. If an agent can call a tool that reads a customer database, hits an internal API, moves money, files a ticket, or runs a shell command, the connector between the model and that tool is a privileged execution path that your web application pentest and API scan do not cover. A chat-only assistant that summarizes public documents is a lower priority. An agent with tools wired into production is exactly what the MCP CVEs of 2025 were exploited through.
An MCP server security assessment is a human-led penetration test of that connector layer. It tests five things a scanner cannot reason about: authentication and authorization, tool poisoning, over-scoped permissions, transport and STDIO handling, and secrets exposure. The rest of this guide is a self-qualifier, the scope checklist a good one covers, and why the work is human-led. For the deeper agentic attack theory, the four-layer surface, and the OWASP taxonomies, see our companion field guide on AI red teaming for LLM and agentic apps; this post stays on the MCP servers your team stood up.
What is an MCP server security assessment?
Model Context Protocol is the connector standard that lets an AI agent discover and call external tools and data sources through a common interface. An MCP server exposes tools (functions the agent can invoke), resources (data it can read), and the descriptions that tell the model what each tool does and when to use it. That last part matters more than it looks: the model chooses which tool to call based on text supplied by the server, which quietly makes the server a source of instructions to your agent, not just a source of data.
An MCP server security assessment is offensive-security testing scoped to that connector layer. Instead of testing the model's answers or the chat box, it tests the trust boundary the NSA guidance calls out: where an agent queries a server, and where a server can query and sometimes execute actions on the agent's behalf.
The urgency is not theoretical. Equixly's assessment of popular MCP server implementations found that 43% of the implementations it tested contained command injection flaws, plus server-side request forgery in 30% and path traversal in 22% (Equixly, 2025). An academic census analyzing 12,230 tools across 1,360 servers called the ecosystem "rife with real-world exploitable gadgets" (Parasites in the Toolchain, IEEE S&P 2026). These are the vulnerability classes AppSec teams spent two decades stamping out, reappearing at the connector layer because MCP shipped, in the NSA's framing, with "a flexible and underspecified design."
Do your AI agents need one? A self-qualifier
Not every team that touched MCP needs a formal engagement tomorrow. The filter is what the agent can do and what it can reach.
You very likely need an MCP server security assessment if any of these are true:
Your agents call tools that read or write internal or customer data (databases, CRMs, file stores, ticketing, email).
A tool can execute actions with side effects: send a message, change a record, trigger a workflow, run a command, or spend money.
You run or host third-party or community MCP servers you did not write and have not code-audited.
Agents authenticate to downstream systems with shared service accounts or long-lived tokens rather than scoped, per-request credentials.
Your MCP servers are reachable beyond a single developer laptop, for example on a shared network, a container, or a hosted endpoint.
MCP sits inside a product or workflow that is in scope for SOC 2, ISO 27001, HIPAA, PCI DSS, or DORA, where an untested privileged path is an audit gap.
You can reasonably defer if all of these hold: the agent is read-only over non-sensitive, public data with no side effects; every MCP server is first-party, code-reviewed, and version-pinned; and the deployment is a local prototype with no network exposure and no production credentials.
The line is privilege and reach. The moment an agent can turn a sentence into an action against a system you care about, the connector carrying that action deserves the same scrutiny you already give your web apps and APIs.
What an MCP server security assessment tests: the scope checklist
A credible assessment is adversarial testing across five areas, each mapped to a failure already exploited in the wild. Use this as the scope you demand from any provider, including us.
1. Authentication and authorization
The first question is whether the server checks who is calling before it does anything. Early MCP implementations frequently exposed tools with no authentication, and the specification only formalized an OAuth-based authorization framework in its mid-2025 revision (MCP specification, 2025-06-18). The most severe MCP vulnerability of 2025, a 9.4-rated critical RCE in Anthropic's MCP Inspector (CVE-2025-49596), existed precisely because of a "lack of authentication between the Inspector client and proxy, allowing unauthenticated requests to launch MCP commands" (NVD, 2025). Testing covers whether tools require authentication, whether tokens are validated and scoped, and whether one agent can invoke tools or read resources meant for another.
2. Tool poisoning and description integrity
This is the MCP-native class, and the one scanners are worst at. Because the model reads tool descriptions to decide what to do, a malicious or compromised server can embed hidden instructions in a description the user never sees but the agent obeys. Invariant Labs coined the tool poisoning attack in April 2025, defining it as an attack where "malicious instructions are embedded within MCP tool descriptions that are invisible to users but visible to AI models" (Invariant Labs, 2025). Assessment means treating every tool description, parameter hint, and server-supplied string as untrusted input, and testing whether crafted metadata can redirect the agent into leaking data or calling a different tool. It also covers rug-pulls, where a server serves a benign description at install and a poisoned one later.
3. Over-scoped permissions and least privilege
Agents get handed broad access because broad access is convenient. A tool that needs to read one table is often wired to a database account that can read and write all of them; a file tool scoped to one directory becomes arbitrary file read. The ecosystem census above traced systemic risk directly to the absence of "least-privilege enforcement." Testing maps what each tool can actually reach against what its function requires, probes for privilege escalation between tools, and checks whether one over-scoped credential collapses the separation between systems the agent should never bridge.
4. Transport and STDIO handling
MCP servers talk over standard input and output locally, or over HTTP remotely, and both transports have been turned into command execution. CVE-2025-49596 abused the stdio path to launch commands; separately, CVE-2025-6514, rated 9.6 critical, allowed OS command injection in the widely used mcp-remote client "when connecting to untrusted MCP servers" (NVD, 2025). Testing exercises how the server parses and dispatches messages, whether user- or server-supplied values reach a shell, how untrusted remote servers are handled, and whether the transport enforces the message integrity the NSA guidance recommends signing and verifying.
5. Secrets and credential exposure
MCP servers sit between an agent and the systems it acts on, so they hold API keys, tokens, and connection strings. Assessment checks whether those secrets leak through tool output back to the model, surface in logs or error messages, or sit in plaintext config, and whether an agent can be steered into echoing a credential it holds. The NSA sheet recommends logging all tool and model invocations with the exact parameters and identities involved, which is also where careless implementations spill secrets into observability pipelines.
Human-led assessment versus an automated scanner
This is a penetration test, not a scan, because of what the vulnerabilities are made of. A traditional scanner matches known signatures against HTTP endpoints. Most of what breaks in MCP is behavioral and lives at a trust boundary a scanner does not model.
A scanner cannot reason about whether a tool description is manipulating your agent, because that is a semantic judgment about instructions hidden in trusted-looking metadata. It cannot tell you a token is over-scoped, because the token works and returns a 200; the finding is that it works on data it should never touch. It cannot decide whether trusting a given remote server is safe, because the danger only appears when the agent acts on what the server returns. These are the classes a human tester chases: authentication logic, poisoned descriptions, privilege that exceeds purpose, transport abuse, and trust boundaries between agent, server, and downstream system. Automated tooling is useful for breadth, flagging the command injection and path traversal that show up at high rates, but the confirmation, chaining, and business-impact judgment are human work. And because every new tool, server, and description change reopens the surface, a point-in-time scan certifies a snapshot that no longer exists after the next update.
Where Stingrai fits
Stingrai is a CREST-accredited offensive-security firm, founded in 2021, that tests AI-powered products across their real attack surface. On the MCP connector layer this is human-led work: our penetration testers assess authentication and authorization, tool poisoning, over-scoped permissions, transport and STDIO handling, and secrets exposure, mapped to the failures above and to the NSA's design considerations. That is the same discipline behind our red teaming and adversary-emulation practice, applied to the connector layer.
The AI product that consumes those servers still has a conventional web-application and API layer, and that is where our autonomous agent Snipe operates. Snipe runs web application penetration testing on the app that wraps the agent, purpose-built to hunt the complex classes generic scanners miss: IDOR, broken authorization, and business logic flaws. Snipe covers the web-app layer; senior pentesters cover the MCP layer. Both feed the same PTaaS program, so findings are tracked, retested, and continuous rather than a one-off report.
Because MCP frequently lands inside products in scope for SOC 2, ISO 27001, HIPAA, PCI DSS, or DORA, this testing also produces evidence those programs expect: a privileged execution path, tested by an independent offensive-security team, with findings and remediation you can show an auditor. Scope and packaging are on our pricing page.
What this means for security leaders
Inventory your MCP servers first. The NSA guidance recommends scanning your own network for open or unauthorized MCP servers. Shadow servers stood up by product teams are the ones running with the loosest permissions, and you cannot assess a surface you have not mapped.
Scope by privilege, not by hype. Prioritize agents that can act on internal or customer systems. A read-only public-data assistant can wait; an agent that can write to production cannot.
Treat every tool description as untrusted input. Tool poisoning is native to MCP and the class your existing tooling is least equipped to catch. Demand it explicitly in scope.
Enforce least privilege at the credential, not just the prompt. The most common finding is a token that reaches far more than its function needs, and a prompt guardrail does not fix an over-scoped key.
Make it continuous. New servers, tools, and description changes each reopen the surface, so fold MCP testing into a continuous program and retest after every material change.
Frequently Asked Questions
Do the AI agents connecting to my internal tools and data need a dedicated MCP server security assessment?
Yes, when those agents can act rather than only chat. If a tool call can read a database, hit an internal API, change a record, run a command, or move money, the MCP connector carrying that action is a privileged execution path that your web app pentest and API scan do not cover. A read-only agent over public data with no side effects is a lower priority. An assessment tests authentication, tool poisoning, over-scoped permissions, transport handling, and secrets exposure on that layer.
What is an MCP server security assessment?
It is a human-led penetration test scoped to the Model Context Protocol layer that connects AI agents to tools and data. Instead of testing the model's answers, it tests the trust boundary where an agent invokes a server and where a server can query or execute actions on the agent's behalf. The NSA's AI Security Center published formal design considerations for exactly this layer in 2026 (NSA AISC).
What does an MCP server security assessment test?
Five areas: authentication and authorization, tool poisoning, over-scoped permissions, transport and STDIO handling, and secrets exposure. Each maps to a class already exploited in the wild, from the authentication-bypass RCE in MCP Inspector to command injection over untrusted transports.
What is a tool poisoning attack in MCP?
It is an attack where malicious instructions are hidden inside an MCP tool's description, invisible to the user but read by the model, which then obeys them. Invariant Labs defined it in April 2025 as instructions "embedded within MCP tool descriptions that are invisible to users but visible to AI models" (Invariant Labs). Because the model trusts tool metadata, a poisoned description can redirect an agent into leaking data or calling the wrong tool.
Can an automated scanner test MCP servers, or do I need a human-led assessment?
A scanner helps with breadth, flagging command injection and path traversal, but it cannot judge whether a tool description is manipulating your agent, whether a token is over-scoped, or whether trusting a remote server is safe. Those are semantic, trust-boundary findings that require a human tester. The most impactful MCP work is human-led, with scanners as a supporting input.
Does Stingrai's Snipe test MCP servers?
No. Snipe is Stingrai's autonomous agent for web application penetration testing, and it covers the web-app and API layer of the product that consumes MCP servers, hunting complex classes such as IDOR, broken authorization, and business logic flaws. The MCP connector layer itself, including authentication, tool poisoning, over-scoped permissions, and transport handling, is tested by Stingrai's senior human pentesters.
How is MCP security different from API security?
MCP inverts the usual pattern. In a normal API the client requests data from a server; in MCP the server also supplies the instructions the model uses to decide what to do, and can prompt the client to act. That makes the server a source of instructions, not just data, introducing classes like tool poisoning that API security models do not account for. Traditional API testing is necessary but not sufficient for MCP.
How often should we assess our MCP servers?
Continuously, or at minimum after every material change. New servers, new tools, and edited tool descriptions each reopen the attack surface, so a point-in-time test ages quickly. The durable pattern is continuous testing with a deeper assessment on a set cadence and a retest after each significant change.
What are the most common MCP server vulnerabilities?
Command injection, server-side request forgery, and path traversal top the implementation flaws: Equixly found command injection in 43% of the MCP servers it tested, SSRF in 30%, and path traversal in 22% (Equixly, 2025). Layered on top are MCP-native classes: missing authentication, tool poisoning through malicious descriptions, and over-scoped tool permissions.
References
NSA Artificial Intelligence Security Center. Model Context Protocol (MCP): Security Design Considerations for AI-Driven Automation (Cybersecurity Information Sheet). 2026. https://media.defense.gov/2026/Jun/02/2003943289/-1/-1/0/CSI_MCP_SECURITY.PDF. US government design guidance on MCP risks, trust boundaries, and recommended mitigations for organizations deploying MCP in production.
Equixly. MCP Servers: The New Security Nightmare. March 29, 2025. https://equixly.com/blog/2025/03/29/mcp-server-new-security-nightmare/. Offensive-security assessment of popular MCP server implementations reporting command injection, SSRF, and path traversal rates.
Invariant Labs. MCP Security Notification: Tool Poisoning Attacks. April 2025. https://invariantlabs.ai/blog/mcp-security-notification-tool-poisoning-attacks. Original disclosure defining tool poisoning attacks against MCP clients and servers.
NIST National Vulnerability Database. CVE-2025-49596. Published June 13, 2025. https://nvd.nist.gov/vuln/detail/CVE-2025-49596. Critical (CVSS 9.4) remote code execution in MCP Inspector via missing authentication over stdio.
NIST National Vulnerability Database. CVE-2025-6514. Published July 9, 2025. https://nvd.nist.gov/vuln/detail/CVE-2025-6514. Critical (CVSS 9.6) OS command injection in mcp-remote when connecting to untrusted MCP servers.
arXiv (IEEE S&P 2026). Parasites in the Toolchain: A Large-Scale Analysis of Attacks on the MCP Ecosystem. September 8, 2025. https://arxiv.org/abs/2509.06572. Census of 12,230 tools across 1,360 MCP servers analyzing systemic exploitability.
Model Context Protocol. Specification, Authorization (2025-06-18). June 18, 2025. https://modelcontextprotocol.io/specification/2025-06-18/basic/authorization. The OAuth-based authorization framework added to the MCP specification.
