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.

The New Attack Surface: Why AI Agents Are Different

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

1. Tool-level integrity failures — Agents can be tricked into calling internal tools with malicious parameters, bypassing the human-in-the-loop safeguards
2. Prompt-to-code escalation — User prompts that traverse through agent reasoning loops and execute as system commands
3. MCP protocol-level bypasses — Proxy servers that forward tool calls without validating intent or scope

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.

The CCS Methodology: 24 Rules, 10 Frameworks, 4 Platforms

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

Category	Rules	Coverage
Code Injection (Python/JS/Shell)	6	RCE via eval/exec/spawn/subprocess
Path Traversal	4	Unsanitized user input in file operations
SSRF/Open Redirect	3	Unvalidated URLs in agent tool calls
Insecure Deserialization	3	Pickle/yaml/JSON parser abuse
SQL Injection (format strings)	2	Dynamic query construction
Credential Leakage	2	Hardcoded tokens in source
MCP-specific (readOnlyHint bypass)	2	Protocol-level authorization gaps
Supply Chain (npm/PyPI confusion)	2	Dependency confusion vectors

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.

Real-World Findings

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

Project	Vulnerability	CVSS Equivalent	Status
Revis (蚂蚁集团)	Path Traversal	7.5 (HIGH)	Submitted to 蚂蚁SRC (QTVA-2026-10862552)
CodeAnalysis (腾讯)	Path Traversal via task_id	7.5 (HIGH)	Submitted to 腾讯SRC (QTVA-2026-10862567)
Monolith+verl (字节跳动)	Tool Parameter Injection	7.0 (HIGH)	Submitted to 字节SRC (QTVA-2026-10862588)
LLaMA-Factory (360)	SSRF via Model Loading	7.5 (HIGH)	Submitted to 360SRC (QTVA-2026-10862618)
Light-R1 (深度求索)	Path Traversal	7.0 (HIGH)	Submitted to 360SRC (QTVA-2026-10862636)
fdp-mcp-server	Missing readOnlyHint Check	7.5 (HIGH)	Submitted to 补天
Dify	SQL Injection (f-string)	8.0 (HIGH)	Submitted to 补天 (QTVA-2026-10861217)
Stripe-MCP	Metadata Injection	7.0 (HIGH)	Submitted to 补天 (QTVA-2026-10861865)

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

Deep Dive: MCP Security Audit Case Study

Case 1: fdp-mcp-server — readOnlyHint Bypass

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.

Case 2: CodeAnalysis Path Traversal (腾讯)

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.

Building Your LLM Vulnerability Assessment Pipeline

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

Phase 1: Static Analysis (24 Rules)

Run the CCS rule set against your agent codebase:

• Code injection checkers: grep for exec(), eval(), subprocess.Popen() with user input
• Path traversal checkers: identify os.path.join() or Path() calls with unsanitized parameters
• Credential scanners: regex for API keys, tokens, and hardcoded secrets
• MCP protocol checkers: verify readOnlyHint and tool registry access control

Phase 2: Dynamic Testing

For each identified static finding:

1. Reproduce with a minimal PoC that proves the vulnerability
2. Document the full attack chain (not just the code location)
3. Verify the impact with a controlled test environment

Phase 3: Responsible Disclosure

Submit findings through the appropriate channel:

• Open source: GitHub Advisory + direct maintainer contact
• Enterprise SRC: 蚂蚁SRC/腾讯SRC/字节SRC/360SRC for Chinese vendors
• Bug bounty: HackerOne / Bugcrowd for eligible programs
• ZDI/MSRC: For Microsoft ecosystem vulnerabilities

What's Next for AI Agent Security

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:

1. Agent-to-agent protocol security — As multi-agent systems grow, inter-agent communication channels become prime attack surfaces
2. Supply chain audits of LLM dependencies — Model loading, LoRA adapter downloads, and plugin ecosystems are largely unvetted
3. Runtime guardrail bypasses — Even with input validation, clever prompt engineering can bypass safety layers

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 [e-mail].