MITRE ATT&CK and ATLAS Agentic Gap Analysis: Techniques Unique to Autonomous Agent Control Planes

Research Note | 2026-03-27 | Status: draft

MITRE ATT&CK and ATLAS Agentic Gap Analysis: Techniques Unique to Autonomous Agent Control Planes

Key Takeaways

  • MITRE ATLAS v5.x contains 15 tactics, 66 techniques, and 46 sub-techniques, but explicitly excludes lateral movement and command-and-control as tactics — a design choice that creates coverage gaps when agents operate as persistent, networked actors within multi-agent systems.
  • Six technique categories have no adequate representation in ATLAS: agent-to-agent lateral movement, tool-chain poisoning, orchestrator hijacking, credential relay through delegation chains, cross-session memory persistence, and MCP server compromise as a pivot point.
  • Each gap technique maps to one or more MAESTRO architecture layers, AICM v1.0 control domains, and OWASP ASI categories, enabling organizations to apply mitigations today even in the absence of formal ATLAS entries.
  • MITRE accepts community technique contributions through GitHub pull requests against the atlas-data repository in STIX 2.1 format; this document is structured to accelerate that submission process.

Background

The Evolution of MITRE ATLAS for Agentic Systems

MITRE ATLAS (Adversarial Threat Landscape for AI Systems) was created to complement ATT&CK by cataloguing techniques that are uniquely relevant to AI and machine learning systems — attacks that manipulate models through adversarial inputs, exploit training pipelines, or abuse inference interfaces in ways that have no direct analog in conventional network attack taxonomies [1]. For the first several years of its existence, ATLAS reflected the threat landscape as it applied primarily to ML models and their supporting data pipelines: prompt injection, model inversion, membership inference, and data poisoning were the core concerns, with case studies drawn largely from academic research settings.

The September 2025 release of ATLAS v5.0.0 introduced the “Technique Maturity” field, providing a more rigorous classification of evidential confidence for each technique [2]. More consequentially, the October 2025 collaboration between MITRE and Zenity Labs added fourteen new techniques and sub-techniques oriented explicitly toward AI agent security rather than model security alone [3]. These additions — including AI Agent Context Poisoning (AML.T0080), Modify AI Agent Configuration (AML.T0081), RAG Credential Harvesting (AML.T0082), and Exfiltration via AI Agent Tool Invocation (AML.T0086) — mark a meaningful shift in the framework’s scope. As agentic systems increasingly interact with real tools, credentials, memory stores, and external services, the attack surface extends well beyond the model inference layer, and ATLAS has begun to reflect this reality.

By early 2026, MITRE’s own OpenClaw investigation — triggered by the disclosure of CVE-2026-25253 and CVE-2026-24763 — identified seven new techniques observable in real-world exploitation of agentic platforms, further accelerating community contribution activity [4]. The OpenClaw CVEs, which allowed attackers to steal authentication tokens via CSRF and execute arbitrary commands through improperly sanitized input fields, demonstrated that agentic systems can be exploited through mechanisms that blend traditional web attack patterns with novel agent-specific trust relationships. The MITRE investigation characterized these techniques as “fairly mature,” having been demonstrated or realized elsewhere in the wild, reinforcing the urgency of systematic gap analysis.

What ATLAS Still Misses

Despite this progress, ATLAS retains a structural limitation that directly bears on multi-agent architectures: the framework intentionally excludes lateral movement and command-and-control as tactics. This exclusion was a design decision made when the primary threat model concerned a single AI system being attacked by an external adversary. The decision made sense in that context. It no longer makes sense when the adversary can compromise one agent and use it as a foothold to attack, instruct, or impersonate other agents in the same orchestration layer — a scenario that is now routine in enterprise agentic deployments.

