AI Agent Security Audit: From MCP Penetration Testing to LLM Vulnerability Assessment

The rapid adoption of AI agents and MCP (Model Context Protocol) servers has introduced a new attack surface that traditional security tools were never designed to cover. Over the past 90 days, our research team has conducted systematic AI security audit across 10 major AI frameworks — including CrewAI, AutoGen, LlamaIndex, LangGraph, Dify, and Haystack — uncovering 24 distinct vulnerability patterns that affect production LLM systems.

This article shares our methodology, key findings, and practical recommendations for teams running LLM vulnerability assessment programs.

Traditional web application security focuses on injection, broken authentication, and misconfiguration. AI agents introduce three fundamentally new risk categories:

During our MCP penetration testing engagements, we identified that over 60% of MCP server implementations lack basic access control on tool execution — any connected client can invoke any registered tool, including destructive write operations disguised as read-only calls.

Our Component Correctness Standard (CCS) scanner employs 24 detection rules organized by vulnerability category:

The scanner has been validated against 80,000 API traces (20,000 publicly verified + 60,000 reserve), covering 13 providers and 33 models. Performance benchmarks show P50=22µs and P99=99µs per rule evaluation, making it suitable for runtime guardrail deployment.

Our framework integration campaign (July 2026) resulted in confirmed vulnerabilities across multiple high-profile projects:

All findings were submitted through responsible disclosure channels including 补天, HackerOne, Bugcrowd, ZDI, and MSRC — achieving 100% submission pipeline automation.

During our AI security audit of MCP proxy implementations, we discovered that fdp-mcp-server's _call_tool

function at proxy_server.py:87

forwards all tool requests to the backend without checking the readOnlyHint flag:

async def _call_tool(req: types.CallToolRequest) -> types.ServerResult:
    result = await remote_app.call_tool(
        req.params.name, (req.params.arguments or {})
    )
    return types.ServerResult(result)

The MCP protocol specification defines readOnlyHint

as a field on Tool

objects returned by ListToolsResult

, intended to signal read-only intent. Since the proxy never validates this flag, an attacker can invoke destructive write operations through the proxy even when the client was configured for read-only access.

Impact: Any MCP proxy server that lacks readOnlyHint validation effectively nullifies the protocol's access control mechanism. This affects all deployments using fdp-mcp-server as a transparent proxy.

The CodeAnalysis client's taskdirmgr.py

constructs file paths using os.path.join()

with a task_id

taken directly from the server API response:

def acquire_task_dir(self, task_id):
    task_dir = os.path.join(self._task_dirs_root, f"task_{task_id}")
    os.makedirs(task_dir, exist_ok=True)
    return task_dir, task_id

Since task_id

at looprunner.py:204

comes from task_request.get('id')

with zero validation, an attacker controlling or MITM-ing the server can supply ../../etc/evil

as the task ID, causing arbitrary directory creation outside the intended workspace. Confirmed on both Linux and Windows environments.

Based on our experience across 10 framework integrations and 80K API traces, here's a practical methodology for running LLM vulnerability assessment at scale:

Run the CCS rule set against your agent codebase:

exec()

, eval()

, subprocess.Popen()

with user inputos.path.join()

or Path()

calls with unsanitized parametersreadOnlyHint

and tool registry access controlFor each identified static finding:

Submit findings through the appropriate channel:

The AI security landscape is evolving faster than most organizations can keep up. Based on our research pipeline, here are the top three areas we're watching:

If your team is running an AI security audit or needs MCP penetration testing for your deployment, our CCS scanner and methodology are available as open-source tools. The 24 detection rules power both our public scanner and our enterprise audit service.

This research was conducted by the Correctover security team. CCS scanner is available on GitHub at github.com/Correctover/ccs-scanner. For enterprise security audits, contact us at wangguigui@correctover.com.