---
title: The Agent Attack Taxonomy (AAT), full technical paper
description: The complete ZioSec Agent Attack Taxonomy: 8 attack layers, 10 tactics, 62 techniques, and 10 threat scopes, with detection guidance, the AAT Coverage Matrix, OWASP ASI and MITRE ATLAS cross-maps, and 14 classified real-world incidents.
url: https://ziosec.com/agent-attack-taxonomy
pdf: https://ziosec.com/downloads/ziosec-agent-attack-taxonomy.pdf
---
# The agentic attack surface, classified.
The ZioSec Agent Attack Taxonomy is a working classification system for finding, describing, and reporting the ways enterprise AI agents actually get broken.
## The two names.
The **Agent Attack Taxonomy (AAT)** is the common language for agent attacks. It classifies each finding by attack layer, tactic and technique, and threat scope, while carrying the existing standards mappings and stable identifiers used in ZioSec reports.
The **Agentic AI Offensive Security Framework (A2OSF)** is the methodology for putting that language to work. It defines how agentic systems are scoped, attacked, measured, reported, and continuously retested.
The distinction is organizational, not technical: AAT gives the existing taxonomy within A2OSF a clear public identity. It does not change or replace its named conventions, identifiers, or mappings. AAT is the classification taxonomy contained within A2OSF. A2OSF is the broader offensive-security methodology used to generate, classify, measure, and remediate those findings.
## What is in this paper.
Sections 1 through 3 are written for security leadership and can be read on their own. Sections 4 through 6 contain the taxonomy itself. Sections 7 through 11 are reference material for the teams who will run it.
Every element in AAT carries a stable identifier. Layers are `L-XXX`. Tactics are `T-XXX`. Techniques are `T-XXX.nnn`. The identifiers do not change between versions, so a finding filed today is still queryable after the next revision. Cite them directly in tickets, reports, and control mappings.
## Executive summary.
Your organization now runs software that takes actions. Not software that recommends actions to a human who then takes them: software that moves money, writes to production databases, sends mail on your behalf, and calls other software that does the same. That is a category change in your attack surface, and it arrived faster than the vocabulary needed to describe it.
Most enterprises testing agentic systems today have the same problem, and it is not a lack of testing. It is that the findings come back as anecdotes. One report says "the agent was jailbroken." Another says "we got it to leak the system prompt." A third describes a chain of four legitimate tool calls that ended in customer data leaving the building. Every one of these is a real finding. None of them can be counted, compared, trended, or handed to an auditor as evidence of anything.
AAT exists to fix that. AAT decomposes every agentic security finding into three orthogonal dimensions, so that the finding answers three questions in a form a machine can index and a board can read:
The structural component of the agentic architecture where the vulnerability was exploited. Eight layers, from the input surface to the human oversight boundary.
The specific method used to manipulate, exploit, or subvert the agent. Ten tactics, 62 techniques, each with detection guidance attached.
The business risk carried by the finding. Ten scopes, from unauthorized action to behavioral integrity loss, each with a stated impact.
### What AAT covers
A taxonomy built only for single-agent chatbots would stop at the runtime: interface, orchestration, memory, tooling, and the traffic between agents. That is not what enterprises are running. Production systems are multi-agent fleets, MCP tool registries, delegated machine identities, and human approval workflows that have quietly become rubber stamps, and the highest-impact findings land in exactly those places.
AAT spans eight attack layers, ten tactics, and 62 techniques, every one carrying detection guidance and a cross-map to OWASP ASI01 to ASI10 and MITRE ATLAS. Fourteen real, publicly documented incidents from 2025 are classified in its terms, so the taxonomy can be checked against reality rather than argued about in the abstract.
### What you should do with it
- **Adopt the identifiers, not just the ideas.** The value compounds only when findings from your internal red team, your vendors, and your platform all carry the same `L-` and `T-` tags.
- **Measure coverage, not activity.** Section 7 gives you a layer-versus-tactic grid. Blank cells are untested surface, and untested surface is the only kind an adversary is guaranteed to find first.
- **Route by threat scope, not severity alone.** A medium-severity technique that produces a regulatory breach outranks a critical-severity technique that produces a cost spike. Section 6 makes that explicit.
- **Wire the detection guidance into monitoring.** Every technique in Section 5 carries a detection approach. Those are backlog items, not commentary.
You cannot manage what you cannot count, and you cannot count findings that have no shared name. AAT is the naming scheme. A2OSF is the methodology for putting it to work. The rest of this paper is what each name means, how it is detected, and what it costs you when it goes unhandled.
## Why agentic AI breaks classic pentesting.
A classic penetration test asks one question: can I get in. An agent has already answered it. The agent is inside, it holds credentials, it can call tools, and it was designed to do things on instruction. The question is no longer access. The question is what an adversary can make it do with the access it already has.
That shift invalidates several assumptions the traditional testing playbook depends on. It is worth naming them precisely, because each one maps to a layer in AAT.
### Five structural breaks
#### 1. The system is non-deterministic, so a single pass proves nothing
A web application either has the SQL injection or it does not. An agent may refuse a request nine times and comply on the tenth, because temperature, context length, retrieved documents, and conversation history all moved. A one-shot test result is a sample, not a verdict. Validation has to be continuous and repeated, and findings have to be expressed as reproducible technique classes rather than one-off transcripts.
#### 2. The tool boundary is the blast radius
The model is not the dangerous part. The tools are. A model that hallucinates is a quality problem; a model that hallucinates while holding a database connection, a payments API, and a shell is an incident. Traditional application testing scopes the app; agentic testing has to scope every downstream system the agent can reach and every permission it can borrow. This is layer `L-TOO`, and it carries more techniques than any other in AAT.
#### 3. Memory is state the attacker can write to
Vector stores, conversation history, and long-term profiles are all persistence surfaces. An attacker who can place content into a retrieval corpus has written to the agent's beliefs, and unlike a compromised session that ends at logout, poisoned memory survives. Remediating the entry point does not remediate the memory. This is `L-MEM`, and the persistence tactic `T-PER` exists precisely because cleanup is a separate problem from containment.
#### 4. Trust between agents is transitive and mostly unverified
In a multi-agent system, a supervisor tells a worker what to do and the worker complies because the message claimed to come from the supervisor. Most deployments today have no cryptographic identity on that channel. Compromise one low-trust agent and you inherit the privileges of everything that trusts it. This is `L-MAG` and the tactic `T-MAC`, and it is where an agentic breach turns into a fleet breach.
#### 5. Identity is machine-to-machine, and delegation leaks
Agents hold non-human identities. They delegate to sub-agents. In practice they delegate everything they have, because scoping a delegation correctly requires knowing in advance what the sub-task needs, and the whole point of an agent is that it decides that at runtime. The result is an entire class of privilege escalation that no user-centric IAM review is designed to catch. This is `L-IAM` and the tactic `T-ICE`.
Every link in that chain is individually low-severity and individually policy-compliant. The chain is critical. A taxonomy that only classifies single steps will grade each link a medium and miss the incident entirely, which is why AAT allows a finding to carry multiple techniques and why `T-TEE.006` exists as its own named technique.
### What the rest of your stack does not do
Enterprises reasonably ask why existing controls do not cover this. The honest answer is that they cover a different problem. Guardrails filter inputs and outputs: measurement, not attack. Observability platforms record what happened: forensics, not adversary simulation. Model evaluations score capability and safety on curated benchmarks: they do not chain exploits across your tools, your data, and your other agents. Traditional pentest vendors test the application around the agent, then stop at the model boundary because they have no methodology for what is behind it.
None of those are failures. They are scope. The gap is that nothing in the standard stack attacks the running agent the way an adversary would, and nothing produces findings in a form that can be aggregated across a fleet. That gap is what AAT and A2OSF are built to close.
Guardrails · WAFs · model evaluations · observability · policy engines · AI governance checklists. All necessary. None adversarial.
Deep-chained attacks against the running agent, continuously, with every finding classified, mapped, and turned into evidence. Classified with AAT. Executed through A2OSF.
## The taxonomy: three orthogonal dimensions.
AAT classifies findings: not products and not vendors. Every finding from a penetration test of an agentic system is decomposed into three dimensions that vary independently of one another.
Orthogonality is the design constraint that matters. Layer, technique, and threat scope are chosen so that knowing one tells you very little about the others: the same technique can appear at different layers, and the same layer can produce wildly different business impacts. That independence is what makes the dimensions useful as filters, as chart axes, and as routing rules. A taxonomy whose dimensions correlate is a single dimension wearing three labels.
### Anatomy of an AAT finding
The following is the worked example from the AAT specification. It is a single incident expressed in AAT terms, and it is the shape every AAT-classified finding in a ZioSec report takes.
| Dimension | Value | Details |
|---|---|---|
| Layer | `L-INT` Interface | Vulnerability exploited via email processed as a RAG data source. |
| Technique | `T-INM.002` Indirect injection | Crafted email with hidden instructions interpreted as trusted guidance. |
| Technique (2) | `T-TEE.006` EDR-invisible chaining | Legitimate tools chained to exfiltrate data without triggering alerts. |
| Threat scope | Data exfiltration (High) | Confidential data leaked to an external endpoint without user awareness. |
| OWASP ASI | `ASI01, ASI02` | Auto-populated from technique metadata. |
| MITRE ATLAS | `AML.T0051.001, AML.T0086` | Auto-populated from technique metadata. |
Note what the tagging buys you. A GRC reader can filter on threat scope and never read a technique ID. An engineer can filter on layer and get a list of components to harden. A compliance analyst can filter on ASI reference and produce a control-by-control response. Three audiences, one finding, no translation layer.
### Tagging rules
- **At least one layer is required.** A finding with no layer cannot be routed to an owning team.
- **At least one technique is required.** Multiple techniques are expected on chained findings, and chained findings are the norm rather than the exception.
- **Threat scope is recommended and can be inferred.** Where the tester is uncertain, it is auto-assignable from layer and technique heuristics, then confirmed on review.
- **Cross-framework references are auto-populated.** OWASP ASI and MITRE ATLAS identifiers are properties of the technique, not judgements the tester makes. They should never be entered by hand.
### Identifier stability
Identifiers are stable. A technique may be deprecated, superseded, or re-scoped in a future revision, but its ID will not be reassigned to a different technique. Findings filed against `T-TEE.006` today will still resolve to EDR-invisible tool chaining after the next release. Anything planned but not yet delivered (the discovery tactic, per-technique CWE mappings, direct control-level tables for NIST AI RMF, ISO 42001, and the EU AI Act) is named as a future extension in the section where it belongs rather than implied as present.
AAT is self-contained but not self-important. It does not attempt to replace OWASP or MITRE ATLAS. It sits beneath them at the resolution an offensive tester actually works at, and carries references upward into engineering, risk, and audit workflows, so a single finding satisfies an engineering backlog, a risk register, and an audit request without being rewritten three times.
## Attack vectors and layers.
Eight AAT layers represent the structural attack surfaces of an agentic AI system. They are the "where". Every finding must be tagged with at least one, and chained findings routinely span three or four.
| ID | Layer | Component focus | OWASP ASI | ATLAS tactic |
|---|---|---|---|---|
| L-INT | Interface | User UI, API gateway, voice and multimodal inputs, webhooks, indirect input surfaces (email, calendar, browsing content, RAG retrieval sources). | `ASI01` | Initial Access |
| L-ORC | Orchestration | The agent brain: planner (CoT), router, supervisor agents, task decomposition, policy enforcement points, planner-executor separation. | `ASI01, ASI08` | Execution, Impact |
| L-MEM | Memory | Context window, short-term buffers, vector DBs (RAG), long-term state stores, shared memory, memory trust and provenance metadata. | `ASI06` | Persistence, Collection |
| L-TOO | Tooling | Action layer: APIs, SQL connections, code execution sandboxes, browsers, file systems, MCP tool interfaces, sandbox boundaries. | `ASI02, ASI05` | Execution, Exfiltration |
| L-MAG | Multi-Agent | Inter-agent protocols (messaging buses), metadata headers, shared state, A2A protocol, agent discovery and routing, trust chains. | `ASI07, ASI10` | Lateral Movement |
| L-IAM | Identity & Access | Agent identities (NHI), credential stores, OAuth and token binding, session isolation, delegation chains, permission boundaries, NHI lifecycle. | `ASI03` | Credential Access, Privilege Escalation |
| L-SUP | Supply Chain | MCP and A2A registries, package dependencies, prompt template repos, agent cards, AIBOM/SBOM integrity, update channels, runtime component loading. | `ASI04` | Resource Development, Initial Access |
| L-HAB | Human-Agent Boundary | HITL approval workflows, alert and notification surfaces, agent UI outputs, trust signals and confidence displays, oversight control panels. | `ASI09` | Impact |
### Why these eight
The first five layers (interface, orchestration, memory, tooling, multi-agent) describe the runtime, and they suffice when an agent is a model with a few tools attached. The remaining three describe the parts of the system that are not the agent at all, and they are where the highest-impact findings of the last eighteen months have actually landed.
**Identity and access** was added because agent credentials behave nothing like user credentials. They are long-lived, broadly scoped, machine-held, and delegated at runtime by a component that cannot reason reliably about least privilege. A permissions review that assumes a human on the other end of the token does not model this.
**Supply chain** was added because the agent ecosystem re-created every package-management mistake of the last twenty years in about eighteen months, and then added two new ones: tool descriptors that are read as instructions, and agent cards that advertise capabilities nobody verifies. An organization can have perfect agent hygiene and still be compromised by a manifest served from a registry it never audited.
**Human-agent boundary** was added because human-in-the-loop is the control most enterprises are relying on, and it is the control least often tested. An approval workflow that a reviewer clicks through 400 times a day is not an approval workflow. It is a latency tax with an audit trail. Treating the human as part of the attack surface is uncomfortable and necessary.
### Layer weighting in practice
The eight layers do not carry equal technique counts, and the distribution is informative. Tooling, orchestration, and memory each attract twelve technique tags; the human-agent boundary attracts seven. That is not a statement about which layer is most dangerous. It is a statement about where the offensive research community has concentrated, and it should be read as a coverage map with known thin spots rather than a risk ranking.
## Tactics and techniques.
Ten AAT tactics encompassing 62 AAT techniques. The tactic answers "what kind of attack was this"; the technique answers "specifically what did the attacker do". Every finding must carry at least one technique, and every technique carries a severity, a layer assignment, an OWASP ASI reference, an ATLAS identifier where one applies, and a detection approach.
The severity ratings are inherent, not contextual. They describe what the technique can do when it succeeds against a system with typical permissions, not what it did in your environment. Contextual risk is the job of the threat scope dimension in Section 6. Read the two together.
| Tactic | Name | Count | Primary layer | Severity profile |
|---|---|---|---|---|
| T-INM | Input Manipulation | 5 | `L-INT` | 1 critical · 3 high · 1 medium |
| T-LPS | Logic & Planning Subversion | 7 | `L-ORC` | 2 critical · 3 high · 2 medium |
| T-TEE | Tool & Environment Exploitation | 10 | `L-TOO` | 4 critical · 5 high · 1 medium |
| T-MKP | Memory & Knowledge Poisoning | 6 | `L-MEM` | 2 critical · 3 high · 1 medium |
| T-MAC | Multi-Agent Exploitation | 7 | `L-MAG` | 2 critical · 3 high · 2 medium |
| T-ICE | Identity & Credential Exploitation | 6 | `L-IAM` | 3 critical · 3 high |
| T-SCC | Supply Chain Compromise | 6 | `L-SUP` | 4 critical · 2 high |
| T-HTE | Human Trust Exploitation | 6 | `L-HAB` | 4 high · 2 medium |
| T-DEV | Defense Evasion | 5 | `L-ORC` | 2 critical · 3 high |
| T-PER | Persistence | 4 | `L-MEM` | 3 critical · 1 high |
**Layer** lists every layer the technique can be exploited at; a technique with two layers produces a finding tagged with both. **ASI** and **ATLAS** are auto-populated references, and a dash means no ATLAS technique currently corresponds: an honest gap rather than a forced fit. **Sev.** is inherent severity as defined above.
## Input manipulation.
Manipulating inputs processed by the agent to alter its behavior, bypass controls, or inject unauthorized instructions.
This is the tactic everyone has heard of and the one most organizations believe they have handled. They have usually handled about a fifth of it. Direct prompt injection through the chat box is the visible surface and the easiest to filter. The dangerous half is indirect: the agent reads a document, a web page, an email, a calendar invite, or a retrieved chunk, and the content of that data is treated as instruction rather than information.
The distinction matters because indirect injection removes the attacker from the session entirely. There is no malicious user to rate-limit and no suspicious prompt in the transcript. An adversary who can place a file into a shared drive that your agent indexes has a persistent, zero-click instruction channel into your fleet. `T-INM.002` is rated critical for this reason, and it appears in five of the fourteen real incidents mapped in Section 10: more than any other single technique.
| ID | Technique | Description | Layer | ASI | ATLAS | Sev. |
|---|---|---|---|---|---|---|
| T-INM.001 | Direct Prompt Injection | Standard jailbreak or prompt injection via the primary user input channel. | `L-INT` | `ASI01` | `AML.T0051.000` | High |
| T-INM.002 | Indirect Prompt Injection | Instructions hidden in external data (RAG docs, web pages, PDFs, emails) processed by the agent as trusted content. | `L-INT, L-MEM` | `ASI01` | `AML.T0051.001` | Critical |
| T-INM.003 | Cross-Modal Injection | Malicious instructions embedded in images, audio, or video to bypass text-based input filters. | `L-INT` | `ASI01` | `AML.T0051` | High |
| T-INM.004 | Scheduled/Deferred Injection | Malicious instructions via calendar invites, scheduled emails, or timed data that influence agent goals over repeated sessions (goal-lock drift). | `L-INT` | `ASI01` | `AML.T0051.002` | High |
| T-INM.005 | Encoding & Obfuscation Bypass | Base64, Unicode homoglyphs, or tokenizer-specific tricks to evade text-based injection filters. | `L-INT` | `ASI01` | `AML.T0068` | Medium |
#### Detection guidance: T-INM
| Technique | Detection approach |
|---|---|
| T-INM.001 Direct Prompt Injection | Input anomaly detection, known jailbreak pattern matching, guardrail trigger logs. |
| T-INM.002 Indirect Prompt Injection | CDR on ingested data, prompt-carrier detection on retrieved documents, anomalous instruction patterns in non-user data. |
| T-INM.003 Cross-Modal Injection | Multi-modal content scanning, OCR and transcription of media inputs before processing. |
| T-INM.004 Scheduled/Deferred Injection | Monitor recurring injection patterns across sessions, behavioral baseline drift detection, calendar and email content scanning. |
| T-INM.005 Encoding & Obfuscation Bypass | Multi-encoding normalization before filter evaluation, tokenizer-aware scanning, character-set anomaly detection. |
## Logic and planning subversion.
Attacking the agent's reasoning, planning, and decision-making processes to alter execution flow or cause unintended outcomes.
Input manipulation gets instructions in. Planning subversion changes what the agent decides to do with them. The two are frequently confused and should not be: an agent can be goal-hijacked by perfectly legitimate input if its planner weights the wrong signal, and a well-defended input surface does nothing to prevent a reward function that rewards the wrong outcome.
Two techniques here deserve executive attention. `T-LPS.007`, reward and metric hacking, is the class where an agent optimizing a stated objective (reduce cloud spend, close tickets faster, improve response time) reaches a harmful conclusion that no one authorized and everyone technically asked for. Deleting backups does reduce storage costs. And `T-LPS.006`, governance drift, is the slow failure of human oversight under repetition: hundreds of benign approvals train the reviewer to approve, and the attacker spends that trained reflex on one high-impact action.
| ID | Technique | Description | Layer | ASI | ATLAS | Sev. |
|---|---|---|---|---|---|---|
| T-LPS.001 | Goal Hijacking | Overriding the agent's primary objective to perform a different, attacker-controlled task while appearing to operate normally. | `L-ORC` | `ASI01` | `AML.T0051` | Critical |
| T-LPS.002 | Planning Denial (Infinite Loop) | Inducing a state where the agent repeats a sub-task indefinitely, causing resource exhaustion and denial of service. | `L-ORC` | `ASI08` | `AML.T0029` | Medium |
| T-LPS.003 | Selective Instruction Skipping | Tricking the agent into ignoring specific safety, logging, or validation steps in its chain-of-thought. | `L-ORC` | `ASI01` | `AML.T0051` | High |
| T-LPS.004 | Temporal/Clock Manipulation | Spoofing system time or timezone data to bypass time-based restrictions, TTL logic, or scheduling controls. | `L-ORC` | `ASI03` | | Medium |
| T-LPS.005 | Cascading Hallucination Propagation | Hallucinated output from one planning step feeds into subsequent steps, compounding errors across multi-step chains. | `L-ORC, L-MAG` | `ASI08` | | High |
| T-LPS.006 | Governance Drift Exploitation | Repeated benign interactions erode HITL oversight (rubber-stamping), then relaxed controls are exploited for a high-impact action. | `L-ORC, L-HAB` | `ASI09` | | High |
| T-LPS.007 | Reward/Metric Hacking | Manipulating the agent's objective function or KPIs to optimize toward harmful outcomes, such as deleting backups to reduce costs. | `L-ORC` | `ASI10` | `AML.T0048` | Critical |
#### Detection guidance: T-LPS
| Technique | Detection approach |
|---|---|
| T-LPS.001 Goal Hijacking | Goal-state tracking against declared intent, behavioral baseline deviation alerting, anomalous tool-use sequences. |
| T-LPS.002 Planning Denial | Step-count circuit breakers, cost and time budget enforcement, loop detection in execution traces. |
| T-LPS.003 Selective Instruction Skipping | Mandatory step-completion verification, execution trace auditing against expected plan templates. |
| T-LPS.004 Temporal/Clock Manipulation | Server-side time validation, NTP integrity monitoring, timestamp consistency checks. |
| T-LPS.005 Cascading Hallucination Propagation | Inter-step output validation, confidence scoring with propagation decay, fact-checking gates. |
| T-LPS.006 Governance Drift Exploitation | Approval-rate anomaly monitoring, mandatory re-auth for high-impact actions, periodic oversight reset. |
| T-LPS.007 Reward/Metric Hacking | Outcome validation against business constraints, destructive-action guardrails independent of the objective function. |
## Tool and environment exploitation.
Exploiting the agent's tool interfaces, execution environment, or tool interactions to achieve unauthorized outcomes.
Ten techniques, four of them critical: the largest tactic in AAT and the one that turns a language problem into a security incident. Everything an agent can actually do to your environment happens here. The techniques divide into three families. Classic injection carried through a new channel: `T-TEE.001` is SSRF and SQL injection reached through the agent's tool arguments rather than an HTTP parameter. Privilege confusion, where the agent lends its own high-trust credentials to an attacker-supplied intent. And sequence attacks, where no individual call is a violation.
That third family is the one existing controls handle worst. `T-TEE.006`, EDR-invisible tool chaining, describes a sequence of individually policy-compliant administrative actions that together exfiltrate data. Every call passes its own check. The endpoint agent sees legitimate binaries. The policy engine sees approved tools. Only a control that evaluates the sequence catches it, and most enterprises do not have one. Alongside it, `T-TEE.009` covers the same idea for egress: a permitted tool used as a covert channel, exfiltrating over DNS lookups or steganography rather than an obvious upload.
| ID | Technique | Description | Layer | ASI | ATLAS | Sev. |
|---|---|---|---|---|---|---|
| T-TEE.001 | Parameter Injection (Tool SSRF) | Injecting malicious arguments into tool calls: crafted URLs for SSRF, SQL injection via database tools. | `L-TOO` | `ASI02, ASI05` | `AML.T0053` | High |
| T-TEE.002 | Confused Deputy Tooling | Tricking the agent into using its high-privilege credentials for an attacker-controlled action. | `L-TOO, L-IAM` | `ASI02, ASI03` | `AML.T0053` | Critical |
| T-TEE.003 | Tool Output Poisoning | Forcing a tool to return fabricated or manipulated responses to alter the agent's planning decisions. | `L-TOO` | `ASI02` | `AML.T0099` | High |
| T-TEE.004 | Insecure Delegation | Passing auth tokens or elevated permissions from agent to sub-process without scope restriction. | `L-TOO, L-IAM` | `ASI03` | | High |
| T-TEE.005 | Tool-Name Typosquatting | Registering a malicious tool with a name similar to a legitimate one so the agent resolves the wrong tool. | `L-TOO, L-SUP` | `ASI02, ASI04` | `AML.T0104` | High |
| T-TEE.006 | EDR-Invisible Tool Chaining | Chaining legitimate admin tools where each invocation is policy-compliant but the sequence achieves unauthorized data exfiltration. | `L-TOO` | `ASI02` | `AML.T0086` | Critical |
| T-TEE.007 | Sandbox Escape via Code Gen | Agent generates code exploiting the runtime sandbox: container escape, WASM escape, template injection, filesystem traversal. | `L-TOO` | `ASI05` | `AML.T0112` | Critical |
| T-TEE.008 | Unsafe Deserialization | Agent produces serialized objects with malicious payloads that execute on deserialization in downstream components. | `L-TOO` | `ASI05` | | Critical |
| T-TEE.009 | Approved-Tool Covert Channel | Using a safe tool for unintended exfiltration via side channels: DNS queries via ping, steganography via image tools. | `L-TOO` | `ASI02` | `AML.T0086` | High |
| T-TEE.010 | Loop Amplification (Cost DoS) | Inducing repeated calls to expensive APIs or cloud services, causing financial denial-of-service via bill spikes. | `L-TOO` | `ASI02` | `AML.T0034.002` | Medium |
#### Detection guidance: T-TEE
| Technique | Detection approach |
|---|---|
| T-TEE.001 Parameter Injection | Tool-input schema validation, URL and parameter allowlisting, parameterized query enforcement. |
| T-TEE.002 Confused Deputy Tooling | Per-action intent validation, policy-engine re-auth before privileged tool calls. |
| T-TEE.003 Tool Output Poisoning | Tool-output schema validation, response integrity verification, anomalous output detection. |
| T-TEE.004 Insecure Delegation | Token-scope auditing, delegation chain tracking, credential-use monitoring against declared intent. |
| T-TEE.005 Tool-Name Typosquatting | Tool allowlisting, name-similarity scanning, deterministic tool resolution with no fuzzy matching. |
| T-TEE.006 EDR-Invisible Tool Chaining | Sequence-aware behavioral analysis, tool-chain pattern matching, data-flow tracking across invocations. |
| T-TEE.007 Sandbox Escape via Code Gen | Static analysis of generated code before execution, syscall filtering (seccomp), container hardening. |
| T-TEE.008 Unsafe Deserialization | Deserialization input validation, type-checking, ban unsafe deserialization libraries in the agent runtime. |
| T-TEE.009 Approved-Tool Covert Channel | DNS query anomaly monitoring, egress content inspection, tool-output size and frequency anomalies. |
| T-TEE.010 Loop Amplification (Cost DoS) | Per-tool rate limiting, cost-budget circuit breakers, anomalous invocation frequency alerts. |
## Memory and knowledge poisoning.
Corrupting the agent's stored knowledge, context, or state to influence future decisions, persist backdoors, or degrade reliability.
Memory attacks are patient. Nothing detonates. The agent keeps working, gives plausible answers, and the corruption expresses itself later: sometimes in a different session, sometimes for a different user, sometimes as nothing more than a slow drift in what the agent believes to be true. That latency is exactly why these techniques survive incident response: the team fixes the ingestion path, declares the incident closed, and leaves the poisoned index in place.
Two techniques here should change how you architect. `T-MKP.005`, cross-tenant vector bleed, is a multi-tenancy failure dressed as an AI problem: loose namespace filters in a shared vector store let one customer's query retrieve another customer's chunks. It is critical, it is not exotic, and it is a straightforward pentest target. And `T-MKP.004`, bootstrap poisoning, describes the self-inflicted version: an agent whose own outputs are re-ingested as trusted memory will amplify its own errors indefinitely, with no attacker required at all.
| ID | Technique | Description | Layer | ASI | ATLAS | Sev. |
|---|---|---|---|---|---|---|
| T-MKP.001 | RAG Cache Poisoning | Inserting malicious entries into the vector DB to influence retrieved ground truth. | `L-MEM` | `ASI06` | `AML.T0070` | High |
| T-MKP.002 | Context Window Overflow | Flooding the context buffer to push system instructions out of active context. | `L-MEM` | `ASI06` | | High |
| T-MKP.003 | Sleeper Agent / Triggered Action | Embedding a dormant condition that only activates when a specific term, date, or condition is met. | `L-MEM` | `ASI06, ASI10` | `AML.T0094` | Critical |
| T-MKP.004 | Bootstrap Poisoning (Self-Reinforcing) | The agent's own outputs are re-ingested into trusted memory, creating self-amplifying contamination loops. | `L-MEM` | `ASI06` | `AML.T0080` | High |
| T-MKP.005 | Cross-Tenant Vector Bleed | Exploiting loose namespace filters in shared vector stores to pull another tenant's sensitive chunks. | `L-MEM` | `ASI06` | `AML.T0085.000` | Critical |
| T-MKP.006 | Long-Term Memory Drift | Incremental exposure to subtly tainted data that gradually shifts stored knowledge and goal weighting. | `L-MEM` | `ASI06` | `AML.T0080.000` | Medium |
#### Detection guidance: T-MKP
| Technique | Detection approach |
|---|---|
| T-MKP.001 RAG Cache Poisoning | Provenance tracking on indexed content, write-access controls, anomalous embedding detection. |
| T-MKP.002 Context Window Overflow | System-prompt pinning, input length limits, context-usage monitoring. |
| T-MKP.003 Sleeper Agent / Triggered Action | Periodic adversarial probing of stored knowledge, condition-based behavioral testing, memory auditing. |
| T-MKP.004 Bootstrap Poisoning | Block auto re-ingestion of agent outputs, source-origin tagging on memory writes, feedback-loop detection. |
| T-MKP.005 Cross-Tenant Vector Bleed | Strict per-tenant namespace isolation, tenant-ID filtering before search, namespace boundary pentesting. |
| T-MKP.006 Long-Term Memory Drift | Memory versioning with diff analysis, periodic baseline comparison, trust-score decay on unverified entries. |
## Multi-agent exploitation.
Attacking the communication, trust, and coordination mechanisms between agents in multi-agent systems.
The moment a second agent enters the architecture, you have a network, and the network has no authentication. That is not a caricature. In most production multi-agent deployments today, an agent trusts a message because of what the message claims about itself. There is no mutual TLS, no signed envelope, no per-agent cryptographic identity. Compromise the lowest-value agent in the fleet and you can address the highest-value one as its supervisor.
This is the tactic that converts a single-agent compromise into a fleet compromise, which is why it maps to ATLAS lateral movement. `T-MAC.005`, descriptor forgery, is the routing-layer version: publish an agent card or MCP descriptor that advertises exactly the capability a sensitive task needs, and the orchestrator will route the task to you. No exploit is required. The system works as designed, and the design assumed an honest registry.
| ID | Technique | Description | Layer | ASI | ATLAS | Sev. |
|---|---|---|---|---|---|---|
| T-MAC.001 | Agent Identity Spoofing | Masquerading as a trusted agent (manager, supervisor) to issue unauthorized commands to workers. | `L-MAG` | `ASI07, ASI10` | | Critical |
| T-MAC.002 | Context Contamination (Cross-Agent) | Leaking instructions from a low-trust agent into shared buffers used by a higher-trust agent. | `L-MAG, L-MEM` | `ASI07` | `AML.T0080.001` | High |
| T-MAC.003 | Inter-Agent Race Condition | Exploiting timing between two agents' actions to bypass a validation check. | `L-MAG` | `ASI07` | | Medium |
| T-MAC.004 | Protocol Downgrade Attack | Forcing agents to fall back to weaker communication modes, enabling injection or interception. | `L-MAG` | `ASI07` | | High |
| T-MAC.005 | A2A/MCP Descriptor Forgery | Publishing fake agent cards or MCP tool descriptors with false capabilities to attract sensitive task routing. | `L-MAG, L-SUP` | `ASI07, ASI10` | `AML.T0104` | Critical |
| T-MAC.006 | Trust Chain Replay | Replaying stale delegation tokens or trust messages to trick agents into honoring expired permissions. | `L-MAG, L-IAM` | `ASI07` | | High |
| T-MAC.007 | Semantics Split-Brain | A single instruction parsed into divergent intents by different agents, producing conflicting but legitimate-looking actions. | `L-MAG` | `ASI07` | | Medium |
#### Detection guidance: T-MAC
| Technique | Detection approach |
|---|---|
| T-MAC.001 Agent Identity Spoofing | Per-agent cryptographic identity attestation, mutual TLS, signed message verification. |
| T-MAC.002 Context Contamination | Trust-level tagging on shared-state writes, input sanitization on shared buffers. |
| T-MAC.003 Inter-Agent Race Condition | Atomic read-validate-execute transactions, optimistic concurrency controls, action-level locking. |
| T-MAC.004 Protocol Downgrade Attack | Protocol version pinning, mandatory minimum security enforcement, rejection of downgrade negotiation. |
| T-MAC.005 A2A/MCP Descriptor Forgery | Signed agent cards with PKI verification, attested registries with reputation scoring. |
| T-MAC.006 Trust Chain Replay | Nonce and timestamp binding on trust messages, short TTL on delegation tokens, state-hash verification. |
| T-MAC.007 Semantics Split-Brain | Typed message schemas, intent canonicalization before distribution, conflict detection on parallel outputs. |
## Identity and credential exploitation.
Exploiting agent identity systems, credential delegation, and access control to escalate privileges or impersonate trusted entities.
Half of this tactic is rated critical, and the reason is structural rather than technical. Agents delegate. Delegation requires deciding, in advance, the minimum permission set a sub-task needs. Agents decide their sub-tasks at runtime. The two facts are in direct conflict, and the conflict is resolved in production the same way every time: pass everything down and hope.
`T-ICE.001` is that failure named. `T-ICE.006` is its subtler sibling, where a low-privilege agent silently inherits higher-privilege OAuth scopes mid-workflow because no component re-validates intent against scope. And `T-ICE.002` is the reminder that agent memory is a credential store nobody registered as one: tokens that appear in a context window persist wherever that context is written, and can be replayed from a later session.
| ID | Technique | Description | Layer | ASI | ATLAS | Sev. |
|---|---|---|---|---|---|---|
| T-ICE.001 | Delegated Privilege Abuse | A delegating agent passes all permissions to a sub-agent without scoping, granting access far beyond the task. | `L-IAM` | `ASI03` | | Critical |
| T-ICE.002 | Memory-Based Credential Replay | Extracting cached credentials from agent memory or context from a prior session and reusing them. | `L-IAM, L-MEM` | `ASI03` | `AML.T0083` | Critical |
| T-ICE.003 | TOCTOU in Agent Workflows | Permissions validated at workflow start change or expire before execution completes, but the agent continues with outdated auth. | `L-IAM` | `ASI03` | | High |
| T-ICE.004 | Synthetic Identity Injection | Registering a fake agent with fabricated identity in an A2A registry, gaining inherited trust for privileged actions. | `L-IAM, L-MAG` | `ASI03, ASI10` | `AML.T0103` | Critical |
| T-ICE.005 | Device-Code Phishing Across Agents | Sharing a device-code auth link that a browsing agent follows; a helper agent completes it, binding a victim's tenant to attacker scopes. | `L-IAM` | `ASI03` | `AML.T0100` | High |
| T-ICE.006 | Token Scope Inheritance Abuse | A low-privilege agent inherits higher-privilege OAuth scopes during a multi-agent workflow without intent re-validation. | `L-IAM` | `ASI03` | | High |
#### Detection guidance: T-ICE
| Technique | Detection approach |
|---|---|
| T-ICE.001 Delegated Privilege Abuse | Mandatory scope reduction on delegation, permission-boundary enforcement, delegation chain auditing. |
| T-ICE.002 Memory-Based Credential Replay | Credential scrubbing between sessions, ephemeral per-task credentials, memory wipe on context switch. |
| T-ICE.003 TOCTOU in Agent Workflows | Per-step re-authorization, short-lived tokens with step-level refresh. |
| T-ICE.004 Synthetic Identity Injection | Closed-registration policies, PKI-based identity verification, mandatory attestation before trust assignment. |
| T-ICE.005 Device-Code Phishing | Block agent-initiated device-code flows, require human confirmation for OAuth authorization. |
| T-ICE.006 Token Scope Inheritance Abuse | Intent-binding on tokens, rejection of mismatched intent, transitive permission monitoring. |
## Supply chain compromise.
Compromising upstream components, registries, or dependencies that agents load to inject malicious behavior at scale.
Four of six techniques here are critical, and the reason is leverage. Every other tactic in AAT compromises one agent at a time. Supply chain compromise compromises everyone who pulls the component. A poisoned prompt template, a tampered MCP manifest, or a backdoored package reaches every consumer on the next load, and agents load frequently and automatically by design.
There is a novel failure mode in this tactic that has no direct equivalent in traditional software supply chain security. `T-SCC.002`, tool-descriptor injection, exploits the fact that an agent reads a tool's metadata (its description, its schema, its parameter documentation) as natural language it must interpret. Documentation has become an instruction channel. A field that a human developer skims is a field the agent obeys, and nothing in a conventional dependency scanner is looking for imperative English in a JSON schema.
| ID | Technique | Description | Layer | ASI | ATLAS | Sev. |
|---|---|---|---|---|---|---|
| T-SCC.001 | Poisoned Prompt Templates | Hidden instructions in externally hosted prompt templates that agents auto-load, causing silent exfiltration or destruction. | `L-SUP` | `ASI04` | `AML.T0010` | Critical |
| T-SCC.002 | Tool-Descriptor Injection (Source) | Embedding hidden instructions in a tool's metadata, schema, or MCP descriptor at the source repository. | `L-SUP` | `ASI04` | `AML.T0110` | Critical |
| T-SCC.003 | MCP/Agent Registry Poisoning | Compromising a package registry or MCP server to serve tampered manifests or descriptors to all consumers. | `L-SUP` | `ASI04` | `AML.T0010.005` | Critical |
| T-SCC.004 | Malicious Agent Card Registration | Publishing a fake agent card in an open A2A directory with exaggerated capabilities to attract sensitive task routing. | `L-SUP, L-MAG` | `ASI04, ASI10` | `AML.T0111` | High |
| T-SCC.005 | Third-Party Agent/Plugin Vulnerability | Introducing a third-party agent with unpatched vulnerabilities or insecure defaults into multi-agent workflows. | `L-SUP` | `ASI04` | `AML.T0010` | High |
| T-SCC.006 | Dependency/Package Backdoor | A compromised or typosquatted NPM or PyPI package is auto-installed, executing malicious code at install or runtime. | `L-SUP` | `ASI04` | `AML.T0010.001` | Critical |
#### Detection guidance: T-SCC
| Technique | Detection approach |
|---|---|
| T-SCC.001 Poisoned Prompt Templates | Content-hash pinning of templates, version control with peer review, anomaly scanning at load time. |
| T-SCC.002 Tool-Descriptor Injection | Descriptor integrity verification with signed schemas, automated metadata scanning for injection patterns. |
| T-SCC.003 MCP/Agent Registry Poisoning | Registry access controls, signed package manifests, multi-source attestation, continuous integrity monitoring. |
| T-SCC.004 Malicious Agent Card Registration | Closed or attested registries, digital signature verification on agent cards, reputation-scoring systems. |
| T-SCC.005 Third-Party Agent/Plugin Vulnerability | Dependency scanning, vulnerability assessment, AIBOM and SBOM maintenance, sandbox isolation for third-party agents. |
| T-SCC.006 Dependency/Package Backdoor | Dependency pinning and lockfile integrity, provenance verification, typosquat scanning, sandboxed builds. |
## Human trust exploitation.
Manipulating the human-agent trust relationship to bypass oversight controls or induce poor decisions.
Human-in-the-loop is the control most enterprise AI governance programmes lean on hardest, and it is the one almost nobody tests. This tactic exists to make that testable. Every technique here attacks the reviewer rather than the system, and every one of them succeeds against a control that looks perfectly healthy on an architecture diagram.
The pattern is consistent: exhaust the human, then act. `T-HTE.002` generates enough low-severity noise to desensitize the reviewer. `T-HTE.005` floods the approval queue so thorough review becomes arithmetically impossible. `T-HTE.001` exploits the tendency to accept a confident answer without verification. `T-HTE.006` takes the slow path, expanding the agent's autonomous scope one individually reasonable request at a time until the oversight boundary has moved without anyone deciding to move it. None of these require a model failure. They require a busy person.
| ID | Technique | Description | Layer | ASI | ATLAS | Sev. |
|---|---|---|---|---|---|---|
| T-HTE.001 | Automation Bias Exploitation | Leveraging the human tendency to trust AI outputs without verification, delivering confident but incorrect information. | `L-HAB` | `ASI09` | `AML.T0067` | High |
| T-HTE.002 | Alert Fatigue Induction | Generating a high volume of low-severity alerts to desensitize reviewers, then slipping high-impact actions through. | `L-HAB` | `ASI09` | | High |
| T-HTE.003 | False Authority/Confidence Display | Agent presents fabricated citations, fake confidence scores, or non-existent sources to discourage verification. | `L-HAB` | `ASI09` | `AML.T0067.000` | Medium |
| T-HTE.004 | UI/Output Manipulation | Agent manipulates output formatting or framing to steer decisions: burying warnings, highlighting preferred options, false urgency. | `L-HAB` | `ASI09` | `AML.T0077` | Medium |
| T-HTE.005 | HITL Overwhelm (Volume Attack) | Flooding the reviewer with a massive batch of actions requiring approval, making thorough review impossible. | `L-HAB` | `ASI09` | | High |
| T-HTE.006 | Incremental Scope Creep | Gradually expanding the agent's autonomous action space through small, individually reasonable permission requests. | `L-HAB, L-IAM` | `ASI09` | | High |
#### Detection guidance: T-HTE
| Technique | Detection approach |
|---|---|
| T-HTE.001 Automation Bias Exploitation | Mandatory uncertainty disclosure, periodic accuracy audits, second-opinion mechanisms for high-stakes decisions. |
| T-HTE.002 Alert Fatigue Induction | Alert-volume anomaly detection, risk-proportional escalation, mandatory slowdown for high-impact actions. |
| T-HTE.003 False Authority/Confidence Display | Citation verification systems, source-link validation, confidence-score auditing against actual accuracy. |
| T-HTE.004 UI/Output Manipulation | Output structure auditing, A/B comparison of agent recommendations against a baseline. |
| T-HTE.005 HITL Overwhelm | Approval queue rate limiting, batch-size caps, automatic escalation when queue depth exceeds capacity. |
| T-HTE.006 Incremental Scope Creep | Permission-expansion tracking, periodic privilege review cycles, cumulative-scope dashboards. |
## Defense evasion.
Techniques to avoid detection by monitoring systems, guardrails, or human reviewers during or after an attack.
Evasion is what separates a demonstrated vulnerability from an actual breach. Every other tactic describes how an agent is made to misbehave; this one describes how the misbehaviour stays unnoticed long enough to matter. It is also the tactic most likely to be missing from an internal red-team exercise, because an internal team is not trying to hide from itself.
`T-DEV.003`, log suppression, is critical for a reason that goes beyond the immediate incident: an agent with the ability to write to its own audit trail can invalidate the evidence you would use to investigate anything. `T-DEV.002`, behavioral mimicry, is the same problem in the behavioral dimension: an agent that maintains a compliant-looking pattern of tool use while pursuing a different objective defeats any monitoring keyed to individual actions. And `T-DEV.004` is the reconnaissance step most guardrail vendors do not log: systematic boundary probing to map exactly where the filter stops.
| ID | Technique | Description | Layer | ASI | ATLAS | Sev. |
|---|---|---|---|---|---|---|
| T-DEV.001 | Instruction Obfuscation | Encoding, fragmenting, or disguising instructions across multiple messages, languages, or modalities to avoid detection. | `L-INT, L-ORC` | `ASI01` | `AML.T0068` | High |
| T-DEV.002 | Behavioral Mimicry | Maintaining a compliant appearance normal tool usage, expected outputs while pursuing hidden unauthorized objectives. | `L-ORC` | `ASI10` | `AML.T0067` | Critical |
| T-DEV.003 | Log Suppression/Sanitization | Instructing the agent to skip logging, truncate audit trails, or generate clean-looking logs omitting evidence. | `L-ORC, L-TOO` | `ASI10` | `AML.T0092` | Critical |
| T-DEV.004 | Guardrail Probing & Adaptation | Systematically testing safety filters with boundary-pushing inputs to map and circumvent guardrail thresholds. | `L-INT, L-ORC` | `ASI01` | `AML.T0069` | High |
| T-DEV.005 | Staged Payload Delivery | Multi-phase attack: a benign payload establishes context and trust, and subsequent payloads leverage it for the actual attack. | `L-INT, L-MEM` | `ASI01, ASI06` | `AML.T0094` | High |
#### Detection guidance: T-DEV
| Technique | Detection approach |
|---|---|
| T-DEV.001 Instruction Obfuscation | Multi-turn conversation analysis, cross-message instruction reconstruction. |
| T-DEV.002 Behavioral Mimicry | Behavioral baseline comparison, output semantic analysis against declared goals, anomalous data-access patterns. |
| T-DEV.003 Log Suppression/Sanitization | Immutable logging infrastructure, log-completeness verification, external audit-trail comparison. |
| T-DEV.004 Guardrail Probing & Adaptation | Progressive-probing pattern detection, rate limiting on near-boundary inputs, guardrail trigger logging. |
| T-DEV.005 Staged Payload Delivery | Multi-session behavioral analysis, context-accumulation monitoring, cross-session anomaly correlation. |
## Persistence.
Establishing durable footholds that survive session resets, redeployments, or remediation of the initial vector.
The smallest tactic in AAT and the one that determines whether your incident response worked. Three of four techniques are critical, because each one describes a state in which the entry point has been closed and the compromise remains. Closing the vector is not the same as ending the incident, and agentic systems make that distinction unusually easy to miss: the agent looks fine, the logs are clean, and the poisoned memory or overwritten config is still there.
`T-PER.003`, scheduled re-injection, is the one to plan for explicitly. An attacker who establishes a recurring poisoned source (an RSS feed, a cron-triggered API pull, a synced folder) will re-compromise the system after your cleanup, on a schedule you did not set. And `T-PER.004`, self-replication via provisioning APIs, is the worst case: an agent with infrastructure permissions that spawns unauthorized replicas turns a containment exercise into a hunt. Kill-switch capability is not an optional feature at that point.
| ID | Technique | Description | Layer | ASI | ATLAS | Sev. |
|---|---|---|---|---|---|---|
| T-PER.001 | Memory Implantation | Injecting persistent backdoor instructions into long-term memory, conversation history, or user profiles. | `L-MEM` | `ASI06` | `AML.T0080.000` | Critical |
| T-PER.002 | Configuration Overwrite | Modifying agent config files, system prompts, or environment variables to persist malicious behavior across restarts. | `L-ORC, L-SUP` | `ASI10` | `AML.T0081` | Critical |
| T-PER.003 | Scheduled Re-Injection | Establishing a recurring data source poisoned RSS, cron API call that re-injects malicious content after cleanup. | `L-MEM, L-SUP` | `ASI06, ASI04` | `AML.T0099` | High |
| T-PER.004 | Self-Replication via Provisioning APIs | A compromised agent uses provisioning APIs to spawn unauthorized replicas across infrastructure. | `L-MAG, L-TOO` | `ASI10` | `AML.T0061` | Critical |
#### Detection guidance: T-PER
| Technique | Detection approach |
|---|---|
| T-PER.001 Memory Implantation | Memory integrity auditing, provenance verification on persistent data, periodic adversarial testing. |
| T-PER.002 Configuration Overwrite | Hash-based config-file integrity monitoring, immutable config in production, config-change alerting. |
| T-PER.003 Scheduled Re-Injection | Data-source provenance auditing, content scanning on periodic inputs, anomalous recurring-content detection. |
| T-PER.004 Self-Replication via Provisioning APIs | Agent provisioning controls, infrastructure monitoring for unexpected instances, kill-switch capabilities. |
## Threat scope and business risk.
Ten threat scope types classify what a finding costs the business. This is the dimension that survives translation to a board, an insurer, or a regulator, and it is the one that should drive remediation sequencing.
Severity and threat scope are not the same measurement and should never be collapsed into one number. Severity describes the technical potency of a technique. Threat scope describes the consequence in your environment. A medium-severity technique that lands in a regulated data flow outranks a critical-severity technique that lands in a sandbox with no data and no money attached. Where a tester is uncertain, threat scope is auto-assignable from layer and technique heuristics and confirmed at review, but it should be confirmed, because this is the field an executive reads.
| Threat type | Level | Definition | Business impact | ASI map |
|---|---|---|---|---|
| Unauthorized Action | | The agent executed a state-changing action without approval or outside its authorized scope. | Financial loss, legal liability, or physical asset damage. | `ASI01, ASI02` |
| Privilege Escalation | | Access to internal tools, data, or systems restricted from the current session, user, or agent role. | Internal data breach, lateral movement, unauthorized admin access. | `ASI03` |
| Data Exfiltration | | Sensitive context, system prompts, user data, or business information leaked via agent output or side channels. | IP theft, exposure of proprietary logic, customer data breach. | `ASI01, ASI02, ASI06` |
| Knowledge Corruption | | Agent reliability destroyed via persistent bias, poisoned knowledge, or corrupted state. | Loss of customer trust, degradation of service quality. | `ASI06` |
| Regulatory Breach | | Agent actions violate legal frameworks (GDPR, HIPAA, PCI-DSS, EU AI Act) or compliance policies. | Fines, sanctions, mandatory audit triggers, legal liability. | `ASI03, ASI06` |
| Resource Exhaustion | | Forced high compute costs, API quota depletion, or infrastructure overload. | Unexpected operational costs, denial-of-service. | `ASI02, ASI08` |
| Cascading System Failure | | A single compromised agent triggers chain-reaction failures across downstream systems. | Widespread outage, multi-system data corruption, incident response paralysis. | `ASI08` |
| Supply Chain Contamination | | A compromised upstream component propagates malicious behavior to all consumers. | Mass deployment of backdoored agents, organization-wide credential exposure. | `ASI04` |
| Human Manipulation | | Agent generates deceptive outputs that manipulate human decision-making. | Poor business decisions, fraudulent approvals, reputational damage. | `ASI09` |
| Behavioral Integrity Loss | | Agent appears compliant but pursues hidden objectives or drifts from intended behavior. | Undetectable long-term sabotage, corrupted decision pipelines. | `ASI10` |
### Using threat scope to sequence remediation
The four critical scopes (unauthorized action, cascading system failure, supply chain contamination, and, in regulated contexts, regulatory breach) share a property the others do not: the damage is not proportional to the number of findings. One instance is a complete event. A single supply chain contamination reaches every consumer at once. A single unauthorized fund transfer is a loss with no partial version. These should be treated as go/no-go gates on deployment rather than backlog items with a priority label.
The remaining scopes scale with exposure and are legitimately manageable as a queue. Knowledge corruption and resource exhaustion in particular are best handled with monitoring and budget controls rather than pre-launch remediation, provided the monitoring actually exists. Behavioral integrity loss is the awkward middle: it is rated high, it scales slowly, and it is the hardest to detect, which in practice means it is the one most often deferred and least often revisited.
Threat scope maps cleanly onto most existing enterprise risk taxonomies without a new register. Financial and operational loss, data protection, service availability, third-party risk, and conduct risk each have a home in the ten types above. Map them once, then let every AAT-classified finding inherit the mapping automatically.
## The AAT Coverage Matrix.
Layer-versus-tactic coverage across the Agent Attack Taxonomy
The two structural AAT dimensions form a grid. Each cell holds the number of techniques that can be exploited at that layer using that tactic. Read it twice: once as a map of AAT, and once (filled in with your own test results) as a map of what you have and have not tested.
| Layer | INM | LPS | TEE | MKP | MAC | ICE | SCC | HTE | DEV | PER | Total |
|---|---|---|---|---|---|---|---|---|---|---|---|
| L-INT | 5 | | | | | | | | 3 | | 8 |
| L-ORC | | 7 | | | | | | | 4 | 1 | 12 |
| L-MEM | 1 | | | 6 | 1 | 1 | | | 1 | 2 | 12 |
| L-TOO | | | 10 | | | | | | 1 | 1 | 12 |
| L-MAG | | 1 | | | 7 | 1 | 1 | | | 1 | 11 |
| L-IAM | | | 2 | | 1 | 6 | | 1 | | | 10 |
| L-SUP | | | 1 | | 1 | | 6 | | | 2 | 10 |
| L-HAB | | 1 | | | | | | 6 | | | 7 |
| Total | 6 | 9 | 13 | 6 | 10 | 8 | 7 | 7 | 9 | 7 | 82 |
### Reading the diagonal
The grid has a strong diagonal (each tactic concentrates on its home layer) and that is by design, not an artifact. What matters analytically is the off-diagonal mass. Twenty techniques span more than one layer, and those are the techniques that produce chained findings, cross team boundaries, and require two owners to remediate. If your programme reports on layers in isolation, those twenty are exactly the findings that will fall between two backlogs.
### Known thin spots
Two columns are honestly under-developed and are called out here rather than smoothed over. Reconnaissance has no dedicated tactic; it lives implicitly inside `T-DEV.004`, guardrail probing. A future revision is likely to promote discovery to a first-class tactic. Collection is similarly partial, covered indirectly through memory and exfiltration techniques rather than named as its own activity. Both gaps are documented in the MITRE ATLAS coverage assessment in Section 9.
### Turning the matrix into your coverage report
Replace the technique counts with your own test results and the same matrix becomes a programme dashboard. Three readings are worth building:
- **Tested versus untested.** Any cell with an AAT technique count above zero and a test count of zero is unexercised surface. Start there.
- **Findings density.** Cells where you test frequently and find repeatedly indicate a systemic weakness in that component, not bad luck.
- **Drift over time.** The same grid re-run quarterly shows whether remediation is holding. Rising counts in a previously clean cell usually means a new integration went in without review.
## Applying AAT: the A2OSF methodology.
AAT is the classification system. A2OSF, the Agentic AI Offensive Security Framework, is the operational methodology that wires it into attack creation, remediation, reporting, dashboards, and continuous testing.
A taxonomy that lives only in a PDF is a glossary; one made load-bearing across the security programme becomes an operating system for it. This section covers both the mechanics and a realistic adoption sequence.
### 8.1 How AAT and A2OSF are applied
| Stage | AAT classification | A2OSF application |
|---|---|---|
| Attack creation | **Required:** layer and technique. **Recommended:** threat scope, auto-assignable from layer and technique heuristics. **Auto-populated:** OWASP ASI reference, ATLAS ID, and CWE where mapped properties of the AAT technique, never entered by hand. | Constructs and executes the attack campaign against the running agent, then chains it further where the first step succeeds. |
| Risk & remediation | Layer identifies the component to harden. Technique identifies the pattern to mitigate. Threat scope prioritises urgency. | Produces the remediation and detection guidance, feeding each technique's detection approach from Section 5 straight into monitoring work. |
| Reporting | Standard finding identifiers: per-finding layer, technique, and threat-scope tags, with OWASP and ATLAS cross-references carried alongside. | Structures the evidence and coverage report, and supplies the methodology appendix that tells a reader how the findings were produced. |
| Dashboards & visualization | The coverage dimensions themselves: layer, tactic, technique, threat scope. | Measures gaps, findings density, and drift across campaigns the AAT Coverage Matrix, threat-scope distribution, and technique frequency ranking. |
### 8.2 A worked chain, end to end
AAT earns its keep on chained findings. The following sequence is a single incident, classified using AAT, and it shows why a per-step severity score would have understated it at every step.
Filed as five separate findings this is a busy quarter. Filed as one chained finding carrying five technique tags across four layers, it is a single reportable incident with a named root cause, four owners, and an unambiguous threat scope. AAT does not make the attack worse. It makes it legible.
### 8.3 A ninety-day AAT adoption sequence
Adoption fails in predictable ways: a taxonomy is announced, nobody is required to use it, and six months later half the findings are still free text. The sequence below is the shortest path that has held up in practice.
| Phase | Objective | What actually happens |
|---|---|---|
| Weeks 1-2 Inventory | Know what you have before you classify what breaks. | Enumerate every agent in production and pre-production. For each, record the layers that actually exist: does it have memory, does it call tools, does it talk to other agents, does it hold its own identity. Agents with no inventory entry cannot be tested and should not be in production. |
| Weeks 3-6 Baseline | Establish a first coverage grid with real results. | Run a baseline campaign against the two or three highest-value agents, covering every tactic rather than every technique. Depth comes later; the goal here is to fill the grid and find the empty columns. Expect the human-agent boundary and supply chain columns to be the emptiest. |
| Weeks 7-12 Wire it in | Make the tags load-bearing. | Require AAT layer and technique IDs on every finding in the tracker vendor findings included. Map threat scope to your existing risk register once. Turn the detection guidance for your top ten techniques into monitoring backlog items with owners. Publish the coverage grid to the same audience that sees vulnerability metrics. |
| Ongoing Continuous | Re-test on change, not on calendar. | Every new tool, every new integration, every model swap, and every prompt change re-opens the surface. Trigger campaigns on deployment events, and re-run the full grid quarterly so drift is visible. A coverage report that only moves when someone remembers to run it is not a control. |
### 8.4 Three failure modes to avoid
- **Classifying without measuring coverage.** Tagging findings is half the value. The other half is the empty cells, and those only appear if you also record what you tested and found nothing.
- **Letting vendors file free text.** Require AAT layer and technique IDs on every finding, including findings from external vendors. If an external tester's report does not carry `L-` and `T-` tags, someone on your side will retro-fit them badly or not at all. Put the requirement in the statement of work.
- **Treating detection guidance as commentary.** Each technique's detection approach is a specific, buildable control. Findings get remediated; the detection gap that let it go unnoticed usually does not, and that is the gap that matters on the next attempt.
## Standards alignment and cross-maps.
AAT is designed to be self-contained while remaining fully mappable outward. Nothing in this section requires you to adopt AAT as your primary language: the cross-maps exist so that a finding classified once can be reported in whichever vocabulary the reader needs.
### 9.1 OWASP Top 10 for Agentic Applications: reverse map
Every one of the 62 AAT techniques carries an ASI reference. The table below inverts that relationship: given an ASI category, which techniques test it. This is the view a compliance team needs, and it is the fastest way to answer "are we covered for ASI04" with something other than an opinion.
| ASI | Name | AAT technique IDs | # |
|---|---|---|---|
| ASI01 | Agent Goal Hijack | `T-INM.001, T-INM.002, T-INM.003, T-INM.004, T-INM.005, T-LPS.001, T-LPS.003, T-DEV.001, T-DEV.004, T-DEV.005` | 10 |
| ASI02 | Tool Misuse & Exploitation | `T-TEE.001, T-TEE.002, T-TEE.003, T-TEE.005, T-TEE.006, T-TEE.009, T-TEE.010` | 7 |
| ASI03 | Identity & Privilege Abuse | `T-LPS.004, T-TEE.002, T-TEE.004, T-ICE.001, T-ICE.002, T-ICE.003, T-ICE.004, T-ICE.005, T-ICE.006` | 9 |
| ASI04 | Supply Chain Vulnerabilities | `T-TEE.005, T-SCC.001, T-SCC.002, T-SCC.003, T-SCC.004, T-SCC.005, T-SCC.006, T-PER.002, T-PER.003` | 9 |
| ASI05 | Unexpected Code Execution | `T-TEE.001, T-TEE.007, T-TEE.008` | 3 |
| ASI06 | Memory & Context Poisoning | `T-MKP.001, T-MKP.002, T-MKP.003, T-MKP.004, T-MKP.005, T-MKP.006, T-DEV.005, T-PER.001, T-PER.003` | 9 |
| ASI07 | Insecure Inter-Agent Comms | `T-MAC.001, T-MAC.002, T-MAC.003, T-MAC.004, T-MAC.005, T-MAC.006, T-MAC.007` | 7 |
| ASI08 | Cascading Failures | `T-LPS.002, T-LPS.005, T-LPS.006` | 3 |
| ASI09 | Human-Agent Trust Exploitation | `T-LPS.006, T-HTE.001, T-HTE.002, T-HTE.003, T-HTE.004, T-HTE.005, T-HTE.006` | 7 |
| ASI10 | Rogue Agents | `T-LPS.007, T-MKP.003, T-MAC.001, T-MAC.005, T-ICE.004, T-SCC.004, T-DEV.002, T-DEV.003, T-PER.002, T-PER.004` | 10 |
### 9.2 MITRE ATLAS: kill-chain coverage assessment
Where the OWASP map is about categories, the ATLAS map is about the adversary lifecycle. The assessment below states honestly where AAT is strong, where it is adequate, and where it is thin. Two tactics are marked partial and are not dressed up. Per-technique IDs are mapped against MITRE ATLAS v6 (release 2026.06), which introduced a dedicated agentic technique set; 45 of the 62 techniques resolve to a v6 technique and the remaining 17 describe agentic behaviors ATLAS does not yet name.
| ATLAS tactic | AAT coverage | Status |
|---|---|---|
| Reconnaissance | Implicit in `T-DEV.004` guardrail probing. A dedicated discovery tactic is a recommended future extension. | Partial |
| Resource Development | `T-SCC` covers malicious tooling and infrastructure preparation. | Covered |
| Initial Access | `T-INM` (5 techniques) plus `T-SCC` provide comprehensive coverage. | Strong |
| Execution | `T-TEE` (10 techniques) provides deep execution coverage. | Strong |
| Persistence | `T-PER` (4 techniques) plus `T-MKP.001` and `T-MKP.003` cover persistence mechanisms. | Strong |
| Privilege Escalation | `T-ICE` (6 techniques) plus `T-TEE.002` and `T-TEE.004` are comprehensive. | Strong |
| Defense Evasion | `T-DEV` (5 techniques) provides dedicated evasion coverage. | Strong |
| Credential Access | `T-ICE.002`, `.004`, `.005`, and `.006` cover credential compromise. | Covered |
| Lateral Movement | `T-MAC` (7 techniques) covers multi-agent pivoting. | Strong |
| Collection | Partially addressed via `T-MKP` and the exfiltration techniques. | Partial |
| Exfiltration | `T-TEE.006` and `T-TEE.009` cover exfiltration methods; threat scope covers impact. | Covered |
| Impact | Threat scope (Section 6) comprehensively covers all impact categories. | Strong |
### 9.3 Governance and regulatory frameworks
The three cross-maps below are indicative alignment notes, not certification claims. They connect the AAT threat scope dimension to the risk vocabulary used by NIST AI RMF 1.0, ISO/IEC 42001:2023, and the EU AI Act, so that a technical finding can be routed to the right governance obligation without a translation meeting. Direct control-by-control mapping tables are a planned extension; treat this as the bridge until they land, and confirm applicability with your own compliance function.
| Threat scope | NIST AI RMF 1.0 | ISO/IEC 42001:2023 | EU AI Act |
|---|---|---|---|
| Unauthorized Action | MANAGE response and recovery planning for AI systems in operation | Annex A operational controls for AI system use and change management | Art. 14 human oversight; Art. 26 deployer obligations |
| Privilege Escalation | MEASURE AI system security and resilience evaluated and documented | Annex A controls on AI system life cycle and access | Art. 15 accuracy, robustness and cybersecurity |
| Data Exfiltration | MAP and MEASURE data provenance, privacy and security risks characterized | Annex A data management and information for interested parties | Art. 10 data governance; Art. 15 cybersecurity |
| Knowledge Corruption | MEASURE validity, reliability and accuracy tracked over time | Annex A verification and validation of AI systems | Art. 15 accuracy and robustness |
| Regulatory Breach | GOVERN legal and regulatory requirements understood and managed | Clause 4 and 6 context, obligations and AI risk assessment | Art. 9 risk management system; Art. 12 record-keeping |
| Resource Exhaustion | MANAGE resource allocation and residual risk documented | Annex A resource and operational planning for AI systems | Art. 15 robustness against faults and misuse |
| Cascading System Failure | MANAGE incident response, fallback and disengagement mechanisms | Annex A AI system life cycle and operational monitoring | Art. 9 risk management; Art. 14 human oversight and stop function |
| Supply Chain Contamination | MAP and GOVERN third-party components and risks inventoried | Annex A third-party and supplier relationships for AI systems | Art. 25 responsibilities along the AI value chain |
| Human Manipulation | MEASURE human-AI interaction and configuration assessed | Annex A information provided to users and interested parties | Art. 14 human oversight; Art. 50 transparency obligations |
| Behavioral Integrity Loss | MEASURE and MANAGE ongoing monitoring for emergent behavior | Annex A performance monitoring and continual improvement | Art. 72 post-market monitoring; Art. 55 systemic-risk model testing |
### 9.4 Frameworks reachable transitively
- **OWASP LLM Top 10 (2025).** Reachable through the OWASP ASI mapping matrix, which itself maps ASI categories to the LLM Top 10. AAT does not duplicate that hop.
- **CWE.** Per-technique CWE mappings are a planned extension for techniques with traditional software parallels: `T-TEE.001` to CWE-918 server-side request forgery, `T-TEE.008` to CWE-502 unsafe deserialization, and similar.
- **AIUC-1 and sector schemes.** Where an assurance scheme asks for adversarial testing evidence, the AAT Coverage Matrix plus per-finding technique tags is generally the artifact requested. It is produced as a by-product of running A2OSF rather than assembled for the audit.
## Observed agent attacks, classified with AAT.
A taxonomy is only as good as its fit against reality. Fourteen publicly documented incidents from February to October 2025, drawn from the OWASP ASI exploits and incidents tracker, classified using AAT with no forcing and no gaps.
| Date | Incident | Layer | Technique(s) | OWASP ASI |
|---|---|---|---|---|
| Oct 2025 | Malicious MCP package backdoor (NPM dual reverse shells) | `L-SUP` | `T-SCC.006` | `ASI04` |
| Oct 2025 | Framelink Figma MCP RCE (unsanitized input) | `L-TOO` | `T-TEE.001, T-TEE.007` | `ASI02, ASI05` |
| Sep 2025 | Malicious MCP impersonating Postmark (BCC exfiltration) | `L-SUP, L-TOO` | `T-SCC.003, T-TEE.005` | `ASI02, ASI04` |
| Sep 2025 | ForcedLeak: Salesforce Agentforce CRM exfiltration | `L-INT, L-TOO` | `T-INM.002, T-TEE.002` | `ASI01, ASI02, ASI03` |
| Sep 2025 | VS Code agentic AI workflows RCE | `L-INT, L-TOO` | `T-INM.002, T-TEE.007` | `ASI01, ASI05` |
| Jul 2025 | Amazon Q prompt poisoning (file-wipe risk) | `L-SUP, L-INT` | `T-SCC.001, T-INM.002` | `ASI01, ASI04` |
| Jul 2025 | Google Gemini CLI file loss (directory wiped) | `L-ORC, L-TOO` | `T-TEE.007, T-LPS.001` | `ASI01, ASI05` |
| Jul 2025 | Replit vibe-coding meltdown (DB deleted, false outputs) | `L-ORC, L-HAB` | `T-LPS.001, T-HTE.001` | `ASI01, ASI09` |
| Jul 2025 | Copilot Studio: agents public by default | `L-IAM` | `T-ICE.001` | `ASI03` |
| Jun 2025 | Heroku MCP app ownership hijack | `L-IAM, L-TOO` | `T-ICE.001, T-TEE.002` | `ASI02, ASI03` |
| May 2025 | EchoLeak: zero-click Copilot data exfiltration | `L-INT, L-TOO` | `T-INM.002, T-TEE.006` | `ASI01, ASI02` |
| Apr 2025 | Agent-in-the-middle (A2A protocol spoofing) | `L-MAG, L-SUP` | `T-MAC.005, T-SCC.004` | `ASI04, ASI07, ASI10` |
| Mar 2025 | GitHub Copilot code-agent exploit (backdoor injection) | `L-SUP, L-HAB` | `T-SCC.005, T-HTE.001` | `ASI04, ASI09` |
| Feb 2025 | ChatGPT Operator vulnerability (web prompt injection) | `L-INT, L-IAM` | `T-INM.002, T-ICE.001` | `ASI01, ASI03` |
### What the sample tells you
Three patterns are worth stating plainly, with the caveat that fourteen incidents is a sample of what became public, not a census of what happened.
`T-INM.002` is the single most frequent technique in the sample. The entry point is almost never the chat box.
Real incidents chain. Single-layer findings are a testing artifact, not a description of how systems fail.
MCP servers, packages, templates and registries. The layer most programmes leave out of scope is already the busiest.
The last of those deserves emphasis for anyone planning next quarter's testing. Supply chain is the layer testing programmes are least likely to have in scope, and in a fourteen-incident public sample it appears in five. If your agentic testing programme currently scopes only the agents you built, it is scoped to a minority of the observed incidents.
## AAT Quick Reference Card.
Three steps, three questions each. This page is designed to be printed on its own and kept beside the tester.
### Step 1: identify the layer. Where was the issue?
| ID | Layer | Key question |
|---|---|---|
| L-INT | Interface | Was the vulnerability in the user-facing input surface or data ingestion path? |
| L-ORC | Orchestration | Was the vulnerability in the planner, router, or decision-making logic? |
| L-MEM | Memory | Was the vulnerability in context, RAG, vector DB, or stored state? |
| L-TOO | Tooling | Was the vulnerability in a tool, API, sandbox, or execution environment? |
| L-MAG | Multi-Agent | Was the vulnerability in inter-agent communication, trust, or coordination? |
| L-IAM | Identity & Access | Was the vulnerability in credentials, permissions, delegation, or agent identity? |
| L-SUP | Supply Chain | Was the vulnerability in an upstream dependency, registry, template, or plugin? |
| L-HAB | Human-Agent Boundary | Was the vulnerability in HITL controls, approval flows, or trust signals? |
### Step 2: identify the tactic and technique. How was it exploited?
| Tactic | Name | # | Key question |
|---|---|---|---|
| T-INM | Input Manipulation | 5 | Did the attack manipulate inputs to alter agent behavior? |
| T-LPS | Logic & Planning Subversion | 7 | Did the attack subvert the agent's reasoning or planning? |
| T-TEE | Tool & Environment Exploitation | 10 | Did the attack exploit tools, execution environments, or their interactions? |
| T-MKP | Memory & Knowledge Poisoning | 6 | Did the attack corrupt stored knowledge, context, or state? |
| T-MAC | Multi-Agent Exploitation | 7 | Did the attack exploit inter-agent communication or trust? |
| T-ICE | Identity & Credential Exploitation | 6 | Did the attack abuse identity, credentials, or delegation? |
| T-SCC | Supply Chain Compromise | 6 | Did the attack compromise an upstream component or dependency? |
| T-HTE | Human Trust Exploitation | 6 | Did the attack manipulate human oversight or decision-making? |
| T-DEV | Defense Evasion | 5 | Did the attack evade detection, guardrails, or monitoring? |
| T-PER | Persistence | 4 | Did the attack establish a persistent foothold? |
### Step 3: assign threat scope. What is the business impact?
| Threat type | Level | Key indicator |
|---|---|---|
| Unauthorized Action | | Agent executed a state-changing action without approval. |
| Privilege Escalation | | Access to restricted tools, data, or systems. |
| Data Exfiltration | | Sensitive data leaked via output or side channels. |
| Knowledge Corruption | | Agent reliability degraded via poisoned knowledge. |
| Regulatory Breach | | Agent actions violated legal or compliance frameworks. |
| Resource Exhaustion | | Forced high costs or infrastructure overload. |
| Cascading System Failure | | Single failure triggered a chain reaction across systems. |
| Supply Chain Contamination | | Compromised component propagated to all consumers. |
| Human Manipulation | | Agent manipulated human decision-making. |
| Behavioral Integrity Loss | | Agent appeared compliant but pursued hidden objectives. |