An AI agent with a shell tool, a web fetch tool and a schedule already has everything an implant needs, so an attacker who can steer it does not need to install malware at all. MITRE ATLAS tracks this as AML.T0108 AI Agent, under the Command and Control tactic (AML.TA0014): adversaries abuse an agent already present on the victim's system to receive and run their commands. The traffic looks like the agent doing its job, the process is a trusted application, and the instructions can be told to stay out of the user's view. This page explains how the technique works, what the ATLAS case study and public research show, and how to detect and break agent-based command and control using agent telemetry. Classic C2 detection is covered in the Command and Control (C2) Guide and the Beaconing and C2 Detection Guide; this page covers what changes when the implant is an agent. It is for SOC analysts, detection engineers and teams that deploy personal, coding or computer-use agents.
Key takeaways
- The agent is the implant. ATLAS notes that agents are often granted tools that run shell commands, reach the internet and call other services, which makes them capable C2 agents with no attacker binary on disk.
- Persistence lives in instructions, not in services. In AML.CS0051 an injected install step wrote instructions into files the agent loads into its system prompt, so every new session fetched and ran new tasks.
- Network C2 detection sees an approved app. The callbacks come from the agent process to web addresses, often over HTTPS, so endpoint and proxy rules built for malware families rarely fire.
- Agent telemetry is the primary sensor. Tool call logs, instruction file changes and the link between fetched content and the next command are where this technique becomes visible.
- Break the loop outside the model. Approval gates, narrow tools, read-only instruction files and egress allowlists stop the fetch, execute and repeat cycle even when the prompt injection succeeds.
How agent-based command and control works
ATLAS added AML.T0108 in January 2026 (last modified May 2026, maturity demonstrated, platform Agentic AI). The ATLAS data gives it no ATT&CK equivalent: the agent itself replaces the implant. ATLAS describes three moving parts, each of which has its own ATLAS technique.
| Stage | What happens | Related ATLAS technique | Control point |
|---|---|---|---|
| Take control | Untrusted content the agent reads (a web page, document, email or tool output) carries instructions the model follows | AML.T0051 LLM Prompt Injection | Untrusted data handling, guardrails |
| Stay in control | Instructions are written into the agent's configuration, instruction files or memory so they reload in every session | AML.T0081 Modify AI Agent Configuration; AML.T0080 AI Agent Context Poisoning | Read-only instructions, memory integrity |
| Receive and run tasks | The agent fetches tasks from an attacker-controlled location and runs them with its own tools, then reports or exfiltrates results | AML.T0108 AI Agent (this page) | Tool approval, narrow tools, egress control |
| Hide | The agent is instructed not to mention its actions to the user | AML.T0108 description | Logs the model cannot edit or suppress |
The defining feature is that the attacker's control channel is an ordinary agent capability. A periodic "check this page and do what it says" is indistinguishable at the network layer from an agent checking a to-do list, a ticket queue or a status page. The persistence pieces are covered in the MITRE ATLAS AML.T0081 Modify AI Agent Configuration and MITRE ATLAS AML.T0080 AI Agent Context Poisoning guides; this page focuses on the command channel and how to see it.
What the case study and research show
AML.CS0051: a personal assistant turned into a C2 relay
In February 2026 HiddenLayer researchers showed how a web page could take over OpenClaw, a self-hosted personal AI assistant. According to their write-up, the user asked the agent to summarise a malicious page. The page imitated control markers from the agent's own system prompt so the model treated the injected text as trusted. The model then used its exec tool to run a remote install script without asking the user. That script wrote instructions into workspace markdown files that the agent uses to build its system prompt, so the instructions carried into new sessions. ATLAS records the result: the agent requested a task list from a researcher-controlled web address with its web fetch skill and ran the commands with its bash skill. HiddenLayer lists the root causes as tools running without approval, generic shell wrappers, instruction files the agent could write, and secrets stored in plain text.
Computer-use agents joining a C2 server
In October 2024 the researcher behind the Embrace The Red blog showed that a computer-use agent in beta could be led by a web page to download a program through the browser, make it executable, run it and connect the host to a C2 server. A direct shell download was refused, but the plain-language request on the page was followed. Here the agent was the delivery route for a conventional implant rather than the implant itself, which is why the same controls (approval for download and execute, egress limits, isolated environments) apply to both patterns. See the Browser and Computer-Use Agent Guide.
Detecting an agent under external control
ATLAS links mitigation AML.M0024 AI Telemetry Logging and Monitoring to this technique; it asks for logs of agent steps and decisions, data access, tool use, installation commands and agent identity. Those logs are the core data source for this technique, because the network and endpoint views both show a trusted process doing normal things.
| Data source | What to look for | Why it points to C2 |
|---|---|---|
| Tool call log | A fetch from an external address followed, in the same turn or the next, by a shell or code tool call whose arguments came from the fetched content | This fetch then execute pair is the C2 loop itself |
| Tool call log, over time | The same external address fetched on a regular schedule across sessions, with no user prompt starting the session | Agent beaconing; same scoring ideas as network beaconing |
| Instruction and memory files | Writes by the agent to files that feed its system prompt, skills or long-term memory | The persistence step that keeps the channel alive (AML.CS0051) |
| Agent response versus actions | Tool calls that the final message to the user does not mention | ATLAS notes attackers may tell the agent to hide its actions |
| Endpoint telemetry | Child processes of the agent runtime that download, change file permissions or start network listeners | Agent used to stage a conventional implant |
| Egress proxy or AI gateway | Agent identities contacting domains outside their allowlist, newly registered domains or paste and file-sharing services | Command source or results drop |
- Correlate by session: log a session ID and agent identity on every model call, tool call and outbound request so analysts can rebuild what content came in and what action followed.
- Baseline per agent: each agent has a normal set of tools and destinations. A coding agent that starts fetching from a new domain every hour is an outlier even if the domain is not known bad. See the AI Agent Behaviour Baselining and Anomaly Detection Guide.
- Keep logs out of the agent's reach: ship tool and file events from the runtime or gateway, not from anything the model can write, so an instruction to stay quiet does not remove the evidence.
- Watch for legitimate services as channels: ATT&CK T1102 Web Service describes C2 over legitimate web services. An agent fetching tasks from a public document, issue tracker or code hosting page is the agent version of the same idea.
Metrics
- Telemetry coverage: share of deployed agents whose tool calls, outbound requests and instruction file changes reach the SIEM.
- Unapproved execution: shell or code tool calls run with no approval record while untrusted content was in context (target zero).
- Instruction file changes by the agent: count per month of agent-initiated writes to its own instruction, skill or memory files outside an approved workflow.
- Egress exceptions: agent requests blocked by the destination allowlist, reviewed weekly.
- Time to isolate: minutes from a fetch then execute alert to the agent's tools and tokens being suspended.
Breaking the command loop
ATLAS 2026.10 links two mitigations directly to AML.T0108: AML.M0024 (above) and AML.M0020 Generative AI Guardrails, the latter used to block malicious agent instructions, command outputs and unsafe tool requests. Guardrails help, but HiddenLayer's first recommendation is enforcement outside the model, so treat the following as the main controls.
- Restrict tools when untrusted data is in context (AML.M0030): once a web page, email or document enters the context, block automatic shell and code execution or require confirmation.
- Approval for consequential actions (AML.M0029): require the user to approve downloads, execution of new files, scheduled tasks and changes to the agent's own configuration.
- Narrow tools instead of a generic shell (AML.M0028): replace "run any command" with specific tools that have defined inputs and limits. A C2 operator gains little from an agent that can only create calendar entries.
- Read-only instructions and skills: keep system prompt files, skills and agent configuration where the agent's runtime identity cannot write them, with review for changes. This removes the persistence step in AML.CS0051.
- Egress allowlists per agent: an agent that needs three APIs should reach three APIs. Route browsing agents through a proxy that logs every destination. See the Agent Egress Control and Network Isolation Guide.
- Isolation and ephemeral sessions (AML.M0032): run tools in a sandbox rebuilt per session so a planted task runner does not survive.
- Single chokepoint for model traffic: route all LLM and tool traffic through one gateway where guardrails, logging and kill switches apply. See the AI Gateway and LLM Gateway Guide.
- Protect the secrets the agent holds: an agent under external control will be asked for its keys. Keep credentials out of plain-text configuration and scope them to the agent's task.
Choosing controls by agent type
| Agent type | Main exposure | Priority controls |
|---|---|---|
| Personal or desktop assistant | Reads web and email, runs on a user's machine with their access | Approval gates, read-only instructions, local service bound to localhost, endpoint monitoring |
| Coding agent | Reads repositories and issues, has a shell | Sandboxed execution, approval for network and install commands, repository instruction file review |
| Computer-use or browser agent | Acts on any page it visits | Disposable VM, no saved credentials, egress proxy, approval for download and execute |
| Server-side workflow agent | Processes customer content at scale, often unattended | Narrow tools only, strict egress allowlist, gateway guardrails, behaviour baselines |
Responding to an agent C2 finding
- Contain: suspend the agent's tools and revoke its tokens and API keys, rather than only killing the current session, because the instructions persist. The AI Agent Kill Switch and Containment Guide covers the mechanics.
- Preserve: copy tool call logs, conversation history, instruction, skill and memory files, and proxy logs for the agent's identity before cleaning anything.
- Find the persistence: diff instruction, skill and memory files against the last known-good version; look for scheduled tasks or triggers the agent created.
- Scope the commands: list every command the agent ran from fetched content and treat each as attacker activity on the host and in connected services.
- Rotate: assume every secret the agent could read is exposed, including model provider keys and connected service tokens.
- Restore and harden: rebuild the agent from a clean configuration with the controls above, then block the command source at the proxy.
How to test
Use an AI red team exercise (AML.M0035) in a non-production copy of the agent. Plant a benign instruction on a test page that asks the agent to fetch a harmless task from a test address on a schedule, and confirm three things: the agent asks for approval or refuses to run fetched content, it cannot write to its own instruction files, and the SIEM raises the fetch then execute and instruction file change alerts. Re-run after each agent framework, model or tool change. The AI Red Teaming Guide covers programme design.
Common failure patterns
- Generic shell tools: one "exec" tool that can run anything gives an attacker a full implant; AML.CS0051 relied on it.
- Agent-writable instructions: configuration, skills and memory in the same workspace the agent edits, with no review.
- Only the final answer is logged: chat transcripts without tool call detail hide exactly the actions the attacker told the agent not to mention.
- Allow-all egress for convenience: agents that can reach any domain can reach any command source.
- Killing the session, not the agent: the persisted instructions reload on the next run.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| MITRE ATLAS | AML.T0108 AI Agent (AML.TA0014 Command and Control) | This technique |
| MITRE ATLAS mitigations | AML.M0020, AML.M0024 (linked by ATLAS); AML.M0028, AML.M0029, AML.M0030, AML.M0032, AML.M0035 | Guardrails, telemetry, tool limits, approval, isolation, testing |
| MITRE ATT&CK | T1102 Web Service; T1071.001 Web Protocols | The network form the agent's command channel usually takes |
| OWASP Top 10 for Agentic Applications | ASI01 Agent Goal Hijack; ASI02 Tool Misuse and Exploitation; ASI10 Rogue Agents | Hijacked goals, abused tools and agents acting outside intent |
| OWASP Top 10 for LLM Applications 2025 | LLM01 Prompt Injection; LLM06 Excessive Agency | Entry route and over-capable tools |
Practitioner checklist
- Every deployed agent is inventoried with its tools, destinations and the identities it holds.
- Tool calls, outbound requests and instruction file changes are logged outside the agent's reach and sent to the SIEM.
- A detection exists for external fetch followed by shell or code execution in the same session.
- Shell and code tools require approval, or are blocked, once untrusted content is in context.
- Instruction, skill and configuration files are read-only to the agent runtime.
- Each agent has an egress allowlist enforced by a proxy or gateway.
- Generic shell tools are replaced by narrow tools where the task allows.
- The containment runbook revokes tokens and checks for persisted instructions, not just the live session.
- Red team tests for agent C2 run after each framework or model change.
Standards and references
- MITRE ATLAS: AML.T0108 AI Agent
- MITRE ATLAS: AML.CS0051 OpenClaw Command & Control via Prompt Injection
- MITRE ATLAS: AML.M0020 Generative AI Guardrails
- MITRE ATT&CK: T1102 Web Service
- OWASP GenAI Security Project: OWASP Top 10 for Agentic Applications for 2026
- HiddenLayer: Exploring the Security Risks of AI Assistants like OpenClaw
- Embrace The Red: ZombAIs, From Prompt Injection to C2 with Claude Computer Use
Related NHI Mgmt Group resources: MITRE ATLAS Guide · OWASP Agentic Top 10 ASI10 Guide · MITRE ATLAS AML.T0086 Exfiltration via AI Agent Tool Invocation · AI Agent Observability and Incident Response Guide · OWASP LLM Top 10 LLM01 Prompt Injection Guide