Similarly, the ATLAS framework has not yet addressed the control-plane layer that governs how agents receive tasks, route outputs, invoke tools, and establish identity. Techniques that exploit orchestration metadata, delegation token chains, or protocol-level infrastructure such as the Model Context Protocol (MCP) have no ATLAS home. The OWASP Top 10 for Agentic Applications, released in December 2025, explicitly identifies insecure inter-agent communication (ASI07), identity and privilege abuse (ASI03), and agentic supply chain vulnerabilities (ASI04) as top-tier risks [5] — yet none of these risks is fully represented in ATLAS’s current technique inventory. This gap analysis addresses that discrepancy directly.

Gap Analysis Methodology

The analysis begins with ATT&CK v16 Enterprise, which organizes 216 techniques and 475 sub-techniques across 14 tactics applicable to Windows, macOS, Linux, cloud, and container platforms [6]. For each ATT&CK tactic — from Reconnaissance through Impact — the authors asked a structured question: are there behaviors specific to multi-agent control planes that instantiate this tactic, cannot be fully described by existing ATLAS techniques, and represent a meaningfully distinct threat that would require different detections and mitigations from anything already in the framework?

The analysis was bounded to multi-agent systems with persistent orchestration layers — deployments in which at least one “meta-agent” coordinates the actions of sub-agents, where inter-agent communication occurs over a defined protocol, and where agents operate with delegated credentials or tool permissions that extend beyond the scope of a single user session. Consumer-facing chatbot deployments and single-model inference endpoints were explicitly excluded, as they are already well-served by existing ATLAS coverage.

For each candidate technique, the authors verified that no existing ATLAS entry provides adequate coverage. In cases where a partial match exists — for example, where AI Agent Context Poisoning (AML.T0080) touches on related concepts — the analysis explains why the gap technique represents a distinct attack pattern requiring its own specification rather than a sub-technique of the existing entry. Each proposed technique was then mapped to MAESTRO’s seven-layer architecture [7], AICM v1.0’s eighteen control domains [8], and the OWASP ASI Top 10 categories [5], to situate the technique within the broader defensive landscape that practitioners are already using.

Six Gap Technique Specifications

Technique 1: Agent-to-Agent Lateral Movement

Proposed ATLAS ID: AML.T0090 (candidate)
Tactic: Lateral Movement (proposed new ATLAS tactic)
ATT&CK Analog: Lateral Movement (TA0008) — most closely related to Remote Services (T1021) and Use Alternate Authentication Material (T1550), though neither captures the agent-native trust model

Description. In a multi-agent system, individual agents typically hold authenticated sessions, registered tool permissions, and access credentials scoped to their designated function. An adversary who compromises one agent — through prompt injection, configuration manipulation, or exploitation of a platform vulnerability such as CVE-2026-25253 — can use that agent’s existing trust relationships to initiate connections to, issue instructions to, or impersonate other agents operating in the same orchestration environment. This is structurally analogous to lateral movement in network intrusion scenarios, but it operates entirely within the agent communication layer rather than across network segments.

Agent-to-agent lateral movement is distinct from the existing ATLAS technique of AI Agent Context Poisoning (AML.T0080), which describes manipulation of a single agent’s context to alter its behavior. Lateral movement requires an initial compromise and then exploitation of that foothold to reach additional agents — a two-phase attack pattern that presupposes a multi-agent topology. The attacker’s goal is typically to reach an agent with broader permissions, more sensitive tool access, or the ability to approve actions that the initially compromised agent cannot authorize unilaterally. In orchestration systems that route tasks based on capability declarations, a compromised agent can also inject fraudulent capability announcements to attract tasks that it would not normally receive, effectively poaching work from legitimate agents while intercepting the associated credentials and data.

Procedure Examples. In the OpenClaw investigation, researchers demonstrated how a compromised sub-agent could modify its configuration to disable user confirmation prompts and escalate to shell-level execution on the host [4]. In a multi-agent variant, this same technique would allow the compromised agent to send system-level instructions to sibling agents sharing the same orchestration bus, propagating the configuration change laterally before any human operator could intervene.

