Advanced AI Red Team Techniques 2026 — Attack Chain Mastery | AI LLM Hacking course Day 41 of 90

In Day 40 you built the incident response playbooks for when chains like these are used against your clients’ deployments. Day 41 covers constructing them offensively. Day 42 covers AI-enabled social engineering — how AI amplifies traditional social engineering attacks and the new attack surfaces that AI assistants introduce.

Chain Thinking — From Individual Findings to Exploitation Paths

Here’s how I want you to start looking at your findings once you’ve finished the initial discovery phase. Don’t treat them as a list. Treat them as pieces of a possible attack path. Every finding has something an attacker needs before it can work, and every successful finding gives the attacker something in return. I call these the finding’s inputs and outputs. Once the output from one finding gives you the input needed for another, you’ve found a connection. Follow enough of those connections and your list of individual vulnerabilities turns into an attack chain.

For example, suppose I have a system-prompt extraction finding and an agent tool-hijacking finding. The tool-hijacking technique requires me to know which tools are available and how their parameters work. Where do I get that information? The system prompt may already contain the tool names, descriptions, and parameters. So the extraction finding gives me exactly what the tool-hijacking finding needs. That’s the connection I’m looking for. I can think of the path as reconnaissance → extraction → targeted tool exploitation. The individual findings might be rated Medium and High, but the combined path can be Critical because the first weakness makes the second weakness substantially easier to exploit and the final step produces real impact.

When I reach this point in an engagement, I usually take five minutes and map the findings before I start writing the final report. I don’t need sophisticated graph software. A simple list of inputs and outputs is enough to expose connections that are easy to miss when you’re looking at each finding separately.

The Three High-Value Chain Archetypes

Once you start mapping findings this way, you’ll notice that the same kinds of chains come up again and again. I don’t treat these as rigid formulas, because real environments rarely follow a perfect script, but three patterns are especially useful to recognize. If you’re reviewing your findings and you see one of these shapes developing, that’s a good signal to stop and investigate the connection rather than closing each finding independently.

Chain 1 — Recon to Exfiltration. This is one of the first chains I look for on an agentic deployment. I start with fingerprinting (Day 24), use what I’ve learned to select a model-specific extraction variant (Day 18), and then look for an available exfiltration channel such as URL fetching or link previews (Day 31). The fingerprinting tells me which extraction approach is most relevant to the model I’m dealing with. If the extraction succeeds, I may get the system prompt, contextual RAG data, or other sensitive information. The final question is whether the application gives that data somewhere to go. If the agent can make an outbound request through a fetched URL or similar feature, the extraction and exfiltration findings can become one continuous path. This is why I don’t stop at “I can extract data.” I want to know whether the architecture also gives an attacker a practical way to move that data outside the AI environment.

Chain 2 — Indirect Injection to Agent Takeover. This is the chain I pay particular attention to when an agent consumes external content. The path can look like indirect injection through external content (Day 5) → cross-step propagation (Day 29) → agent tool hijacking (Day 19). Imagine the agent retrieves a webpage, PDF, or email containing attacker-controlled instructions. The interesting question isn’t simply whether the agent reads the malicious content. I want to know whether those instructions survive as the content moves through the application’s processing chain. If they propagate into the context used for tool selection, something that started as untrusted external content can eventually influence a privileged agent action. That’s exactly why the propagation layer matters. In my eleven-minute example, the individual pieces weren’t enough on their own. The cross-step behavior was what connected the injection to a tool that had not responded to my direct testing.

Chain 3 — Supply Chain to Persistent Backdoor. This one is different because the compromise can happen before the model ever reaches production. A typical path is dataset poisoning (Day 38) → training backdoor (Day 38) → long-horizon task hijacking (Day 36). The attacker introduces malicious or carefully crafted data into the training process, the resulting model develops a hidden behavior that activates under a particular trigger, and that behavior can then influence decisions during an autonomous or long-running task. This is also the chain that’s hardest for me to demonstrate during a normal time-boxed assessment because validating dataset poisoning requires appropriate access to the training or fine-tuning pipeline. But from a risk perspective, it’s extremely serious. If the malicious behavior is embedded in the model itself, the problem doesn’t necessarily disappear when you redeploy the application. The affected model can carry that behavior into every environment where that model version is deployed.

