MITRE ATLAS for Agentic AI: Mapping Agent & MCP Attacks

MITRE ATLAS is a free, community-built knowledge base of adversary tactics and techniques against AI and machine learning systems, maintained by the MITRE Center for Threat-Informed Defense and structured the same way MITRE ATT&CK is: tactics organize the adversary's goals, techniques and sub-techniques describe how those goals get achieved, and each technique links to documented mitigations and real-world case studies. As an adversarial ML threat taxonomy, this guide covers MITRE ATLAS agentic AI coverage, specifically how the matrix has expanded to account for autonomous agents and MCP-connected systems, and where real gaps remain. If you want the full relationship between ATLAS and its parent framework, that's covered on our ATT&CK page. What matters most for anyone securing agentic systems right now is a framing that gets lost constantly: ATLAS is the threat vocabulary, not the control layer. It tells you what an adversary does. It doesn't tell you what to build to stop them.

What is MITRE ATLAS, and How Is It Structured?

ATLAS exists because ATT&CK, built for traditional enterprise IT, has no native way to describe an attack against a model, a prompt, or an autonomous agent. Its core structure of ATLAS tactics, techniques, mitigations, and case studies underneath each one is what turns that description into something a security team can actually act on.

Tactics, Techniques, Mitigations, and Case Studies

As of the v5.1.0 release in November 2025, ATLAS spans 16 tactics, roughly 84 techniques and 56 sub-techniques, 32 mitigations, and 42 real-world case studies, with continued expansion through further 2026 updates since. That combination of MITRE ATLAS tactics and techniques, mitigations, and case studies is what makes the framework operational rather than theoretical: every documented technique traces to something that actually happened. Most tactics carry over from ATT&CK with an AI-specific spin, Reconnaissance, Initial Access, Persistence, Exfiltration. Two are entirely new to ATLAS: AI Model Access and AI Attack Staging, added specifically because neither has a meaningful ATT&CK equivalent. A Command and Control tactic was formalized in the same November 2025 release, reflecting how often adversaries now use AI infrastructure itself as the channel for issuing commands. The MITRE ATLAS case studies behind each technique are what separate this framework from a generic list of theoretical risks, since every entry maps back to documented, real-world incident research rather than a hypothetical scenario.

How ATLAS Relates to MITRE ATT&CK

Framed as MITRE ATLAS vs ATT&CK, the two share a lifecycle framing, and if you already read ATT&CK, ATLAS is readable on day one. The distinction is scope: ATT&CK catalogs adversary behavior against conventional networks, endpoints, and applications. ATLAS catalogs adversary behavior against the AI-specific layer sitting on top of, or increasingly acting within, that same infrastructure. In practice, an attack chain often crosses both: a prompt injection technique from ATLAS might hand off to a conventional ATT&CK technique, like credential dumping, the moment an agent's tool access reaches a normal enterprise system.

How ATLAS Has Expanded for Agentic AI

For its first several years, ATLAS was read almost entirely as a model-attack reference: adversarial examples, data poisoning, model extraction. Agentic AI broke that framing wide open, and MITRE ATLAS agent security coverage has been the fastest-growing part of the matrix ever since.

The October 2025 Zenity Labs Collaboration

In October 2025, Zenity Labs contributed 14 new agent-focused techniques and sub-techniques to ATLAS, drawn from Zenity's own GenAI Attacks Matrix research, along with a new case study documenting a real-world attack. That collaboration was the inflection point that pushed ATLAS from a model-evasion glossary toward a framework that actually accounts for autonomous agents calling tools, holding credentials, and acting across systems on their own. MITRE's first 2026 update extended that work further, and Zenity's research has continued contributing agent-specific techniques and case studies into 2026 releases since.

Named Agent-Specific Techniques (Credential Harvesting, Clickbait, Poisoned Tools)

Several of the newly named techniques describe attack patterns that security teams have been seeing in production, without a formal name for them. AI agent tool credential harvesting describes an attacker abusing an agent's own connected tools to retrieve secrets, tokens, and API keys from adjacent systems, exploiting the broad tool access agents are often given specifically so they can act without constant human approval. The risk here is structural rather than incidental: once an attacker reaches the tool boundary, the agent itself becomes a shortcut into whatever adjacent identities and services those tools can reach. AI agent clickbait formalizes a distinct risk for agentic browsers: content engineered to manipulate an autonomous browsing agent into taking an unintended action, the agent equivalent of a phishing link, except the target reading it is the agent rather than a human, and the agent has no instinct to hesitate the way a cautious human might. Publish Poisoned AI Agent Tool, added in the February 2026 v5.4.0 release, names the rug-pull pattern directly: a tool that behaves honestly when first published and approved, then gets modified afterward to act maliciously once trust has already been established, exploiting the fact that most teams review a tool once rather than continuously.

The New AI Service API Technique and Command-and-Control Risk