Detection. Anomalous inter-agent communication patterns — particularly messages that originate from an agent outside its declared role or that carry capability claims not registered at agent initialization — should be flagged for review. Orchestration platforms that log agent-to-agent message metadata can establish behavioral baselines and alert on deviations.

Mitigations. AICM domains: Identity and Access Management (IAM-06, IAM-09), Governance Risk and Compliance (GRC-12). MAESTRO layers: Agent Frameworks (Layer 3), Deployment Infrastructure (Layer 5). Agents should authenticate to one another using cryptographically bound identities that are scoped to specific communication channels, not shared session tokens. The orchestration layer should enforce role-based constraints on which agents may communicate with which other agents, and should validate capability declarations against a registry rather than accepting them at runtime.

Technique 2: Tool-Chain Poisoning

Proposed ATLAS ID: AML.T0091 (candidate)
Tactic: Defense Evasion / Persistence
ATT&CK Analog: Supply Chain Compromise (T1195) — but distinct because it targets the agent’s runtime tool registry rather than build artifacts or software distribution channels

Description. Agents in modern deployments consult a tool registry — a configuration-layer record that maps tool names to endpoints, schemas, and authentication credentials — to determine how to invoke external capabilities. Tool-chain poisoning occurs when an adversary modifies entries in this registry to redirect tool invocations to attacker-controlled endpoints. The attack is silent by design: the agent continues to believe it is calling a legitimate service, but its outputs are now flowing to or being shaped by an adversary. Because agents typically trust their tool registry as a root-of-trust configuration source rather than validating endpoints at call time, this technique can persist across agent restarts and configuration reloads without triggering any standard integrity check.

This technique is categorically different from the supply chain compromise techniques already present in ATLAS, which concern the injection of malicious code into model training pipelines, data sources, or software distribution channels. Tool-chain poisoning targets the operational runtime of a deployed agent rather than its development artifacts. An adversary who gains write access to the tool registry — through a compromised secrets manager, a misconfigured infrastructure-as-code pipeline, or direct exploitation of a platform vulnerability — can achieve persistent, invisible interception of agent tool calls without modifying the agent’s model or code at all. The MITRE ATLAS OpenClaw investigation noted that CVE-2026-24763, a command injection in the OpenClaw gateway, provided a path to exactly this kind of configuration-layer manipulation [4].

Procedure Examples. Researchers at Adversa AI demonstrated in early 2026 that OpenClaw’s gateway command injection vulnerability could be exploited to overwrite tool endpoint definitions in the agent configuration, redirecting file-write tool calls to an exfiltration endpoint while returning plausible success responses to the agent [9]. The agent continued operating normally from its own perspective, with no indication in its tool-call logs that responses were being proxied.

Detection. Integrity monitoring on tool registry configuration files, with hash verification on each agent startup. Out-of-band validation of tool endpoint certificates against a trusted registry. Behavioral anomaly detection on tool-call response latency and response schema conformance.

Mitigations. AICM domains: Supply Chain Transparency (SCT-03, SCT-07), Application and Interface Security (AIS-05). MAESTRO layers: Agent Frameworks (Layer 3), Security and Compliance (Layer 6). Tool registries should be treated as security-critical configuration and stored in tamper-evident, access-controlled systems with audit logging on all writes. Endpoint signing — where legitimate tool servers publish cryptographic signatures that agents verify before establishing connections — provides a strong technical control against registry poisoning.

Technique 3: Orchestrator Hijacking

Proposed ATLAS ID: AML.T0092 (candidate)
Tactic: Privilege Escalation / Impact
ATT&CK Analog: No direct ATT&CK equivalent; functionally similar to Domain Controller compromise in network intrusion, but operating at the AI orchestration layer