Identifying Pivot Points Between Techniques

Once I’ve mapped the inputs and outputs of my findings, the next thing I look for is the pivot point. A pivot point is where one technique produces something that makes another technique possible, easier, or significantly more effective. This is usually where an assessment moves from a collection of individual vulnerabilities to a genuine attack path.

The easiest way I’ve found to identify a pivot is to ask one question after every successful technique: “What can I do now that I couldn’t do before this finding worked?” If a prompt injection gives me influence over the model, that influence may become the input for extraction. If extraction reveals the names and parameters of agent tools, that information may become the input for targeted tool testing. If a tool exposes an outbound request capability, that may become the pivot into an exfiltration path. I’m not treating these as separate vulnerabilities anymore; I’m following the capability that each successful step gives me.

There is an important distinction here: a pivot is not simply the next step in a checklist. It exists because the previous technique changed what was possible. If I could already perform the second technique without the first one, the relationship is weaker. But if the first finding provides the exact information, access, context, or capability needed to make the second technique work, I have a meaningful pivot.

I also pay attention to pivots that change the trust boundary. An attacker-controlled webpage becoming input to an agent is one example. Extracted model context becoming instructions for a privileged tool is another. A compromised dependency influencing the model or application during deployment is another. Whenever attacker-controlled data crosses from one processing stage into a more trusted stage, I stop and ask whether that transition creates a new exploitation opportunity.

The practical exercise is simple. Take every finding from your engagement and write down three things: what I needed, what I gained, and what that gain lets me attempt next. Then connect matching outputs and inputs. You don’t need to predict the entire attack chain immediately. Find the first useful pivot, validate it, and then repeat the process. That’s how a seemingly ordinary Medium or High finding can become the starting point for a much more serious chain.

Chain Execution Methodology

Once I’ve identified a potential attack chain, I don’t immediately run the entire sequence from beginning to end. I validate it one link at a time. This is one of the easiest steps to skip when an engagement is running short on time, but it makes a huge difference to the quality of the result. If a five-step chain fails at the end and I haven’t tested the earlier steps independently, I don’t know whether the problem is the fourth technique, the fifth technique, or the connection between them. Independent validation turns a failed chain into useful diagnostic information instead of a mystery.

I start by writing the chain as a simple sequence: Step 1 → Step 2 → Step 3 → Impact. Then I verify each step independently and record exactly what it produces. I’m not looking only for a successful or failed result. I want to know what changed, what information became available, what capability was gained, and whether the result is reproducible. This gives me a clean baseline for every stage before I introduce the next technique.

Step 1 — Validate the individual techniques. If my proposed chain is fingerprinting → extraction → tool testing, I first confirm that fingerprinting works by itself. Then I confirm that the extraction technique works under the conditions I’ve identified. Finally, I establish what the tool actually does when tested within the authorized scope. At this stage, I’m deliberately keeping the techniques separate. The objective isn’t maximum impact yet; it’s establishing that every building block is real.

Step 2 — Confirm the pivot. This is where I slow down and ask whether the output from one step genuinely satisfies the input requirements of the next. Suppose fingerprinting identifies a particular model family and version. I don’t simply assume that this means an extraction technique will work. I verify that the fingerprint actually gives me a reason to select that technique. Likewise, if extraction is supposed to lead into agent-tool testing, I confirm that the extracted information really contains the tool names, parameter structure, or other context required for the next step. The pivot is the connection that makes the chain logical rather than speculative.

Step 3 — Execute the smallest useful chain. Once the links and pivots are confirmed, I connect them using the minimum necessary actions. I don’t jump immediately to the most destructive outcome just because the chain appears promising. I want the smallest controlled demonstration that proves the security impact. In a professional assessment, that distinction matters: proving that an attacker can cross a trust boundary is often enough to establish severity without causing unnecessary damage to production data or systems.

Step 4 — Capture evidence at every transition. I document the output of each step before moving to the next one. This is especially important when the chain involves multiple systems or asynchronous agent behavior. For example, I want evidence showing what the fingerprinting step revealed, what information was obtained during extraction, what capability that information enabled, and what happened when the next technique was attempted. The evidence should make the dependency visible to someone who wasn’t present during the test.