The AI Service API technique was added specifically in response to a real incident: the SesameOp case study, where a legitimate AI service API became the covert channel adversaries used to issue commands and receive responses, rather than relying on traditional command-and-control infrastructure. That pattern, hiding malicious coordination inside what looks like ordinary AI service traffic, is precisely why Command and Control was formalized as its own ATLAS tactic in the same release cycle.

Mapping Agent and MCP Attacks to the ATLAS Matrix

Translating ATLAS's named techniques onto an actual agent or MCP-connected deployment means knowing exactly where current coverage is strong and where it isn't yet. Mapping MITRE ATLAS MCP attacks specifically is the hardest part of this exercise right now, precisely because of the gap covered below.

Where MCP Risk Currently Lives, and the Gap in Named Coverage

There is no MCP-named technique in ATLAS yet. MCP-specific risk is currently covered implicitly, folded into broader categories such as AI Agent security Tools, Tool Definitions, and AI Agent Tool Invocation, rather than being broken out under an "MCP" label of its own. That's a real gap for any team trying to map MCP server exploitation, tool poisoning through a compromised MCP connection, or unauthorized MCP server discovery directly onto the matrix. Until MITRE names MCP-specific sub-techniques explicitly, security teams need to consciously map MCP risk onto the closest existing agent-tool categories rather than assuming a clean, dedicated entry already exists.

Exfiltration via Tool Invocation

Exfiltration via AI Agent Tool Invocation (AML.T0086) documents how an agent's own legitimate tool access becomes the exfiltration path: rather than an attacker pulling data out through a separate channel, the compromised or manipulated agent uses a tool it was already authorized to call, an email client, a file-sharing integration, a database query tool, to move data out through infrastructure that looks completely normal from the outside.

Context and Memory Poisoning Techniques

Context and memory poisoning techniques cover two related but distinct patterns: manipulating the context an agent's LLM reads within a single session to steer its immediate responses or tool calls, and altering an agent's persistent memory so a malicious change survives across future sessions entirely. Both produce a specific kind of signal for defenders: not one alarming event, but a gradual behavioral drift as the agent's reasoning gets shaped across sessions by content it was never supposed to fully trust.

Case Studies Worth Knowing

ATLAS case studies exist precisely because named techniques are easier to operationalize once there's a concrete, documented incident behind them.

SesameOp: A Backdoor via the OpenAI Assistants API

SesameOp (AML.CS0042) documents a backdoor that repurposed the OpenAI Assistants API as a covert command-and-control channel. Rather than standing up separate C2 infrastructure an attacker would need to hide, the technique blended malicious coordination into legitimate-looking AI service traffic, using agent APIs and assistant logic to issue commands and receive responses. It's the case study that directly inspired the AI Service API technique described above.

Financial Transaction Hijacking with an AI Assistant as Insider

This case study documents an attacker performing a Remote Copilot Execution attack against Microsoft 365 Copilot, taking control of the assistant's capabilities without ever needing a compromised user account. In the documented scenario, an attacker intercepts a user's request for vendor bank details inside Copilot and, through prompt manipulation, injects a fraudulent response containing the attacker's own banking details alongside legitimate-looking supporting files. The victim, trusting an assistant they had no reason to doubt, transfers funds directly to the attacker.

The January 2026 MCP Server Compromise Case Study

Added to ATLAS in January 2026, this case study documents a real attack against Model Context Protocol infrastructure specifically, the clearest existing example of MCP risk inside the matrix even without a dedicated named technique yet. It's the case study worth pointing to today when mapping MCP-specific incidents onto ATLAS, precisely because it fills part of the gap the missing named MCP technique otherwise leaves open.

ATLAS Is the Threat Side, Not the Control Side

Knowing every technique in the matrix doesn't, by itself, secure anything. ATLAS describes what adversaries do. Closing the gap requires pairing it with frameworks that describe what defenders should build.

How ATLAS Pairs with NIST AI RMF, OWASP, and ISO 42001

ATLAS complements rather than competes with the NIST AI RMF, the OWASP Top 10 for LLM and Agentic Applications, and ISO/IEC 42001. Thought of as ATLAS vs NIST AI RMF, or ATLAS vs OWASP LLM Top 10, the comparison is really a division of labor rather than a competition: pair ATLAS with NIST's Measure function for quantifying risk, OWASP's lists for application-level vulnerability coverage specific to LLMs and agents, and ISO 42001 for the certifiable governance structure wrapping all of it. Roughly 70% of ATLAS's own documented mitigations map onto security controls organizations already run, which is exactly the point: ATLAS gives you the threat model vs control framework distinction in its clearest form, a shared vocabulary for adversary behavior that other frameworks then tell you how to actually defend against.

Why You Can't Operationalize ATLAS Without an Agent/MCP Inventory First

Most of ATLAS's Discovery, Credential Access, and Exfiltration techniques assume a defender already knows what agents and MCP servers exist in their environment. The agent inventory prerequisite isn't optional: asking whether a specific technique like Exfiltration via AI Agent Tool Invocation is covered has no real answer until you know which agents hold which tool access in the first place. Teams that jump straight to red teaming against ATLAS techniques without a current agent and MCP inventory end up testing a fraction of their actual exposure, the same agents they already knew about, while shadow agents and undocumented MCP connections stay completely untested.