Description. In multi-agent deployments, an orchestrator — sometimes called a meta-agent or planner agent — serves as the central authority that assigns tasks to sub-agents, aggregates results, makes routing decisions, and in many implementations holds the master credential set from which sub-agent delegated tokens are derived. The orchestrator is a single point of failure by design: its compromise provides an adversary with visibility into all ongoing tasks, the ability to redirect any sub-agent’s instructions, and in many cases the ability to issue new tasks that sub-agents will execute without question because they originate from a trusted source.

Orchestrator hijacking has no precedent in ATT&CK because ATT&CK does not model systems where a single software component functions as the authoritative command layer for a fleet of autonomous actors. The closest analog — compromise of a domain controller in a Windows enterprise environment — shares the structural characteristic of controlling downstream authentication, but the mechanisms of exploitation and the resulting capabilities are entirely different. An adversary who hijacks an orchestrator can instruct sub-agents to exfiltrate data, modify documents, invoke privileged tools, or alter their own memory — all while the orchestrator’s responses to human operators appear normal, because the adversary controls what the orchestrator reports. This “double-agent” characteristic, where the compromised layer mediates all visibility into the system it controls, makes orchestrator hijacking particularly difficult to detect through standard monitoring approaches.

Procedure Examples. The CSA MAESTRO framework threat modeling exercises conducted in early 2026 identified orchestrator compromise as a scenario in which an adversary, having gained write access to the orchestrator’s system prompt or configuration, could cause it to suppress tool-call audit entries while continuing to report successful completion to human operators [7]. Sub-agents received legitimate-looking task assignments from the orchestrator and executed them without anomaly, because the orchestrator’s authority was structurally valid — only its content had been manipulated.

Detection. External, out-of-band monitoring of orchestrator outputs that does not rely on the orchestrator itself for log generation. Cryptographic signing of orchestrator task assignments, enabling sub-agents to verify task provenance independently of the orchestrator’s runtime state. Human-in-the-loop checkpoints for high-impact orchestrator decisions that cannot be bypassed by orchestrator-level manipulation.

Mitigations. AICM domains: Governance Risk and Compliance (GRC-04, GRC-08), Identity and Access Management (IAM-11). MAESTRO layers: Agent Ecosystem (Layer 7), Security and Compliance (Layer 6). The orchestrator’s own system prompt and configuration should be stored in a write-protected environment and loaded through a cryptographically verified boot sequence. Least-privilege principles should limit the orchestrator’s own permissions to those strictly necessary for task routing, preventing it from directly invoking high-impact tools that should be reserved for specialized sub-agents.

Technique 4: Credential Relay Through Agent Delegation Chains

Proposed ATLAS ID: AML.T0093 (candidate)
Tactic: Credential Access / Privilege Escalation
ATT&CK Analog: Use Alternate Authentication Material: Pass the Token (T1550.001) — but structurally distinct because the relay occurs across multiple agent hops with scope accumulation rather than simple token theft

Description. Multi-agent systems routinely implement delegation: the human user authorizes an orchestrator, which in turn authorizes sub-agents with scoped tokens derived from the parent credential. The expectation is that each delegation step narrows the scope of the derived credential, ensuring that downstream agents can only perform the subset of actions required for their specific task. In practice, however, delegation chain implementations frequently fail to enforce scope narrowing at each hop. Tokens issued to orchestrators with broad permissions are passed through to sub-agents with minimal or no scope reduction, and sub-agents in turn may spawn further agents using similarly under-scoped credentials.

An adversary who compromises any agent in a delegation chain — including a low-privilege leaf agent — may be able to use that agent’s credential to make requests that exceed its intended scope, particularly if the credential was derived from a parent with broader permissions and was not properly attenuated at delegation time. This technique combines elements of lateral movement and privilege escalation: the adversary moves through the chain until they find a node that holds credentials sufficient for their objective, or they accumulate permissions across multiple hops. The technique is particularly relevant to environments that implement the OpenID Connect or OAuth 2.0 delegation models, where improperly scoped act or may_act claims can be exploited to assert authority on behalf of upstream principals.