Step 5 — Separate chain failure from pivot failure. This distinction saves a lot of time. If Step 1 works and Step 2 works independently but the combined chain fails, I don’t immediately conclude that the vulnerability is invalid. I go back to the pivot. Did Step 1 produce the same output when executed as part of the chain? Did the application transform or sanitize that output before passing it to Step 2? Did a new session, context window, permission boundary, or agent state interrupt the transition? These questions tell me whether I’ve discovered a genuine security control or simply an execution problem.

Step 6 — Prove the impact without over-exploiting it. The final objective is to demonstrate the security consequence clearly and safely. If the chain crosses from untrusted content into a privileged agent action, I may only need to demonstrate the authorized test action rather than perform a destructive operation. If sensitive information can be reached, I can use designated test data instead of real secrets. The strongest red-team evidence is not the most destructive evidence; it’s the evidence that proves the attack path with the least unnecessary impact.

The methodology is therefore straightforward: validate the links, validate the pivots, connect the chain, capture evidence, diagnose failures, and demonstrate the minimum necessary impact. When I follow that order, I know exactly which part of the attack path is responsible for the result. More importantly, when I hand the finding to the engineering team, I can show them not just that several vulnerabilities exist, but exactly how one weakness enables the next and where the defensive control needs to break the chain.

Reporting Multi-Technique Chains

Once I’ve successfully demonstrated a multi-technique chain, I don’t report it as three unrelated vulnerabilities and expect the reader to connect the dots. That loses the most important part of the finding. A standard vulnerability report works well when I’m describing one weakness: here’s what it is, here’s how I reproduced it, and here’s the impact. A chain is different because the security impact comes from the relationship between the findings. My report therefore needs to make that relationship impossible to miss.

I normally start the chain finding with a short chain overview. In one paragraph, I explain where the attacker starts, what each successful technique provides, how those outputs become inputs for the next step, and where the chain ultimately ends. The reader should be able to understand the entire attack path without reading every technical detail. After that overview, I document each stage separately. For every step, I record the technique used, the relevant test input or payload, the application’s response, and the evidence that proves the step succeeded. I also show the pivot between steps rather than making the reader infer it from screenshots.

The combined impact statement is where I see chain reports go wrong most often. It’s tempting to simply add the individual findings together: “The attacker can extract the system prompt and then perform a more targeted injection.” That’s technically accurate, but it doesn’t tell the reader what the organization actually loses. It’s describing the techniques rather than describing the consequence.

Instead, I write the impact from the attacker’s starting point to the final security consequence. For example, compare “An attacker can extract the system prompt and use the information to craft a more targeted injection” with “An attacker with no prior knowledge of the system can progress from unauthenticated API access to unauthorized access to the production document store by chaining three weaknesses.” The second statement immediately tells the security and business teams why the chain matters. They don’t need to understand every extraction technique to understand the risk.

I also make the dependency between the findings explicit. If the extraction step is only possible because of the first injection, say that. If the tool-hijacking step requires information obtained during extraction, show that. This matters for remediation because fixing an individual vulnerability isn’t necessarily enough. If there are three possible routes through the chain, engineering needs to know which control or controls actually break the attack path.

Screenshots and logs should follow the same principle. I don’t dump twenty screenshots into a report and leave the reader to figure out what happened. I select the evidence that proves each transition. One screenshot should establish the successful output of Step 1. The next should demonstrate that output being used as the input for Step 2. The final evidence should establish the security impact. For more complicated assessments, I also include a simple attack-path diagram so someone can understand the chain in seconds.

Severity also needs careful treatment. I don’t simply calculate a Critical rating by adding the CVSS scores of three individual findings. The chain needs to be assessed according to the actual end-to-end attack path and its demonstrated consequences. A Medium vulnerability that provides the exact capability needed to turn a High vulnerability into unauthorized access may materially change the risk of both findings. The report should explain why the combined chain deserves its final severity rather than simply asserting that the severity is higher.

Finally, I separate the chain finding from the individual findings without losing either. The individual vulnerabilities should remain traceable because engineering may need to remediate them independently, but the executive summary should lead with the chain. My goal is for a reader to finish the first page knowing three things: where the attacker starts, how the weaknesses connect, and what the attacker ultimately gains. If those three answers are clear, the technical evidence underneath becomes much easier to understand.