Using ATLAS in Practice for Red Teaming and Threat Modeling

ATLAS earns its keep as an input to structured testing, not as a checklist to complete once. Threat modeling against a specific agent or MCP-connected application should walk through the matrix and ask, technique by technique, whether that specific system is exposed: can context or memory be poisoned across this agent's sessions, can its tool access become an exfiltration path, does a compromised MCP connection give an attacker a foothold the rest of the deployment would trust implicitly. Red teaming should then chain techniques the way a real adversary would rather than testing each in isolation, since ATLAS's own case studies almost always show a multi-step chain, prompt manipulation into tool misuse into exfiltration, rather than a single-technique attack. Free tools like ATLAS Navigator and Arsenal make this workable without building tooling from scratch, letting a team model an attack path and identify which mitigations from the matrix actually apply to it.

How Akto Maps to MITRE ATLAS

Akto's continuous discovery of AI agents, LLM applications, and MCP server connections builds the inventory that ATLAS's own Discovery and Credential Access techniques already assume exists, closing the exact prerequisite gap most teams hit first. Ongoing red teaming targets the named agent-specific techniques directly, credential harvesting, context and memory poisoning, tool misuse, and exfiltration via tool invocation, chaining them the way a real adversary would rather than testing each in isolation. Because ATLAS doesn't yet name MCP-specific techniques explicitly, Akto's MCP-aware testing covers that current gap directly, mapping findings back to the closest existing ATLAS categories until the matrix catches up. Findings feed into runtime guardrails that enforce the deterministic controls ATLAS itself doesn't specify, turning threat-side coverage into an actual control-side response.

Frequently Asked Questions: MITRE ATLAS for Agentic AI

1. What is MITRE ATLAS, and how is it structured?

MITRE ATLAS is a free, living knowledge base of adversary tactics and techniques against AI and machine learning systems, structured like MITRE ATT&CK: tactics organizing adversary goals, techniques and sub-techniques describing how those goals are achieved, and each technique linked to mitigations and real-world case studies.

2. How is MITRE ATLAS different from MITRE ATT&CK?

ATT&CK catalogs adversary behavior against conventional enterprise IT. ATLAS catalogs adversary behavior specific to AI and ML systems, including two tactics with no ATT&CK equivalent, AI Model Access and AI Attack Staging, though the two frameworks share the same lifecycle structure and often chain together in a real attack.

3. Has MITRE ATLAS added techniques specifically for AI agents?

Yes. The October 2025 Zenity Labs collaboration added 14 agent-focused techniques and sub-techniques, covering context and memory poisoning, credential harvesting, tool misuse, and exfiltration via tool invocation, with further agent-specific techniques added in subsequent 2026 releases.

4. Does MITRE ATLAS have a dedicated technique for MCP-specific attacks?

Not yet. MCP risk is currently covered implicitly through broader categories like AI Agent Tools and AI Agent Tool Invocation, plus a January 2026 case study documenting a real MCP server compromise, but there's no MCP-named technique in the matrix as of now.

5. What is the "AI Service API" technique, and why was it added?

It describes adversaries repurposing a legitimate AI service API as a covert command-and-control channel instead of standing up separate C2 infrastructure. It was added directly in response to the SesameOp case study, which documented exactly this pattern using the OpenAI Assistants API.

6. What is the SesameOp case study, and what does it demonstrate?

SesameOp (AML.CS0042) documents a backdoor that used the OpenAI Assistants API to issue commands and receive responses, blending malicious coordination into legitimate-looking AI service traffic rather than relying on traditional, more detectable C2 infrastructure.

7. What is "Publish Poisoned AI Agent Tool," and how does it relate to MCP risk?

Added in the February 2026 ATLAS update, it names the pattern where a tool behaves honestly when first published and approved, then gets modified afterward to act maliciously. It's directly relevant to MCP risk since this is exactly how a compromised or rug-pulled MCP tool typically operates.

8. Is MITRE ATLAS a replacement for NIST AI RMF or OWASP's LLM Top 10?

No. ATLAS is a threat taxonomy describing adversary behavior. NIST AI RMF and OWASP's lists describe governance structure and application-level risk categories, respectively. The three are meant to be used together, not as substitutes for one another.

9. What do you need in place before you can operationalize ATLAS for agent security?

A current, continuously updated inventory of every agent and MCP server in the environment. Most of ATLAS's Discovery, Credential Access, and Exfiltration techniques assume you already know what exists, so testing against the matrix without that inventory only covers agents you already knew about.

10. How does Akto map its red teaming and detection coverage to MITRE ATLAS?

Akto's continuous agent and MCP discovery supplies the inventory ATLAS assumes; its red-teaming targets named techniques like credential harvesting and context poisoning directly; and its runtime guardrails supply the control-side enforcement that ATLAS itself, as a threat framework, doesn't specify.