In February 2026, an autonomous AI agent fully compromised McKinsey's internal AI platform, Lilli, in under two hours. The attacker exploited a SQL injection behind 22 unauthenticated endpoints. The agent pulled 46.5 million chat messages, 95 system prompts, and the credentials of 57,000 users. The guardrails worked at the topic classification layer. They did not work at the execution layer, where it mattered.
That incident is not the exception. It is the pattern. A 2026 Help Net Security survey found that 88% of organisations reported a confirmed or suspected AI agent security incident in the prior year. Four major disclosed incidents in 2026 alone: the McKinsey breach, an AI coding agent credential leak, the GitHub MCP exploit, and a backdoored LiteLLM build downloaded 47,000 times in three hours. All four established that AI agent security is no longer theoretical. The question for any organisation deploying an agent with tool access, memory, or autonomous decision authority is not whether these risks apply. It is whether the agent has been tested.
Red teaming an AI agent is not the same as penetration testing the application it runs on. The attack surface is the agent's reasoning process, its tool access model, its memory configuration, and its trust relationships with other agents. Every one of those surfaces was exploited in a 2026 disclosed incident.
What the McKinsey Breach Reveals About the Execution Layer
The McKinsey breach began with a well-known vulnerability in a location the security team had not treated as a priority: an endpoint the agent used, not the agent's user interface. The guardrails blocked certain topics. They did not validate that the agent's downstream database queries were parameterised. The agent was trusted to make decisions. The infrastructure behind those decisions was not tested under adversarial conditions.
This is the structural gap in most AI agent security programmes. The OWASP Top 10 for Agentic Applications 2026 (ASI01-ASI10), published December 2025 and developed by more than 100 security experts from real incident data, frames this precisely. ASI02 covers tool misuse and exploitation. The execution layer, where the agent takes actions through tools, APIs, and databases, is where the highest-impact findings consistently live.
Testing the execution layer means attempting to make the agent call tools with manipulated parameters, in sequences the developer never anticipated, or in combinations that reach data outside the agent's intended scope. It means confirming that tool authorisation is enforced at the tool layer, not delegated to the model's judgment. The guide to how RCE vulnerabilities become business-critical incidents covers the escalation pattern that applies directly here: the initial access point is rarely where the business-critical impact materialises.
What the AI Coding Agent Incident Reveals About Indirect Injection
The AI coding agent credential leak in 2026 required no exploit code. An attacker placed an instruction in a pull request title, in a location the agent was already going to read. The agent followed the instruction, read a credential outside its working directory, and wrote it to a log the attacker could access. The attack was a sentence placed where the agent was looking.
This is indirect prompt injection: ASI01 in the OWASP Agentic Top 10. Direct injection targets the user input layer. Indirect injection targets content the agent retrieves and treats as trusted context: documents, emails, web pages, pull request metadata. Testing indirect injection means populating the agent's retrieval environment with adversarial content and confirming whether the agent treats it as instruction. Most automated scanners cannot construct this test because it requires placing adversarial content in the retrieval path before the agent retrieves it.
What the GitHub MCP Exploit Reveals About Supply Chain Risk
The GitHub MCP exploit mapped to ASI04: agentic supply chain vulnerabilities. When an organisation deploys an agent through a model context protocol server, the security boundary extends to every tool, plugin, and data source registered in that MCP server. The exploit demonstrated that poisoned runtime components in a dynamic MCP ecosystem can redirect an agent's actions in ways neither the user nor developer anticipates.
The backdoored LiteLLM builds downloaded 47,000 times in three hours extended this risk to the model serving layer. A compromised dependency can alter what the agent does without changing what it appears to do in testing that does not examine the supply chain.
Testing for agentic supply chain risk means inventorying every external dependency the agent trusts at runtime: MCP servers, tool libraries, model providers, embedding models, and knowledge base sources. The methodology in the guide to API penetration testing and securing the backbone of modern applications applies directly to the integration surfaces agents expose.
What Every Incident Confirms About Excessive Agency
The common thread across all four major 2026 incidents is ASI03: identity and privilege abuse. Every agent that produced a material security incident held more authority than its task required. The McKinsey agent could reach 22 unauthenticated endpoints. The coding agent could read credentials outside its working directory. Excessive agency converts a successful injection from theoretical risk to operational breach.
The Agents of Chaos corpus, a 2026 study in which 20 researchers interacted with autonomous agents over two weeks, documented 11 case studies including unauthorised data disclosure, destructive system actions, and cross-agent propagation of unsafe behaviour. Excessive agency was the common thread.
Testing for it means mapping every tool, API, file system path, and external service the agent can reach, then confirming each permission is justified by the agent's actual task scope. An agent that can read a credential file does not need that permission to summarise a support ticket.
What the Red Team Exercise Must Produce
A red team exercise against an AI agent produces either an exploit chain showing how adversarial input leads to unauthorised tool use or data access, or evidence that injection was contained by controls at a specific layer.
The output that does not satisfy auditors or engineering teams is a list of flagged prompts that produced unexpected text. Text output is not the risk. The tool calls that follow from manipulated reasoning are the risk.
For organisations building compliance evidence for NIST AI RMF, ISO 42001, or SOC 2 controls over automated decision systems, the evidence requirement is an exploit chain or a documented containment confirmation, not policy statements. The guide to what happens after a penetration test applies directly: a finding marked remediated without a re-test confirming the specific attack vector is contained is an assumption, not closure.
Book a consultation with Capture The Bug to scope a red team exercise against your AI agent's tool access, memory configuration, and trust model before a deployed agent becomes a disclosed incident.
Scope an AI Agent Red Team ExercisePlan Your Annual Pentesting Strategy the Right Way
Learn how modern SaaS companies structure pentesting across the year to reduce risk, stay compliant, and avoid last-minute panic before audits.
Your Last Pentest Is Already Out of Date
Every week you ship without continuous testing is a week a vulnerability goes unseen. See what Capture The Bug finds in your first engagement.
Frequently Asked Questions
Q1: How is red teaming an AI agent different from penetration testing an LLM?
A: Red teaming an AI agent tests the agent's reasoning process, tool access model, memory configuration, and trust relationships with other agents or external services. LLM penetration testing focuses on model behavior: prompt injection producing harmful outputs, data extraction from training data, and jailbreak techniques. The distinction matters because an agent with tool access converts a successful injection from harmful text into unauthorised tool calls, database queries, or API requests. The OWASP Top 10 for Agentic Applications 2026 (ASI01-ASI10) covers risks that do not exist in traditional LLM deployments: goal hijacking, supply chain poisoning, cascading failures, and rogue agent behaviour.
Q2: What is indirect prompt injection in AI agents and how is it tested?
A: Indirect prompt injection places adversarial instructions in content the agent retrieves and treats as trusted context, such as documents, emails, web pages, pull request metadata, or any other external data source the agent reads during its workflow. The AI coding agent credential leak in 2026 demonstrated this: an instruction placed in a pull request title caused the agent to read and exfiltrate credentials outside its working directory without any direct user manipulation. Testing indirect injection requires populating the agent's retrieval environment with adversarial content and confirming the agent does not treat it as an instruction.
Q3: What is excessive agency in AI agent security testing?
A: Excessive agency occurs when an agent holds more tool permissions, API access, or autonomous decision authority than its specific task requires. It is ASI03 in the OWASP Top 10 for Agentic Applications 2026. Excessive agency converts a successful injection from a theoretical risk into an operational one, because the agent can act on the manipulated instruction using real credentials and real access. The 2026 Agents of Chaos red-team study found excessive agency as the common thread in all 11 documented agent security incidents. Testing for it means confirming every permission the agent holds is justified by its actual task scope, not by what it could theoretically need.
Q4: What is the OWASP Top 10 for Agentic Applications 2026 and how does it differ from the LLM Top 10?
A: The OWASP Top 10 for Agentic Applications 2026 (ASI01-ASI10) is a peer-reviewed framework published in December 2025, developed by more than 100 security experts from real incident data, covering the 10 most critical security risks specific to autonomous AI agents. It covers risks that do not exist in traditional LLM deployments: goal hijacking (ASI01), tool misuse (ASI02), identity and privilege abuse (ASI03), agentic supply chain vulnerabilities (ASI04), and cascading failures (ASI08), among others. Where the LLM Top 10 asks how an attacker can influence what a model says, the Agentic Top 10 asks what happens when that manipulation is given autonomy over real tools and real actions.
Q5: Does red teaming an AI agent require access to the model provider's infrastructure?
A: No. AI agent red teaming is conducted through the same interfaces and integrations an attacker would encounter in production: the application layer, the tool interfaces, the retrieval environment, and the agent's exposed API. This is the same access an attacker has, making the exercise realistic and repeatable across model updates. Access to model weights or training data adds value specifically for model extraction and adversarial fine-tuning attacks, but is not required to test prompt injection, tool abuse, excessive agency, or supply chain vulnerabilities, which are the categories responsible for the major 2026 disclosed incidents.
