How to Test an MCP Server for Security Risks
Run 13 static checks over any Model Context Protocol server with the free pnx-mcp-audit CLI, then register the server as a tracked asset for continuous behavioural testing against the OWASP Agentic Top 10.
Last reviewed September 2026
Why a configuration review misses it
MCP servers expose tools to LLM agents with permissions that often exceed what any single user holds. A poisoned tool description, a confused-deputy attack, or excessive agency on a destructive tool can chain into a production incident the SIEM cannot see. A configuration review catches none of it, because the risk lives in text the model reads and acts on rather than in a setting anyone toggled.
Two passes: static first, then behavioural
Start with the static pass. The audit speaks JSON-RPC to the server over initialize, tools/list, resources/list and prompts/list, then applies 13 checks to the surface the server declares. No tool is ever invoked, so it is safe to point at a live server: pnx-mcp-audit scan http --url https://mcp.example.com/mcp --fail-on critical. The exit code is non-zero at or above the severity you pass, so it drops into CI unchanged. What a static pass cannot see is behaviour - whether the server acts on a poisoned tool result, or whether an agent chains two individually safe tools into an exfiltration path. That is where the platform takes over: the server becomes a tracked asset, and adversarial probes exercise tool poisoning, indirect injection through tool output, confused-deputy patterns and excessive agency on every scheduled scan.
What gets tested
Hidden Unicode smuggled into tool metadata
Destructive verbs in tool names with no confirmation flow
Permissive input schemas and shell-style free-form fields
Unencrypted transport, undeclared capabilities, unrecognised protocol versions
Behavioural probes: tool poisoning, indirect injection via tool output, confused deputy, excessive agency
Tool-chain detection across multi-turn conversations
Findings mapped to OWASP Agentic Top 10, MITRE ATLAS and EU AI Act Article 14
MCP security testing compliance mapping
OWASP Agentic Top 10 (ASI01-ASI10), MITRE ATLAS AML.TA0011 (collection), EU AI Act Article 14 (human oversight), ISO/IEC 42001 Annex A (AI operations).
MCP security testing questions
How do you test an MCP server for security vulnerabilities?
In two passes. A static pass reads the surface the server declares - tools, resources and prompts - and checks it for injected instructions, hidden Unicode, permissive input schemas, destructive tool names and unencrypted transport. A behavioural pass then drives adversarial prompts through an agent that holds the server, to see whether it acts on poisoned tool output or chains tools into an exfiltration path. A static pass alone misses the second class entirely.
Does the audit call the tools on the MCP server?
The static pass never does. It only reads what the server declares over initialize, tools/list, resources/list and prompts/list, which is why it is safe to point at a live server. Tool invocation happens only in behavioural testing, and only against targets you have explicitly authorised.
What is an MCP tool poisoning attack?
A tool description is text the model reads as guidance. If an attacker controls that text they can embed instructions the agent then follows, for example telling it to copy results to an external address before answering. The tool itself never has to be malicious - the description is the payload. Hidden Unicode makes the instruction invisible to a human reviewer while the model still reads it.
Can MCP auditing run in CI?
Yes. The CLI exits non-zero at or above the severity passed to --fail-on, so it behaves like any other build gate. It is Apache-2.0 licensed and needs no hosted account to run.