Procedure Examples. The disclosure of CVE-2026-25253 in OpenClaw illustrated how authentication tokens obtained from one component of an agentic system could be used to achieve remote code execution through a second, distinct component — a real-world demonstration of cross-component credential relay in an agentic context [10]. More broadly, the JFrog-discovered CVE-2025-6514 in mcp-remote showed how an MCP client’s OAuth flow could be hijacked by a malicious server to capture and reuse delegation tokens across sessions [11].

Detection. Token inspection at each agent boundary to verify that the scope of incoming credentials matches the expected scope for that agent’s role. Anomaly detection on credential usage patterns — an agent making requests that exceed its registered capability scope should trigger an alert regardless of whether the credential validates cryptographically.

Mitigations. AICM domains: Identity and Access Management (IAM-02, IAM-07, IAM-10), Data Security and Privacy Lifecycle Management (DPL-04). MAESTRO layers: Agent Frameworks (Layer 3), Deployment Infrastructure (Layer 5). Every delegation step must enforce explicit scope reduction through token claims. Platforms should adopt the principle that no derived credential may grant permissions exceeding those of the requesting agent’s registered role, regardless of the permissions encoded in the parent token. Revocation infrastructure must be capable of invalidating an entire delegation chain when any link is compromised.

Technique 5: Memory Persistence Across Sessions

Proposed ATLAS ID: AML.T0094 (candidate)
Tactic: Persistence
ATT&CK Analog: Boot or Logon Autostart Execution (T1547) — structurally similar in that the adversary achieves execution that survives a “restart” event, but operating through AI memory mechanisms rather than OS startup sequences

Description. Long-term memory in modern agentic systems — implemented through vector databases, key-value stores, episodic memory modules, or retrieval-augmented generation (RAG) backends — is designed to persist information across session boundaries, enabling agents to recall prior interactions, user preferences, and learned context. This same mechanism creates a persistence vector: an adversary who injects malicious instructions, false memories, or behavioral modifications into an agent’s long-term memory store achieves persistence that survives session termination, application restarts, and even model updates, because the memory store is external to the model itself and is not cleared by standard remediation actions.

ATLAS v5.x introduced the Memory sub-technique under AI Agent Context Poisoning (AML.T0080.000), which describes manipulation of LLM memory to persist malicious changes to future sessions [3]. However, this sub-technique focuses on the act of manipulation during an active session rather than on the persistence mechanism as a distinct attack objective — analogous to the distinction between an initial access technique and a persistence technique in ATT&CK. Memory Persistence Across Sessions is a dedicated persistence technique because the adversary’s goal is specifically to survive detection and remediation cycles, not merely to influence a single agent response. An attacker who achieves this form of persistence can cause the agent to behave maliciously on any future task that triggers the poisoned memory retrieval, long after the initial compromise has been forgotten.

Procedure Examples. Zenity Labs research demonstrated that agents with access to persistent memory stores could be manipulated through indirect prompt injection in retrieved documents, causing the agent to write adversarial instructions to its own memory — instructions that were subsequently retrieved in later sessions and influenced agent behavior without any further attacker interaction [3]. The OWASP ASI framework classifies this pattern under ASI06 (Memory and Context Poisoning) and rates it as one of the most difficult agentic risks to remediate because the poisoned state is structurally indistinguishable from legitimate learned context [5].

Detection. Regular integrity audits of agent memory stores, including semantic review of stored content for instruction-like patterns inconsistent with legitimate episodic memory. Anomaly detection on memory write operations, particularly writes that occur during document retrieval or tool-call processing rather than explicit user instruction. Version-controlled memory stores that enable rollback to known-good states.

