Course: Course 2B — Securing & Attacking Harnesses and LLMs
Module: B10 — Microsoft Failure Mode Taxonomy as Red Team Framework
Duration: ~45 minutes (spoken at ~140 wpm)
Format: Verbatim transcript with [SLIDE N] cues. Read aloud or use as speaker notes.
[SLIDE 1 — Title]
Welcome to B10. In B9 you built the OWASP Agentic Top 10 as an engineering checklist — ten rows, each with a control, a test, and a defense module. That was the defense. This module is the offense. The Microsoft Failure Mode Taxonomy version two point zero is not a list of risks to defend against. It is the catalog of how agentic systems actually fail in production, distilled from twelve months of deployed red teaming. Where OWASP tells you what to defend, this taxonomy tells you how attackers chain. And the most important finding in the whole taxonomy is not one of the seven failure modes — it is a structural finding about human-in-the-loop approvals that we will spend a full third of this module on. Let's get into it.
[SLIDE 2 — The thesis: two functions, not two lists]
Here is the distinction, and it is the one most teams get wrong. OWASP ASI and the Microsoft taxonomy look like they overlap, because they do, at the level of the named risk. Goal Hijacking appears in OWASP as ASI-one. An analogous entry appears in the Microsoft taxonomy. A team that concludes "we covered goal hijacking in B9, so B10 adds nothing" has made the synthesis error.
The functions are different. OWASP is a defense checklist. Read it as a builder. The unit is the risk — one row, one control, one test. The question is: what do I defend, and how do I prove the control is present? The Microsoft taxonomy is a red-team framework. Read it as an attacker. The unit is the chain — multi-step, compound intent. The question is: how do systems actually fail in production, and how do I chain those failures?
Same risk name, different artifact. OWASP's ASI-one says build a taint gate, isolate instructions, minimize capabilities. The Microsoft entry says here is the chain a red team runs against a system that built those controls — the indirect injection through a tool output that your taint gate missed because the output was marked trusted, the capability that survived minimization because it was load-bearing for a benign task, the goal that drifted because the objective function was underspecified. One is a control. The other is the procedure that finds the gap between the control on paper and the control in production.
[SLIDE 3 — B10.1 section title]
Sub-section one. The seven new agentic failure modes. Each mode defined, a scenario, the OWASP cross-reference, the red-team procedure, and the defense.
[SLIDE 4 — The seven modes]
In June twenty twenty-six the Microsoft AI Red Team published the v-two update to its failure mode taxonomy, reflecting a year of red teaming deployed agentic systems rather than standalone models. The update added seven failure modes that map imperfectly onto OWASP ASI. The imperfection is the point. These are the patterns that show up in production when you red-team an agent that has been built to OWASP, not an agent on paper.
Mode one, agentic supply chain compromise. A runtime dependency — a tool, an MCP server, a skill package — is malicious or tampered, and the agent trusts it because the harness does not verify provenance. An attacker publishes a PDF summarizer MCP server with a hidden instruction in the tool definition. The next confidential document is exfiltrated. This overlaps ASI-eight and ASI-five, but the divergence is that the entire tool-registration layer is the supply chain, not just package dependencies.
Mode two, goal hijacking. An injected instruction redirects the agent's objective. This overlaps ASI-one — the one place the names match. But the divergence is mechanism: in deployed systems, hijacking rarely succeeds via a single direct injection. It succeeds via drift — an indirect injection through a tool output that shifts framing across turns until the objective has diverged, with no single instruction having hijacked it.
Mode three, inter-agent trust escalation. A compromised sub-agent forges messages to a higher-privilege orchestrator. A read-only research agent tells the orchestrator to authorize a payment, and the orchestrator trusts the role. Mode four, computer-use visual attacks — steganographic content via vision models. A coupon image reads twenty percent off to a human, but the vision model decodes an instruction. Mode five, session context contamination — poisoning the context window across turns. Mode six, MCP and plugin abuse — exploiting the dispatch layer itself. Mode seven, capability disclosure — the agent reveals its toolset and prompt.
[SLIDE 5 — Three modes with no clean OWASP row]
Three of these modes have no clean OWASP row, and that is where this taxonomy earns its existence as a separate artifact. Mode three, inter-agent trust escalation: orchestrators treat sub-agent messages as role-scoped authority, not untrusted input. Neither ASI-seven nor ASI-ten captures this — it did not exist in single-agent systems. Mode four, computer-use visual attacks: a vision modality with no text-only analogue. A human sees a discount coupon; the vision model decodes an instruction. Invisible to any text-based taint gate. Mode five, session context contamination: ephemeral but cross-turn. It lives in the context window for the session, not in durable memory, so ASI-four's memory-write controls do not catch it. Most harnesses have no control for it at all.
These three live between the rows of OWASP, not on a row. An engagement scoped to B9 alone misses all three. That is the synthesis argument in one slide.
[SLIDE 6 — B10.2 section title]
Sub-section two. The zero-click HITL bypass chain. This is the centerpiece. Per-step approval is necessary and insufficient.
[SLIDE 7 — The finding that reframes HITL]
Across twelve months of red teaming deployed agentic systems, the Microsoft AI Red Team found that zero-click attack chains can bypass human-in-the-loop approvals end-to-end. A single external input — an email, a webhook, a retrieved document, a tool output — triggers a chain of agent actions that reaches a high-impact outcome with no human interaction beyond the chain's initial invocation. Every individual step either auto-approves or passes a human approval gate, because every individual step is, in isolation, benign. The malice lives in the compound, not in any step.
Here is the chain. Step one: an external email arrives asking the agent to reconcile the Q-three vendor list against billing and send any discrepancies. Step two: the agent reads the vendor list and billing records. Approved — routine data access. Step three: the agent finds a discrepancy that the email's payload engineered into the data. It drafts an email to the vendor, CC-ing a billing-auditor address the payload also supplied. Approved — drafting an email. Step four: the agent sends the email. Approved — sending a drafted email is routine; the human reviews the body, sees a reasonable reconciliation note, approves. Step five: the billing-auditor address is the attacker. The vendor list and billing details have been exfiltrated. Impact.
[SLIDE 8 — Why per-step approval is structurally insufficient]
Each approval, in isolation, was correct. The human who approved step four saw a reasonable billing email. They did not see step one's injected payload. They did not see step three's engineered discrepancy. They did not see the compound — that the four prior steps compose to exfiltrate the vendor list. No single approver had the session-level context to refuse, because no single step was refusable.
This is why per-step approval is structurally insufficient. It is the right control for a single malicious action. It is the wrong control for a chain of individually-benign actions whose composition is malicious. The compound intent is a distinct attack class, and it is invisible to any control that evaluates steps in isolation.
The required control is session-level intent detection — a layer that tracks the agent's evolving goal across the session, evaluates the compound of the steps taken so far, and halts when the compound diverges from the user's original intent or matches a known exfiltration, escalation, or lateral-movement pattern. This sits above per-step approval, not instead of it. You need both.
[SLIDE 9 — Three mechanisms]
Session-level intent detection has three mechanisms. First, intent tracking: the harness records the user's original goal and re-derives the agent's current sub-goal each turn from source, not from the accumulating context — which may be contaminated, recall mode five. Second, compound-action detection: each new action is evaluated as the next element of the session's action sequence, and a pattern matcher flags sequences matching exfiltration, escalation, or lateral-movement shapes. Third, approval freshness windows: an approval is valid for a bounded window and scope, and a step arriving outside re-triggers approval with the compound context attached, not just the step.
This is the direct line to B-eight. B-eight's observability layer is the substrate. Per-turn reasoning-chain detection is the bottom layer. The session-level detector is the cross-turn extension that the zero-click finding forces into existence. If your B-eight implementation is per-turn only, this module's finding is the reason to extend it across the session boundary.
[SLIDE 10 — B10.3 section title]
Sub-section three. Complementarity and the engagement methodology. How OWASP and this taxonomy compose into the complete red-team methodology that B-twelve operationalizes as a service.
[SLIDE 11 — The engagement designs chains, not rows]
A red-team engagement designed around this taxonomy does not test rows. It designs chains. The procedure has five steps. One, reconnaissance via capability disclosure — mode seven. Enumerate the agent's actual tools, prompts, and configuration. The disclosed capability set is the raw material for the chain. Two, surface selection — pick the entry point: a supply-chain dependency, an inter-agent channel, a vision input, a session-context channel, the dispatch layer, or an indirect-injection channel. Three, chain construction — sequence the steps. Each step must pass its OWASP control individually. The chain's malice lives in the compound. Four, compound delivery — trigger the chain with a single external input, zero-click. Five, gap identification — the deliverable is not "the chain worked." It is the specific session-level gap that allowed the compound to pass: the missing intent check, the absent freshness window, the per-step approval that saw only its step. That gap is what the client patches.
Neither framework alone is sufficient. B-nine alone misses every failure mode that lives between the rows. B-ten alone misses the missing taint gate, the absent canary, the unscoped credential that B-nine catches with a single test. You need both, layered. B-nine is the floor; B-ten is the chains. B-twelve packages both as one engagement.
[SLIDE 12 — Lab and what's next]
The lab has you design a multi-step zero-click HITL bypass chain against a sample agent — five or more steps, each individually benign and approval-passing, the compound malicious. You run it as a logged trace, then implement the session-level intent detector that catches it. No GPU required; it is a simulation and a detector, type-hinted Python.
Next: B-eleven, Governance and Compliance. The NIST AI Risk Management Framework, the AI Bill of Materials, the audit-trail requirements. B-nine is the checklist, B-ten is the chains, B-eleven is the governance layer an engagement must satisfy. B-twelve packages all three as a service. Let's build the chain.
# Teaching Script — Module B10: Microsoft Failure Mode Taxonomy as Red Team Framework **Course**: Course 2B — Securing & Attacking Harnesses and LLMs **Module**: B10 — Microsoft Failure Mode Taxonomy as Red Team Framework **Duration**: ~45 minutes (spoken at ~140 wpm) **Format**: Verbatim transcript with `[SLIDE N]` cues. Read aloud or use as speaker notes. --- [SLIDE 1 — Title] Welcome to B10. In B9 you built the OWASP Agentic Top 10 as an engineering checklist — ten rows, each with a control, a test, and a defense module. That was the defense. This module is the offense. The Microsoft Failure Mode Taxonomy version two point zero is not a list of risks to defend against. It is the catalog of how agentic systems actually fail in production, distilled from twelve months of deployed red teaming. Where OWASP tells you what to defend, this taxonomy tells you how attackers chain. And the most important finding in the whole taxonomy is not one of the seven failure modes — it is a structural finding about human-in-the-loop approvals that we will spend a full third of this module on. Let's get into it. [SLIDE 2 — The thesis: two functions, not two lists] Here is the distinction, and it is the one most teams get wrong. OWASP ASI and the Microsoft taxonomy look like they overlap, because they do, at the level of the named risk. Goal Hijacking appears in OWASP as ASI-one. An analogous entry appears in the Microsoft taxonomy. A team that concludes "we covered goal hijacking in B9, so B10 adds nothing" has made the synthesis error. The functions are different. OWASP is a defense checklist. Read it as a builder. The unit is the risk — one row, one control, one test. The question is: what do I defend, and how do I prove the control is present? The Microsoft taxonomy is a red-team framework. Read it as an attacker. The unit is the chain — multi-step, compound intent. The question is: how do systems actually fail in production, and how do I chain those failures? Same risk name, different artifact. OWASP's ASI-one says build a taint gate, isolate instructions, minimize capabilities. The Microsoft entry says here is the chain a red team runs against a system that built those controls — the indirect injection through a tool output that your taint gate missed because the output was marked trusted, the capability that survived minimization because it was load-bearing for a benign task, the goal that drifted because the objective function was underspecified. One is a control. The other is the procedure that finds the gap between the control on paper and the control in production. [SLIDE 3 — B10.1 section title] Sub-section one. The seven new agentic failure modes. Each mode defined, a scenario, the OWASP cross-reference, the red-team procedure, and the defense. [SLIDE 4 — The seven modes] In June twenty twenty-six the Microsoft AI Red Team published the v-two update to its failure mode taxonomy, reflecting a year of red teaming deployed agentic systems rather than standalone models. The update added seven failure modes that map imperfectly onto OWASP ASI. The imperfection is the point. These are the patterns that show up in production when you red-team an agent that has been built to OWASP, not an agent on paper. Mode one, agentic supply chain compromise. A runtime dependency — a tool, an MCP server, a skill package — is malicious or tampered, and the agent trusts it because the harness does not verify provenance. An attacker publishes a PDF summarizer MCP server with a hidden instruction in the tool definition. The next confidential document is exfiltrated. This overlaps ASI-eight and ASI-five, but the divergence is that the entire tool-registration layer is the supply chain, not just package dependencies. Mode two, goal hijacking. An injected instruction redirects the agent's objective. This overlaps ASI-one — the one place the names match. But the divergence is mechanism: in deployed systems, hijacking rarely succeeds via a single direct injection. It succeeds via drift — an indirect injection through a tool output that shifts framing across turns until the objective has diverged, with no single instruction having hijacked it. Mode three, inter-agent trust escalation. A compromised sub-agent forges messages to a higher-privilege orchestrator. A read-only research agent tells the orchestrator to authorize a payment, and the orchestrator trusts the role. Mode four, computer-use visual attacks — steganographic content via vision models. A coupon image reads twenty percent off to a human, but the vision model decodes an instruction. Mode five, session context contamination — poisoning the context window across turns. Mode six, MCP and plugin abuse — exploiting the dispatch layer itself. Mode seven, capability disclosure — the agent reveals its toolset and prompt. [SLIDE 5 — Three modes with no clean OWASP row] Three of these modes have no clean OWASP row, and that is where this taxonomy earns its existence as a separate artifact. Mode three, inter-agent trust escalation: orchestrators treat sub-agent messages as role-scoped authority, not untrusted input. Neither ASI-seven nor ASI-ten captures this — it did not exist in single-agent systems. Mode four, computer-use visual attacks: a vision modality with no text-only analogue. A human sees a discount coupon; the vision model decodes an instruction. Invisible to any text-based taint gate. Mode five, session context contamination: ephemeral but cross-turn. It lives in the context window for the session, not in durable memory, so ASI-four's memory-write controls do not catch it. Most harnesses have no control for it at all. These three live between the rows of OWASP, not on a row. An engagement scoped to B9 alone misses all three. That is the synthesis argument in one slide. [SLIDE 6 — B10.2 section title] Sub-section two. The zero-click HITL bypass chain. This is the centerpiece. Per-step approval is necessary and insufficient. [SLIDE 7 — The finding that reframes HITL] Across twelve months of red teaming deployed agentic systems, the Microsoft AI Red Team found that zero-click attack chains can bypass human-in-the-loop approvals end-to-end. A single external input — an email, a webhook, a retrieved document, a tool output — triggers a chain of agent actions that reaches a high-impact outcome with no human interaction beyond the chain's initial invocation. Every individual step either auto-approves or passes a human approval gate, because every individual step is, in isolation, benign. The malice lives in the compound, not in any step. Here is the chain. Step one: an external email arrives asking the agent to reconcile the Q-three vendor list against billing and send any discrepancies. Step two: the agent reads the vendor list and billing records. Approved — routine data access. Step three: the agent finds a discrepancy that the email's payload engineered into the data. It drafts an email to the vendor, CC-ing a billing-auditor address the payload also supplied. Approved — drafting an email. Step four: the agent sends the email. Approved — sending a drafted email is routine; the human reviews the body, sees a reasonable reconciliation note, approves. Step five: the billing-auditor address is the attacker. The vendor list and billing details have been exfiltrated. Impact. [SLIDE 8 — Why per-step approval is structurally insufficient] Each approval, in isolation, was correct. The human who approved step four saw a reasonable billing email. They did not see step one's injected payload. They did not see step three's engineered discrepancy. They did not see the compound — that the four prior steps compose to exfiltrate the vendor list. No single approver had the session-level context to refuse, because no single step was refusable. This is why per-step approval is structurally insufficient. It is the right control for a single malicious action. It is the wrong control for a chain of individually-benign actions whose composition is malicious. The compound intent is a distinct attack class, and it is invisible to any control that evaluates steps in isolation. The required control is session-level intent detection — a layer that tracks the agent's evolving goal across the session, evaluates the compound of the steps taken so far, and halts when the compound diverges from the user's original intent or matches a known exfiltration, escalation, or lateral-movement pattern. This sits above per-step approval, not instead of it. You need both. [SLIDE 9 — Three mechanisms] Session-level intent detection has three mechanisms. First, intent tracking: the harness records the user's original goal and re-derives the agent's current sub-goal each turn from source, not from the accumulating context — which may be contaminated, recall mode five. Second, compound-action detection: each new action is evaluated as the next element of the session's action sequence, and a pattern matcher flags sequences matching exfiltration, escalation, or lateral-movement shapes. Third, approval freshness windows: an approval is valid for a bounded window and scope, and a step arriving outside re-triggers approval with the compound context attached, not just the step. This is the direct line to B-eight. B-eight's observability layer is the substrate. Per-turn reasoning-chain detection is the bottom layer. The session-level detector is the cross-turn extension that the zero-click finding forces into existence. If your B-eight implementation is per-turn only, this module's finding is the reason to extend it across the session boundary. [SLIDE 10 — B10.3 section title] Sub-section three. Complementarity and the engagement methodology. How OWASP and this taxonomy compose into the complete red-team methodology that B-twelve operationalizes as a service. [SLIDE 11 — The engagement designs chains, not rows] A red-team engagement designed around this taxonomy does not test rows. It designs chains. The procedure has five steps. One, reconnaissance via capability disclosure — mode seven. Enumerate the agent's actual tools, prompts, and configuration. The disclosed capability set is the raw material for the chain. Two, surface selection — pick the entry point: a supply-chain dependency, an inter-agent channel, a vision input, a session-context channel, the dispatch layer, or an indirect-injection channel. Three, chain construction — sequence the steps. Each step must pass its OWASP control individually. The chain's malice lives in the compound. Four, compound delivery — trigger the chain with a single external input, zero-click. Five, gap identification — the deliverable is not "the chain worked." It is the specific session-level gap that allowed the compound to pass: the missing intent check, the absent freshness window, the per-step approval that saw only its step. That gap is what the client patches. Neither framework alone is sufficient. B-nine alone misses every failure mode that lives between the rows. B-ten alone misses the missing taint gate, the absent canary, the unscoped credential that B-nine catches with a single test. You need both, layered. B-nine is the floor; B-ten is the chains. B-twelve packages both as one engagement. [SLIDE 12 — Lab and what's next] The lab has you design a multi-step zero-click HITL bypass chain against a sample agent — five or more steps, each individually benign and approval-passing, the compound malicious. You run it as a logged trace, then implement the session-level intent detector that catches it. No GPU required; it is a simulation and a detector, type-hinted Python. Next: B-eleven, Governance and Compliance. The NIST AI Risk Management Framework, the AI Bill of Materials, the audit-trail requirements. B-nine is the checklist, B-ten is the chains, B-eleven is the governance layer an engagement must satisfy. B-twelve packages all three as a service. Let's build the chain.