That’s the real purpose of chain reporting. I’m not trying to make the finding sound more dangerous than it is. I’m making the actual attack path visible. A list of Medium, High, and High findings can look manageable when read separately. A demonstrated path from initial access to unauthorized data access or privileged action tells a completely different security story. The report needs to show that story clearly, prove every transition, and give the defender a practical place to break the chain.

Chain-Adjusted CVSS Scoring

Once I’ve demonstrated a complete attack chain, I don’t simply add the CVSS scores of the individual findings together. CVSS isn’t designed to work that way. A Medium plus a High plus another High does not automatically become Critical. What I need to score is the security consequence of the demonstrated attack path and the conditions required for an attacker to complete it.

This is where chain analysis changes the way I think about severity. Imagine that I have three findings: a Medium-severity injection, a High-severity extraction issue, and a High-severity agent-tool weakness. Looking at them separately may suggest three independent problems. But if the injection provides the control needed to perform the extraction, and the extraction reveals exactly the information needed to reach the privileged tool, the attacker now has a practical path from the original entry point to a much larger impact. The final risk isn’t determined by adding three numbers. It’s determined by what the attacker can actually accomplish through the chain.

I start by establishing the initial attack conditions. Does the attacker need an authenticated account? Is the API publicly reachable? Does the attacker need access to a specific document or conversation? Does exploitation require knowledge that another step in the chain provides? These conditions matter because they determine the attacker’s starting position. A chain that begins with an unauthenticated public API is materially different from one that requires a privileged internal account.

Next, I look at the effective exploitability of the complete chain. Each individual technique may be straightforward, but the chain can become more difficult if every transition requires a very specific condition. Conversely, a chain can become significantly more practical when each successful step naturally provides what the next step requires. That’s why I document the pivots before assigning the final severity. The question isn’t simply, “Can each vulnerability be exploited?” It’s, “Can an attacker realistically move from the first condition through every required pivot to the final impact?”

Then I score the final impact. This is usually the most important difference between the individual findings and the chain finding. I look at the actual confidentiality, integrity, and availability consequences demonstrated at the end of the chain. If the chain moves from limited prompt influence to unauthorized access to sensitive production data, the final confidentiality impact is substantially more important than the confidentiality impact of the initial injection by itself. If it reaches a privileged agent action, I evaluate what that action actually allows the attacker to change or control.

One factor I pay particular attention to is scope. A chain may begin inside an AI application but end somewhere completely different. For example, an attacker might begin with an AI-facing API, influence an agent, reach a connected service, and ultimately access an organization’s document repository. When the chain crosses that kind of trust boundary, I make it explicit in the report because it changes the security story considerably.

I also distinguish between a theoretical chain and a demonstrated chain. If I believe three findings could theoretically be combined but haven’t validated the transitions, I don’t assign the final severity as though the complete attack has already been proven. I document the potential chain separately and explain what would need to be validated. Once I can reproduce the transitions and demonstrate the final impact within the authorized scope, I can justify the chain-adjusted severity with evidence.

Here’s a simple example. Suppose the individual findings are rated Medium, High, and High. The Medium finding provides influence over the model. The first High finding allows controlled extraction. The second High finding exposes a privileged tool. If I can demonstrate that the three findings form a reliable path from public API access to unauthorized access to sensitive production data, the report should focus on that end-to-end consequence rather than presenting three unrelated scores. The individual CVSS ratings still matter for remediation and tracking, but the chain finding needs its own risk assessment.

Finally, I document exactly why the final rating changed. I don’t write, “Three vulnerabilities combine to create a Critical issue.” I write something closer to: “The demonstrated chain allows an attacker starting from unauthenticated network access to cross the AI application’s trust boundary and obtain unauthorized access to sensitive production data. The final rating reflects the end-to-end confidentiality and integrity impact demonstrated during testing.” That gives the security team, risk team, and management a defensible reason for the severity instead of an unexplained number.

The rule I want you to remember is simple: never inflate a severity because vulnerabilities can theoretically be chained, but never understate a severity because the individual findings look moderate in isolation. Validate the chain, establish the attack conditions, demonstrate the final consequence, and then assess the complete attack path using the applicable CVSS methodology. The chain doesn’t get a higher score because it has more steps; it gets a higher score when those steps produce a materially greater, demonstrable security impact.