Mitigations. AICM domains: Data Security and Privacy Lifecycle Management (DPL-02, DPL-06), Model Security (MS-08). MAESTRO layers: Data Operations (Layer 2), Agent Frameworks (Layer 3). Memory stores should enforce write authorization policies that distinguish between user-directed memory operations and agent-autonomously triggered writes. High-confidence memory entries — those written by verified user input — should be marked with provenance metadata that agents can weight more heavily than entries derived from retrieved content. Memory stores should be included in the scope of incident response playbooks, with defined procedures for memory sanitization following a confirmed compromise.

Technique 6: MCP Server Compromise

Proposed ATLAS ID: AML.T0095 (candidate)
Tactic: Initial Access / Lateral Movement
ATT&CK Analog: Exploit Public-Facing Application (T1190) for initial access; Server Software Component (T1505) for the persistent pivot role — neither captures the protocol-level structural characteristics of MCP compromise

Description. The Model Context Protocol (MCP), developed by Anthropic and now widely adopted as an open standard for connecting AI agents to external tools and data sources, introduces a server tier between agents and the services they invoke. MCP servers aggregate tool capabilities, manage protocol negotiation, and often hold authentication credentials on behalf of the agents they serve. This architecture creates a high-value target: a compromised MCP server can intercept all tool calls from any agent that uses it, inject malicious responses, redirect agent actions, and harvest the credentials and data payloads that agents transmit during normal operations.

CVE-2025-6514, discovered by JFrog Security Research, exemplifies the structural risk in MCP infrastructure. The vulnerability — a command injection in the mcp-remote client library through improper handling of OAuth authorization endpoint URLs — allowed a malicious MCP server to achieve remote code execution on the connecting client’s machine by returning a crafted authorization endpoint during the OAuth handshake [11]. With a CVSS score of 9.6, the vulnerability affected mcp-remote versions 0.0.5 through 0.1.15 and impacted widely-deployed AI tools including Claude Desktop, Cursor, and Windsurf. The exploit required only that a client initiate a connection to an attacker-controlled MCP server — a trivially achievable precondition given that MCP server registries are not universally authenticated.

MCP server compromise is distinct from the tool-chain poisoning technique (AML.T0091) described earlier in this document. Tool-chain poisoning targets the agent’s configuration layer to redirect it toward attacker-controlled endpoints. MCP server compromise targets the server tier itself — either by deploying a rogue server that clients connect to or by compromising a legitimate server that is already trusted. The attack surface is protocol-level: weaknesses in how MCP handles authentication, capability negotiation, and response validation create exploitation paths that do not exist in traditional API architectures and cannot be addressed through agent-side controls alone.

Procedure Examples. The Docker security team published a case study in 2025 documenting MCP supply chain attack scenarios in which maliciously crafted MCP servers were published to community registries and subsequently installed by developers building agentic applications [12]. Once installed, these servers achieved persistent code execution in the developer’s environment and gained access to the agent’s full tool credential set. The JFrog CVE-2025-6514 disclosure provided a concrete, in-the-wild mechanism by which even a briefly visited rogue MCP server — without any persistent installation — could achieve host-level code execution through the client OAuth flow [11].

Detection. MCP server certificate pinning, preventing agents from connecting to servers that do not match a pre-registered identity. Behavioral monitoring of MCP server response patterns, flagging unusual response schemas or unexpected OAuth flow deviations. Network-level monitoring for unexpected outbound connections from MCP client processes.

Mitigations. AICM domains: Application and Interface Security (AIS-02, AIS-08), Supply Chain Transparency (SCT-01, SCT-05). MAESTRO layers: Deployment Infrastructure (Layer 5), Agent Ecosystem (Layer 7). Organizations should maintain an authorized MCP server registry and configure agents to connect only to registered, certificate-verified servers. MCP client implementations should validate OAuth endpoint URLs against an allowlist and refuse connections that redirect authentication flows to unexpected hosts. The eSentire guidance on MCP security published in 2025 recommends that all MCP servers in production environments be deployed with mutual TLS authentication as a minimum baseline [13].

