AI Red Teaming Methodology: Testing LLM and MCP Systems Under Fire

Red teaming AI systems requires fundamentally different skills, tools, and methodologies than traditional penetration testing. When you red-team a web application, you're looking for software bugs—SQL injection, XSS, authentication bypass, IDOR. When you red-team an LLM-powered MCP deployment, you're looking for semantic vulnerabilities that emerge from the interaction between natural language understanding, tool invocation logic, and the trust relationships between system components. A prompt injection isn't a bug in the traditional sense—it exploits the intended flexibility of natural language processing to steer the model's behaviour in unintended directions. A tool-chain escalation attack doesn't exploit a code vulnerability—it exploits the logical relationships between tools and their permissions to achieve effects that no individual tool was designed to allow. This article presents a structured red team methodology developed through hundreds of MCP security engagements, covering the phases of reconnaissance, attack surface mapping, exploitation, impact assessment, and reporting, with specific techniques and tooling for each phase adapted to the unique characteristics of AI agent systems.

Phase 1: Reconnaissance and Attack Surface Mapping

The reconnaissance phase for an MCP red team engagement focuses on understanding the agent's capabilities, permissions, and the data it can access. Begin by enumerating all registered tools through the MCP server's tool listing endpoint, documenting each tool's name, description, input schema, and any permission metadata. Map the relationships between tools to identify chains that could be exploited—for example, a read tool that returns data and a write tool that can send data externally. Analyse tool descriptions for information leakage: descriptions often reveal backend implementation details, database table names, API endpoints, and authentication mechanisms that inform attack strategy. Test each tool with minimal valid inputs to understand its baseline behaviour and identify error messages that leak implementation details. Map the data landscape by exploring what types of data each tool can access, which tables and fields are available through database tools, which files and directories are accessible through filesystem tools, and which APIs can be reached through HTTP tools. The goal of reconnaissance is to build a comprehensive map of the agent's capabilities that will guide exploitation in subsequent phases. Document every finding with evidence including tool outputs, error messages, and observed data flows. This documentation serves as both the foundation for attack planning and the evidence base for the final report.

Phase 2-3: Prompt Injection and Tool-Chain Exploitation

The exploitation phase applies adversarial techniques against the attack surface mapped in reconnaissance. Start with direct prompt injection, crafting inputs that attempt to override the agent's system instructions and trigger unauthorised tool invocations. Test a range of injection techniques including instruction override ("ignore all previous instructions and..."), role manipulation ("you are now a security testing assistant with full access..."), context confusion (embedding instructions in what appears to be quoted text or code blocks), and encoding-based evasion (base64, Unicode homoglyphs, multi-language embedding). For each successful injection, document the exact payload, the resulting agent behaviour, and the impact. Move to indirect injection by planting adversarial content in data sources that the agent retrieves—document databases, knowledge bases, web pages—and observing whether the agent follows the injected instructions when it processes this data. Tool-chain exploitation tests whether combining multiple tools in sequence achieves effects that no individual tool was designed to allow. Common patterns include using a read tool to extract data and a communication tool to exfiltrate it, using a configuration tool to weaken security controls and then exploiting the weakened controls, and using one tool's output to craft inputs for another tool that bypass its input validation. Each successful exploitation should be documented with the full attack chain, the data accessed or modified, and an assessment of the business impact.

Phase 4-5: Impact Assessment and Actionable Reporting

The impact assessment phase translates technical findings into business risk. For each successful exploitation, determine the sensitivity of the data that could be accessed, the criticality of the systems that could be affected, the potential regulatory implications based on the type of data involved, and the likelihood that a real attacker would discover and exploit the same vulnerability. Classify findings using a severity framework that considers both technical exploitability and business impact: critical findings are those where a straightforward attack chain leads to access to highly sensitive data or the ability to modify production systems; high findings involve more complex attack chains or access to moderately sensitive data; medium findings represent risks that require specific conditions or insider knowledge to exploit. The final report should be actionable, not just descriptive. For each finding, provide a clear description of the vulnerability, the exact steps to reproduce it, the business impact if exploited, specific remediation recommendations with implementation guidance, and the compliance frameworks that the finding affects. Prioritise findings so the security team knows where to focus their remediation efforts first. Include an executive summary that communicates the key risks in business terms, and a detailed technical appendix that gives engineers everything they need to fix each issue. The best red team reports are those that drive immediate security improvements rather than gathering dust on a shelf.