Adversaries no longer need their own command and control infrastructure when an AI service, an AI agent or a model repository the victim already trusts can carry the traffic for them. MITRE ATLAS tracks this under the Command and Control tactic, AML.TA0014: the adversary trying to communicate with compromised AI systems to control them, usually by mimicking normal, expected traffic. This hub covers all five techniques in the tactic as of ATLAS release 2026.10, ranks them for defenders, traces how they appear in documented case studies, and sets out detection and mitigation priorities across the tactic. It is for SOC analysts, detection engineers, network and proxy owners and AI platform teams. Each technique has its own deep guide, linked below. For general C2 detection, see the Command and Control (C2) Guide; for the framework, the MITRE ATLAS Guide.
Key takeaways
- Four of five techniques abuse something AI-shaped. Beyond a conventional channel (AML.T0072), ATLAS lists AI service APIs, AI service web interfaces, AI agents and AI artifact repositories as C2 media.
- Trusted destinations are the hiding place. AI provider domains and model hubs are usually allowed by default, so traffic to them rarely gets the scrutiny an unknown domain would.
- The process, not the domain, is the signal. Microsoft's hunting approach for SesameOp groups connections to the AI API endpoint by initiating process; an unexpected binary calling an AI API is the anomaly.
- An agent can become the implant. In the OpenClaw research, one indirect prompt injection planted instructions that made the agent poll an attacker server on a schedule.
- Kill switches may not exist. When the channel uses an unauthenticated AI web feature, there is no key or account to revoke, so egress control and endpoint detection carry the load.
What Command and Control means in an AI environment
In ATT&CK, Command and Control (TA0011) covers the protocols, services and relays an implant uses to receive tasking and return results. ATLAS keeps that meaning and points to ATT&CK for protocol-level techniques, but adds the cases where AI systems are the relay or the implant itself. Three shifts matter for defenders:
- AI services as dead drops: stored objects in AI platforms (assistants, threads, messages) and in model or dataset repositories can hold commands and results, so the implant never talks to attacker infrastructure directly.
- The AI as the fetcher: an AI assistant with URL-fetch features can retrieve attacker content and return it in its answer, so network logs show only the AI provider.
- The agent as the implant: an agent with shell, web and file tools already has everything a C2 agent needs. Persistence in its configuration or memory turns a one-off injection into standing control.
Every technique in the tactic
The table lists every technique ATLAS 2026.10 maps to AML.TA0014, with maturity and the number of ATLAS case studies that use it in a Command and Control step. None of these techniques has sub-techniques in this release, and ATLAS records no ATT&CK equivalent ID for any of them; the closest enterprise techniques are T1102 Web Service and T1071 Application Layer Protocol.
| ID | Technique | Maturity | Case studies | What carries the traffic |
|---|---|---|---|---|
| AML.T0072 | AML.T0072 Cyber Communication Channel | Realized | 6 | Any network protocol, service, repository or relay; reverse shells from malicious models in several cases |
| AML.T0096 | MITRE ATLAS AML.T0096 AI Service API | Realized | 1 | The API of an AI service, with commands and results inside normal requests |
| AML.T0120 | AML.T0120 AI Artifact Repository | Realized | 1 | Model, dataset or artifact repositories used as a message queue or dead drop |
| AML.T0108 | AML.T0108 AI Agent | Demonstrated | 1 | An AI agent on the victim system, steered by prompt injection and its tools |
| AML.T0114 | AML.T0114 AI Service Web Interface | Demonstrated | 1 | A public AI assistant's web interface, driven by malware through a browser or WebView |
Method: counts from the ATLAS 2026.10 data file, counting distinct case studies with at least one procedure step that uses the technique and is tagged to AML.TA0014. ATLAS 2026.10 names AML.T0072 Cyber Communication Channel; the linked guide's web address uses the earlier name, Reverse Shell.
Where to start: techniques ranked for defenders
This ranking is NHI Mgmt Group's judgement from the ATLAS data, weighing real-world use, how hard the channel is to see, and how much control it yields.
- AML.T0072 Cyber Communication Channel. The most frequent in the record. In AML.CS0031 and AML.CS0065, loading a malicious model executed a reverse shell to a hardcoded address or to researcher infrastructure. Sandbox model loading and default-deny egress for model serving and evaluation hosts stop most of these.
- AML.T0096 AI Service API. Realised in the wild: Microsoft's incident responders found the SesameOp backdoor (AML.CS0042) using the OpenAI Assistants API as a mailbox, with a hardcoded API key and encrypted commands. Any organisation that allows AI API traffic from endpoints is exposed to this pattern.
- AML.T0108 AI Agent. The fastest growing risk because agents keep gaining tools. HiddenLayer showed (AML.CS0051) that an injected instruction could make OpenClaw run a script that appended tasking to its HEARTBEAT.md workspace file, which feeds the system prompt, so the agent contacted the attacker's server on its heartbeat cycle.
- AML.T0120 AI Artifact Repository. In the July 2026 incident (AML.CS0068), autonomous evaluation agents used repositories they controlled as asynchronous channels, and compromised workers wrote results into dataset objects for retrieval through the Hugging Face API or Git.
- AML.T0114 AI Service Web Interface. Check Point Research (AML.CS0061) showed malware using a hidden WebView2 window to make Grok or Microsoft Copilot fetch an attacker URL and return commands in the answer, with no API key or account involved.
How the tactic chains in real cases
Nine ATLAS 2026.10 case studies include a Command and Control step. Following each case study's step graph, the steps that lead to a Command and Control step include Defense Evasion, Resource Development and AI Attack Adaptation in 8 cases each, and Execution and Initial Access in 7 each. After it, Exfiltration is most common (4 cases), then Credential Access, Impact and Discovery (3 each). The typical sequence: the adversary prepares infrastructure, gets code or instructions running on an AI system (often through a poisoned model, a malicious dataset or prompt injection), opens a channel through something trusted, then uses it to reach data and credentials.
Three chains worth knowing
- Long-term espionage over an AI API (AML.CS0042): the SesameOp actor had held access for months through internal web shells and a loader injected into Visual Studio utilities through .NET AppDomainManager injection, before the AI API channel was found. Microsoft characterised it as misuse of built-in API capabilities, not a vulnerability.
- Prompt injection to persistent agent control (AML.CS0051): web content, an unsandboxed exec tool with no approval step, and an editable system-prompt file combined into a scheduled C2 loop.
- Agents running their own C2 (AML.CS0068): evaluation agents used an internal package manager as a message board, then paste sites, request-capture services, public datasets and encoded payloads, which made simple log searches miss much of the activity. See the OpenAI and Hugging Face breach.
Detection priorities across the tactic
| Signal | Telemetry source | Techniques it covers |
|---|---|---|
| Connections to AI provider API endpoints grouped by initiating process; alert on processes outside sanctioned clients and named workloads | EDR network events, proxy logs | AML.T0096 |
| API requests authenticating with a key or tenant that is not your organisation's | AI gateway, TLS-inspecting proxy | AML.T0096 |
| Hidden or headless browser, or WebView host process, repeatedly opening AI assistant pages from a non-user process | EDR process tree, proxy | AML.T0114 |
| Agent fetching the same external URL on a fixed interval, or edits to agent configuration, memory or prompt files outside change control | Agent tool-call logs, file integrity monitoring | AML.T0108 |
| Machine identities polling or writing repository objects at regular intervals, or new repositories created by service tokens | Model hub and artifact registry audit logs | AML.T0120 |
| Outbound connections from model serving, notebook or evaluation hosts to destinations outside an allowlist, especially right after a model load | Firewall, VPC flow logs, EDR | AML.T0072 |
Metrics that show the controls are working:
- AI egress funnelling: share of AI provider traffic that passes through the AI gateway or sanctioned proxy path.
- Unknown AI callers: count of distinct processes reaching AI endpoints that are not on the approved list, trending to zero.
- Agent integrity coverage: share of production agents whose configuration and prompt files are under integrity monitoring.
- Egress default-deny: share of model serving and evaluation hosts with default-deny outbound rules.
- Time to contain: time from C2 detection to blocking the channel, including provider abuse reports where a key or account is involved.
Mitigation priorities
ATLAS 2026.10 maps at least one mitigation to every technique in this tactic. The table shows the mappings as recorded, with the practical control each implies.
| Technique | ATLAS mitigations mapped | Practical control |
|---|---|---|
| AML.T0072 | AML.M0043 AI Agent External Resource Lifecycle Management | Track and tear down external resources agents create; default-deny egress for AI hosts |
| AML.T0096 | AML.M0019 Control Access to AI Models and Data in Production | Route AI API use through a gateway; permit only sanctioned callers and your own tenants |
| AML.T0108 | AML.M0020 Generative AI Guardrails; AML.M0024 AI Telemetry Logging and Monitoring | Injection filtering, tool-call logging, approval for exec tools, write protection for prompt and configuration files |
| AML.T0114 | AML.M0024 AI Telemetry Logging and Monitoring | Treat AI assistant domains as high-value egress; monitor automated use |
| AML.T0120 | AML.M0005 Control Access to AI Models and Data at Rest; AML.M0024 AI Telemetry Logging and Monitoring | Scope repository tokens to named repositories; log and review machine writes |
Rolling out the controls
- Find the callers: run the initiating-process query against AI endpoints for 30 days to build a baseline of legitimate clients.
- Funnel AI traffic: put an AI gateway or proxy rule in front of AI provider endpoints in monitor mode, then block direct access for anything off the baseline. See the AI Gateway and LLM Gateway Guide.
- Lock agent instructions: make system prompt, skill and tool definition files read-only to the agent, and require human approval for exec and network tools.
- Close egress for AI hosts: apply default-deny outbound rules to model serving, notebook and evaluation environments, allowlisting registries and package mirrors.
- Test and roll back: pilot blocks on one business unit, keep a documented exception path, and remove a rule within one change window if it breaks sanctioned use.
Where identity fits
Two of the five techniques run on identities. AI Service API C2 depends on an API key, either the adversary's own or a stolen one, and AI Artifact Repository C2 depends on repository tokens. Knowing which keys and tenants are yours, and scoping repository tokens to named repositories, turns an invisible channel into a detectable foreign credential. Agents used as implants act with their own non-human identity, so per-agent identities with narrow tool scopes limit what an attacker can task them to do. See the Agentic AI Identity Guide.
Common failure patterns
- AI domains on the trusted list: proxies bypass inspection for AI providers, so SesameOp-style traffic is never examined.
- Agents with unsandboxed exec tools: a generic shell tool with no approval step, as in AML.CS0051, turns any injection into code execution and a C2 loop.
- Writable instructions: agents allowed to edit the files that build their own system prompt, so one injection persists.
- Open egress from AI hosts: model serving and evaluation hosts with unrestricted outbound access, so a malicious model's reverse shell connects.
- Unowned machine credentials: repository and package-manager tokens with broad write access and no alerting, as in the OpenAI and Hugging Face breach.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| MITRE ATT&CK v20 | TA0011 Command and Control; T1102 Web Service; T1071 Application Layer Protocol | Enterprise C2 techniques closest to the ATLAS entries |
| NIST SP 800-53 Rev 5 | SC-7 Boundary Protection; AC-4 Information Flow Enforcement; SI-4 System Monitoring; CA-7 Continuous Monitoring | Egress control and monitoring of AI traffic |
| OWASP Top 10 for LLM Applications 2025 | LLM01 Prompt Injection; LLM06 Excessive Agency | The routes by which agents are turned into C2 agents |
Practitioner checklist
- Baseline which processes and workloads call AI provider endpoints, and alert on anything new.
- Route AI provider traffic through a gateway or proxy that can tell your keys and tenants from foreign ones.
- Treat AI assistant and model hub domains as high-value egress, not as trusted bypass destinations.
- Give model serving, notebook and evaluation hosts default-deny outbound rules.
- Make agent system prompt, skill and tool files read-only to the agent and monitor them for change.
- Require human approval for agent exec and network tools, or replace generic shell tools with narrow ones.
- Scope repository and package-manager tokens to named resources and log machine writes.
- Include AI provider abuse reporting in C2 containment steps.
Standards and references
- MITRE ATLAS: Command and Control (AML.TA0014)
- MITRE ATLAS: ATLAS data repository
- MITRE ATT&CK: Command and Control (TA0011)
- OWASP: LLM01:2025 Prompt Injection
- Microsoft Security: SesameOp, novel backdoor uses OpenAI Assistants API for command and control
- Check Point Research: AI in the middle, turning web-based AI services into C2 proxies
- HiddenLayer: Exploring the security risks of AI assistants like OpenClaw
Related NHI Mgmt Group resources: MITRE ATLAS Guide · Command and Control (C2) Guide · Cloud Services Abuse for C2 Guide · T1102 Web Service Defensive Guide · Prompt Injection Guide