Cross-Reference Table

The following table consolidates the six proposed techniques with their tactic alignments, ATT&CK analogs, MAESTRO layers, AICM domains, and OWASP ASI categories to facilitate cross-framework mapping in security architecture and governance contexts.

Technique Tactic ATT&CK Analog MAESTRO Layers AICM Domains OWASP ASI
Agent-to-Agent Lateral Movement (AML.T0090) Lateral Movement (proposed) T1021, T1550 Layer 3 (Agent Frameworks), Layer 5 (Infrastructure) IAM-06, IAM-09, GRC-12 ASI07 (Inter-Agent Communication), ASI03 (Identity & Privilege)
Tool-Chain Poisoning (AML.T0091) Defense Evasion, Persistence T1195 (Supply Chain) Layer 3 (Agent Frameworks), Layer 6 (Security) SCT-03, SCT-07, AIS-05 ASI04 (Supply Chain), ASI01 (Goal Hijack)
Orchestrator Hijacking (AML.T0092) Privilege Escalation, Impact No ATT&CK equivalent Layer 6 (Security), Layer 7 (Ecosystem) GRC-04, GRC-08, IAM-11 ASI10 (Rogue Agents), ASI08 (Cascading Failures)
Credential Relay Through Delegation Chains (AML.T0093) Credential Access, Privilege Escalation T1550.001 (Pass the Token) Layer 3 (Agent Frameworks), Layer 5 (Infrastructure) IAM-02, IAM-07, IAM-10, DPL-04 ASI03 (Identity & Privilege), ASI07 (Inter-Agent Communication)
Memory Persistence Across Sessions (AML.T0094) Persistence T1547 (Boot/Logon Autostart) Layer 2 (Data Operations), Layer 3 (Agent Frameworks) DPL-02, DPL-06, MS-08 ASI06 (Memory & Context Poisoning), ASI01 (Goal Hijack)
MCP Server Compromise (AML.T0095) Initial Access, Lateral Movement T1190, T1505 Layer 5 (Infrastructure), Layer 7 (Ecosystem) AIS-02, AIS-08, SCT-01, SCT-05 ASI04 (Supply Chain), ASI07 (Inter-Agent Communication)

MITRE ATLAS Submission Summary

The six techniques specified in this document are formatted in accordance with MITRE ATLAS community contribution guidelines. ATLAS accepts community submissions through pull requests against the public atlas-data GitHub repository, which contains schemas defining each ATLAS object type — including techniques, sub-techniques, mitigations, and case studies — in YAML format for human authoring and STIX 2.1 format for machine-readable distribution [14]. Each submission is expected to include a technique name, description, procedure examples drawn from observed or demonstrated incidents, platform scope, detection guidance, and at least one associated mitigation. The techniques in this document satisfy all of these requirements.

Community contributions are reviewed by the MITRE ATLAS team and, where they meet the framework’s evidential standards, incorporated into subsequent releases. The October 2025 update cycle, which incorporated Zenity Labs’ fourteen techniques after collaborative development, provides the most recent precedent for coordinated external contributions at this scale [3]. The CSA AI Safety Initiative intends to submit these six techniques as a coordinated contribution package, referencing the OpenClaw investigation case studies [4], the CVE-2025-6514 incident record [11], and the OWASP ASI Top 10 framework alignment [5] as supporting evidence for technique maturity classification. Techniques AML.T0090 through AML.T0095 are proposed IDs; final IDs will be assigned by MITRE during review.

Organizations wishing to provide additional case studies, detection logic, or procedure examples in support of these submissions are encouraged to contribute through the ATLAS GitHub repository or to coordinate directly with the CSA AI Safety Initiative. The MITRE AI Incident Sharing initiative, launched in October 2024, provides a structured, anonymized channel for organizations to contribute real-world incident data that can substantiate technique maturity assessments [15]. Community engagement through both channels strengthens the evidential basis for each technique and accelerates the review and publication timeline. The CSA estimates that a well-documented submission package with multiple independent case studies can expect review and initial feedback from the MITRE team within sixty to ninety days of submission, based on the cadence of prior community contributions.

