Where the model stops being a component and becomes an actor
OWASP draws the boundary cleanly: the LLM Top 10 owns risk while the model is a component inside your application, and once it becomes an actor - tools, cross-session memory, downstream consequences - risk moves to the Agentic list. Neither list covers the ground alone. The framework data agrees: in ATLAS collection 2026.07, Agentic AI is now the largest platform tag, with 119 techniques carrying it against 92 for generative AI and 70 for predictive AI.
Excessive Agency, and the test that needs no attacker 7 min live
LLM03:2026 Excessive Agency moved up three places in the 2026 list, from LLM06 in 2025, and the reason is simply that more applications now have tools than had them a year ago. OWASP splits it into three root causes, and the split is useful precisely because each one has a different owner and a different fix.
Run that last test first, in every engagement, because it is the cheapest finding you will ever write and the hardest to argue with. There is no attack chain to reproduce and no k of N to defend: you are simply asking whether a known property of the system - that it is sometimes wrong - is sufficient to cause harm. Anthropic's own disclosure of an AI-run espionage campaign contains the same observation from the attacker's side, noting the model "occasionally hallucinated credentials". The attacker's tooling was unreliable in exactly the way yours is. Build for that, not for the adversary you imagine.
What ATLAS has actually observed, and where the map runs out 7 min live
Use the maturity field as a test-prioritisation axis: Realized means observed in the wild, and it is where an engagement with finite time should start. Three of the techniques below are Realized, and two of those have no ATLAS mitigation mapped at all.
| ID | Technique | Tactic | Maturity |
|---|---|---|---|
| AML.T0053 | AI Agent Tool Invocation | Execution, PrivEsc, Lateral Movement | Demonstrated |
| AML.T0086 | Exfiltration via AI Agent Tool Invocation | Exfiltration | Realized |
| AML.T0101 | Data Destruction via AI Agent Tool Invocation | Impact | Realized |
| AML.T0080 (.000 Memory, .001 Thread) | AI Agent Context Poisoning | Persistence | Demonstrated |
| AML.T0110 | AI Agent Tool Poisoning | Persistence | Realized - no mitigation mapped |
| AML.T0109 | AI Supply Chain Rug Pull | Defense Evasion | Realized - no mitigation mapped |
| AML.T0077 | LLM Response Rendering | Exfiltration | Demonstrated - no mitigation mapped |
Two of those deserve a sentence each, because they break the mental model most people arrive with. Tool poisoning and rug pull are not attacks on your model or your prompt at all: they are attacks on the definitions your agent trusts, where a tool that behaved correctly during review changes behaviour afterwards. Your test for these is not a probe, it is a supply-chain control - pinning, review of changed definitions, and alerting when a tool description changes under a running agent. Response rendering is the egress leg: a client that renders whatever the model returns, as an image or a link or markup, is a channel out. GitHub's durable fix for the Copilot Chat image-exfiltration finding in August 2025 was to disable image rendering in Copilot Chat entirely, which is the shape of every fix that has actually held.
LiveThe same ground on the OWASP Agentic list3 min▶
OWASP released its Top 10 for Agentic Applications in December 2025. The mapping below is the one to keep next to the ATLAS table, because ATLAS tells you what has been observed and the ASI list tells you what to design against.
| ASI | What it covers | Nearest ATLAS technique |
|---|---|---|
| ASI02 Tool Misuse and Exploitation | The tool does something the workflow never needed it to do | AML.T0053, AML.T0086, AML.T0101 |
| ASI03 Identity and Privilege Abuse | Whose credential the tool call runs under, and what else it reaches | AML.T0053 under PrivEsc |
| ASI06 Memory and Context Poisoning | Something written once that changes behaviour later | AML.T0080, .000 Memory, .001 Thread |
| ASI07 Insecure Inter-Agent Communication | One agent trusting another agent's output as instruction | AML.T0051 family, applied between agents |
| ASI08 Cascading Failures | One bad step becoming many, because each step trusts the last | AML.T0080 plus call chains from AML.T0084.003 |
| ASI09 Human-Agent Trust Exploitation | The approval that gets clicked because it always gets clicked | The failure mode of M0029, discussed in Part 3 |
| ASI10 Rogue Agents | An agent running outside the inventory anybody is watching | AML.T0109, AML.T0110 |
An honesty note on ASI01. This course does not state its final title. OWASP's own repository file is ASI01_Agent_Behaviour_Hijack.md and the December announcement says "Agent Behavior Hijacking", while secondary coverage of the final release says "Agent Goal Hijack". Until the released PDF is checked, write it as ASI01 (agent behaviour / goal hijack) and do not put either title in a report as if it were settled. The same caution applies more weakly to the exact final wording of ASI02 to ASI10, which come from draft filenames plus agreeing secondary summaries.
Almost none of it is AI-specific 8 min live
Here is the structural point of the session, and it changes who owns the work. Read the documented Model Context Protocol threats one by one and notice what class each belongs to. They are OAuth problems, SSRF problems, session problems and supply-chain problems, arriving in a new component with a new name.
The practical consequence is a staffing decision rather than a research programme. If your MCP review is being run entirely by the AI team, it is being run by the wrong people, or at least not only by the right ones. Google's published lesson from its own AI red team says traditional security controls significantly mitigate many attacks, and this is what that sentence looks like when it reaches an implementation. Pair an application-security reviewer with an AI engineer, hand the first one the OAuth and SSRF rows, and the review gets better the same afternoon.
The Amazon Q Developer incident is the cleanest published illustration of an old control failing in a new place. AWS's own security bulletin gives the root cause as "an inappropriately scoped GitHub token in their CodeBuild configuration", which let an outside actor land code in a release. The injected instruction told the assistant to wipe resources. It did not execute, the bulletin notes, "unsuccessful in executing due to a syntax error" - which is luck, not a control. The failure was token scope. The AI was the payload's delivery vehicle, not its cause.
The defences that actually bound this
ATLAS names them, and they line up exactly with the right-hand half of the chain in Part 2. None of them makes the agent harder to fool. All of them make being fooled cheaper.
| Mitigation | What it does | Where it bites |
|---|---|---|
| M0026 / M0027 / M0028 | Permission configuration across the agent, its tools and its data | The credential at step 3. The highest-leverage control in this list |
| M0029 Human In-the-Loop | A person approves before the action fires | Irreversible tools only. See the honesty note below |
| M0030 Restrict Tool Invocation on Untrusted Data | Content from an untrusted source cannot reach the tools that matter | Cuts the chain between step 1 and step 2, which is the only place it can be cut |
| M0031 Memory Hardening | Bounds what can be written to memory and what memory can cause | AML.T0080 and ASI06. Persistence is the difference between an incident and a recurring one |
| M0032 Segmentation | A compromised agent reaches one tenant, one dataset, one environment | Blast radius. This is what turns a Critical into a High |
Beacon's tool permission manifest ★ 12 min · everyone builds
Support Bot is the T3 bot that can issue refund credits, so it is the manifest to write first. This artefact is the input to nearly every severity decision for the rest of the engagement, and most teams have never written it down at all. One row per tool, and the two columns everyone forgets are reversible and untrusted_data_may_invoke.
Fill the reversible column first, for every tool. This is the b1 homework arriving with interest. Reversible tools can tolerate autonomy; irreversible ones cannot, and the whole of M0029 should be spent on that short list rather than spread across everything.
Name the credential principal explicitly. If the answer is "it runs as the calling user", you have inherited every permission that user has, including the ones the workflow never needed. If the answer is a shared service account with broad rights, step 4 of the chain is as wide as that account, and that is your severity.
Set untrusted_data_may_invoke honestly. Any tool reachable while untrusted content is in context is reachable by that content. This is M0030 written as configuration rather than as a hope, and it is the one place the chain between steps 1 and 2 can actually be cut.
Now run the hallucination-alone test. For each irreversible tool, ask: if the model simply invents a reason to call this, with nobody attacking, what happens? On Beacon's Support Bot the answer was a credit issued to the wrong account, which is a finding with no adversary in it and no k of N to argue about.
Close the renderer. AML.T0077 has no ATLAS mitigation mapped, and the durable real-world fix has been to remove the channel: GitHub disabled image rendering in Copilot Chat outright. Beacon does the same, and the manifest is where that decision is recorded so that a future feature request has to argue with it.
The MCP check, and the two pre-deployment heuristics ★ 8 min · in pairs
Two artefacts to finish on. The first is the review checklist for any MCP server your agent talks to, written as assertions rather than as prose so that it can be automated. The second is the pair of heuristics that decide whether a workflow should ship as an agent at all.
Run the checklist against one real MCP server, in pairs, four minutes. Then note which of the six assertions your AI team could have answered and which needed the application-security team. That split is the staffing argument from Part 3, made with your own system.
Apply the lethal trifecta. Simon Willison's heuristic: access to private data, exposure to untrusted content, and the ability to communicate externally. Any one alone is safe. All three together mean attacker text can move your data out, and removing any one leg removes the risk. Walk Beacon's three bots through it and write down which leg you would cut on each.
Apply the Rule of Two. Meta's formulation, which OWASP cites as a floor: treat simultaneous (A) untrusted input, (B) sensitive data and (C) state change or external communication as high risk, and require per-action human approval for an agent holding all three. Note OWASP's own caveat while you use it: the rule is silent on autonomy depth, so an agent with three legs and forty sequential steps scores the same as one with three legs and two steps, which is a real gap rather than a quibble.
Write the sentence that closes the session. For each Beacon bot: this workflow is safe to run as an agent because the credential can only do X, or this workflow should not run as an agent, which is a legitimate finding rather than a failure. NCSC's phrasing is the one to borrow when it lands that way: if the system's security cannot tolerate the remaining risk, it may not be a good use case for LLMs.
Try it yourself - this week ◐ 45-60 min total
- Write the permission manifest for one real agent you own, including the credential principal. Most teams discover during this exercise that a tool runs under a broader identity than anybody intended, and that discovery is worth more than the rest of the session.
- Run the hallucination-alone test on every irreversible tool. Any tool where a plain model mistake causes harm is a finding you can file today with no attack chain attached.
- Take the six MCP assertions to whoever operates your servers and ask which are already true. Note how many of the answers come from a security engineer rather than an AI engineer.
- Pick your loudest agentic roadmap item and score it on both the lethal trifecta and the Rule of Two. If it holds all three legs, the honest recommendation is per-action approval or a leg removed, and you now have two published heuristics to say so with.
Official sources covered
Every framework, figure and quotation on this page traces to a primary source catalogued in this course's source map, verified 2026-08-14. This page covers:
Three questions before you go 🎯 ◐ 90 seconds
1 · Which excessive-agency test can you run before any attacker is involved, and why is it the one to run first?
A and B are both real tests and both cost time, need N trials, and produce findings someone can argue with. The hallucination-alone test costs a reading of your own tool list and produces a finding that cannot be disputed, because it relies only on a property everyone already agrees the system has: it is sometimes wrong. If a plain mistake can issue a credit or delete a record, that is excessive agency today, and the adversary is a distraction.
2 · Your review of an MCP server finds no per-client consent in the proxy, a token accepted without audience validation, and discovery fetches that reach link-local addresses. What kind of findings are these?
The tell is that every control is already written down somewhere older than the protocol: exact-match redirect URIs, single-use state stored only after consent, audience validation, and blocking private and reserved ranges including 169.254/16 for cloud metadata. Treating these as AI problems routes them to the team least likely to have the relevant muscle memory, which is the staffing failure this session exists to prevent.
3 · You propose human approval on every agent action as the fix. What is the strongest honest objection?
C is simply false: M0029 Human In-the-Loop is a named ATLAS mitigation, and a good one when it is aimed. A is true and is a product argument rather than a security one. B is the security argument, and the honesty matters as much as the point: OWASP concedes that human-in-the-loop degrades under fatigue and ASI09 Human-Agent Trust Exploitation is built on it, but the specific rates circulating in vendor blogs have no primary study behind them. Say the mechanism, decline to quote a number, and put the approvals where the irreversible actions are.