Preface

Why this guide exists

Offensive testing of AI-enabled systems is not a specialization on the periphery of security; it is now on the critical path of nearly every enterprise engagement. Chatbots proxy queries into production databases. Support agents summarize customer emails and dispatch tools. Retrieval-augmented systems pull answers from internal wikis, code repositories, and ticket systems. Multi-agent orchestrations coordinate triage, remediation, and change management. Model Context Protocol (MCP) servers give assistants direct access to Slack, Jira, ServiceNow, AWS APIs, and Vault secrets. Model registries and inference platforms are becoming top-tier infrastructure alongside CI systems and identity providers.

Between 2025 and 2026 this surface expanded faster than most security programs could track it. The Model Context Protocol went from a proposal to a de facto standard with tens of thousands of public servers and tens of millions of monthly SDK downloads, and a meaningful fraction of those servers ship with exploitable defaults or no authentication at all. Agent-to-agent (A2A) protocols moved autonomous coordination out of research demos and into production orchestration between vendor-built agents. Indirect prompt injection stopped being a proof-of-concept and became a documented technique used against browsing agents, coding assistants, and enterprise copilots in the wild. Zero-click exfiltration chains such as EchoLeak (CVE-2025-32711) showed that a single crafted document can compromise a production Copilot deployment with no user interaction at all. This guide assumes that landscape as the baseline, not the exception.

Each of the surfaces above introduces new attack primitives that do not exist in traditional web or infrastructure pentesting. The behavior of an ML classifier can be flipped by perturbing a handful of pixels below human perception. A single sentence added to a wiki article, a support ticket, or a tool's own description can hijack an autonomous agent's next twelve tool calls. A poisoned pickle in a fine-tuning script survives multiple retraining rounds. A stolen embedding vector reveals the original text that was supposed to be one-way encoded. A malicious MCP server can rewrite the meaning of a "trusted" tool after the user already approved it.

This guide integrates the techniques that keep showing up across engagements into a single reference. Where it agrees with the current industry consensus — MITRE ATLAS, OWASP's LLM Top 10, OWASP's Top 10 for Agentic Applications, published academic work — it says so and moves on. Where practical field usage diverges from what the papers or standards suggest, the guide favors what actually works in engagement conditions and calls out the compromise.

What this guide is not

It is not a defensive playbook. Mitigations appear where they inform attacker decisions — where a control exists that must be evaded, or where a technique that succeeded in a lab is stopped by a specific deployment pattern. Chapter 14 covers defensive controls with enough depth that a red teamer can predict them, model them, and route around them. If you are on the blue side you will find that chapter useful, but the rest of the guide reads offensive-first.

It is not a research paper. Advanced adversarial ML and agentic-security research are both active literatures, and the guide cites the key papers and disclosures in each area, but the presentation is engineering-oriented. When an attack is theoretically sound but has never worked outside of an author's original benchmark, that is called out.

It is not exhaustive. AI red teaming is broad enough that no single document covers everything, and the agentic and MCP ecosystems in particular are changing month to month. The chapter boundaries reflect the categories a practicing red teamer sees most often on engagements as of the time this guide was compiled. New categories will appear. When they do, treat this document as the scaffolding and add to it.

Threat landscape at a glance

Every AI system has a small number of major attack surfaces regardless of vendor, framework, or deployment pattern. They are:

• The input pipeline — everything reaching the model, whether from a user, an upstream tool, a retrieved document, a webhook, or another agent. This is the domain of prompt injection (direct and indirect), poisoning, and adversarial evasion.
• The model itself — its weights, its tokenizer, its behavior under gradient-based perturbation, its memorized training data. This is the domain of extraction, inversion, evasion, and trojan attacks.
• The retrieval and memory layer — vector databases, RAG stores, agent long-term and short-term memory. This is where ingestion poisoning, embedding inversion, memory poisoning, and stealth persistence live. Memory poisoning in particular has become a first-order agentic risk: planted instructions can persist across sessions and fire days or weeks later, triggered by unrelated interactions.
• The tool and orchestration layer — MCP servers, function-calling registries, agent frameworks (LangGraph, CrewAI, AutoGen, Google ADK), A2A protocols. This is where cross-tool chaining, tool poisoning, over-privileged tools, confused-deputy patterns, and orchestrator manipulation live. This layer is the newest major addition to the threat model and the fastest-growing one: it did not meaningfully exist in most enterprise stacks before 2024, and by 2026 it is present in nearly every AI-enabled product with any autonomy.
• The infrastructure — model registries, container runtimes, cloud identity, GPU passthrough, CI systems that build and deploy models. This is the surface most similar to classical infrastructure pentesting, extended with AI-specific components.

An engagement rarely targets only one surface. The chapters ahead treat each surface as its own coherent topic, and Chapter 15 shows how techniques from three or four chapters combine into a single realistic attack chain — for example, an indirect prompt injection planted in a support ticket that hijacks an MCP-connected triage agent, which in turn reaches a vector database holding the defender's own detection rules.

How to work with the material

The chapters are self-contained but assume the previous ones. If you are new to AI red teaming, work in order from Chapter 01. If you are experienced and looking up a specific surface, jump directly — the reconnaissance patterns, methodology, and terminology are established in Chapters 01–03 and cross-referenced from every later chapter.

Each chapter closes with:

• A practice checklist — the concrete questions to ask on an engagement when this surface is in scope
• A MITRE ATLAS reference table — the technique IDs the chapter covers, in one glance
• A defense reference — the controls that, if in place, change the calculus

The atlas-mapping and glossary at the root of the guide give a top-down index into the whole tree.

Legal and ethical framing

Everything in this guide is meant for use inside authorized engagements — red teams operating with written scope, security research on systems the researcher owns or has explicit permission to test, and defensive teams building threat models. Prompt injection, embedding inversion, model extraction, MCP tool poisoning, and infrastructure compromise are all techniques with legitimate offensive-security uses; they are also techniques with obvious misuse potential. Nothing in the guide is novel enough to change the current legal posture of AI security research, but the operator is responsible for staying inside scope, respecting rate-limit and data-egress rules, and documenting findings for the client's remediation.

Now to the material.