References

  1. MITRE Corporation. “MITRE ATLAS: Adversarial Threat Landscape for Artificial-Intelligence Systems.” atlas.mitre.org. Accessed March 2026. https://atlas.mitre.org/

  2. MITRE Corporation. “ATLAS Data Release v5.0.0.” GitHub, mitre-atlas/atlas-data. September 2025. https://github.com/mitre-atlas/atlas-data/releases

  3. Bargury, M.; Zenity Labs. “Zenity Labs and MITRE ATLAS Collaborate to Advance AI Agent Security with the First Release of Agent-Focused Techniques.” Zenity Blog. October 2025. https://zenity.io/blog/current-events/zenity-labs-and-mitre-atlas-collaborate-to-advances-ai-agent-security-with-the-first-release-of

  4. MITRE Corporation. “MITRE ATLAS OpenClaw Investigation: Discovering New and Likeliest Techniques.” MITRE Center for Threat-Informed Defense. February 2026. https://ctid.mitre.org/blog/2026/02/09/mitre-atlas-openclaw-investigation/

  5. OWASP GenAI Security Project. “OWASP Top 10 for Agentic Applications.” December 2025. https://genai.owasp.org/2025/12/09/owasp-top-10-for-agentic-applications-the-benchmark-for-agentic-security-in-the-age-of-autonomous-ai/

  6. MITRE Corporation. “ATT&CK v16 Enterprise Matrix.” attack.mitre.org. October 2025. https://attack.mitre.org/versions/v16/

  7. Cloud Security Alliance. “Agentic AI Threat Modeling Framework: MAESTRO.” CSA Blog. February 2025. https://cloudsecurityalliance.org/blog/2025/02/06/agentic-ai-threat-modeling-framework-maestro

  8. Cloud Security Alliance. “AI Controls Matrix (AICM) v1.0.” CSA Artifacts. July 2025. https://cloudsecurityalliance.org/artifacts/ai-controls-matrix

  9. Adversa AI. “OpenClaw Security Guide 2026: CVE-2026-25253, Moltbook Breach, and Hardening.” adversa.ai. February 2026. https://adversa.ai/blog/openclaw-security-101-vulnerabilities-hardening-2026/

  10. SonicWall Threat Research. “OpenClaw Auth Token Theft Leading to RCE: CVE-2026-25253.” SonicWall Blog. 2026. https://www.sonicwall.com/blog/openclaw-auth-token-theft-leading-to-rce-cve-2026-25253

  11. JFrog Security Research. “Critical RCE Vulnerability in mcp-remote: CVE-2025-6514 Threatens LLM Clients.” JFrog Blog. 2025. https://jfrog.com/blog/2025-6514-critical-mcp-remote-rce-vulnerability/

  12. Docker, Inc. “MCP Horror Stories: The Supply Chain Attack.” Docker Blog. 2025. https://www.docker.com/blog/mcp-horror-stories-the-supply-chain-attack/

  13. eSentire. “Model Context Protocol Security: Critical Vulnerabilities Every CISO Must Address in 2025.” eSentire Blog. 2025. https://www.esentire.com/blog/model-context-protocol-security-critical-vulnerabilities-every-ciso-should-address-in-2025

  14. MITRE Corporation. “atlas-data: ATLAS Tactics, Techniques, and Case Studies Data.” GitHub, mitre-atlas/atlas-data. https://github.com/mitre-atlas/atlas-data

  15. MITRE Corporation. “MITRE ATT&CKcon 6.0: AI Incident Sharing Initiative.” MITRE ATT&CK Resources. October 2025. https://attack.mitre.org/resources/attackcon/october-2025/