Join our Newsletter — 33% off our NHI Course
Home› Guides› AML.T0108 AI Agent: Detecting Agents Turned Into Command…
Guide Agent Threats & Attacks

AML.T0108 AI Agent: Detecting Agents Turned Into Command and Control Channels

← All guides
By NHI Mgmt Group, edited by Lalit Choda Updated 12 November 2026 13 min read
On this page

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.

StageWhat happensRelated ATLAS techniqueControl point
Take controlUntrusted content the agent reads (a web page, document, email or tool output) carries instructions the model followsAML.T0051 LLM Prompt InjectionUntrusted data handling, guardrails
Stay in controlInstructions are written into the agent's configuration, instruction files or memory so they reload in every sessionAML.T0081 Modify AI Agent Configuration; AML.T0080 AI Agent Context PoisoningRead-only instructions, memory integrity
Receive and run tasksThe agent fetches tasks from an attacker-controlled location and runs them with its own tools, then reports or exfiltrates resultsAML.T0108 AI Agent (this page)Tool approval, narrow tools, egress control
HideThe agent is instructed not to mention its actions to the userAML.T0108 descriptionLogs 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 sourceWhat to look forWhy it points to C2
Tool call logA 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 contentThis fetch then execute pair is the C2 loop itself
Tool call log, over timeThe same external address fetched on a regular schedule across sessions, with no user prompt starting the sessionAgent beaconing; same scoring ideas as network beaconing
Instruction and memory filesWrites by the agent to files that feed its system prompt, skills or long-term memoryThe persistence step that keeps the channel alive (AML.CS0051)
Agent response versus actionsTool calls that the final message to the user does not mentionATLAS notes attackers may tell the agent to hide its actions
Endpoint telemetryChild processes of the agent runtime that download, change file permissions or start network listenersAgent used to stage a conventional implant
Egress proxy or AI gatewayAgent identities contacting domains outside their allowlist, newly registered domains or paste and file-sharing servicesCommand 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 typeMain exposurePriority controls
Personal or desktop assistantReads web and email, runs on a user's machine with their accessApproval gates, read-only instructions, local service bound to localhost, endpoint monitoring
Coding agentReads repositories and issues, has a shellSandboxed execution, approval for network and install commands, repository instruction file review
Computer-use or browser agentActs on any page it visitsDisposable VM, no saved credentials, egress proxy, approval for download and execute
Server-side workflow agentProcesses customer content at scale, often unattendedNarrow tools only, strict egress allowlist, gateway guardrails, behaviour baselines

Responding to an agent C2 finding

  1. 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.
  2. Preserve: copy tool call logs, conversation history, instruction, skill and memory files, and proxy logs for the agent's identity before cleaning anything.
  3. Find the persistence: diff instruction, skill and memory files against the last known-good version; look for scheduled tasks or triggers the agent created.
  4. 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.
  5. Rotate: assume every secret the agent could read is exposed, including model provider keys and connected service tokens.
  6. 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

FrameworkReferenceRelevance
MITRE ATLASAML.T0108 AI Agent (AML.TA0014 Command and Control)This technique
MITRE ATLAS mitigationsAML.M0020, AML.M0024 (linked by ATLAS); AML.M0028, AML.M0029, AML.M0030, AML.M0032, AML.M0035Guardrails, telemetry, tool limits, approval, isolation, testing
MITRE ATT&CKT1102 Web Service; T1071.001 Web ProtocolsThe network form the agent's command channel usually takes
OWASP Top 10 for Agentic ApplicationsASI01 Agent Goal Hijack; ASI02 Tool Misuse and Exploitation; ASI10 Rogue AgentsHijacked goals, abused tools and agents acting outside intent
OWASP Top 10 for LLM Applications 2025LLM01 Prompt Injection; LLM06 Excessive AgencyEntry 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

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

Free weekly newsletter

Subscribe to the NHI & AI Identity Journal

The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.

Bonus 33% off our NHI Course when you subscribe.

NHIMG Editorial Note
Researched and written by the NHI Mgmt Group editorial team using AI tools, under the editorial direction of Lalit Choda. Facts are drawn from the sources listed on this page and checked by our automated quality process. Last updated 12 November 2026. Spotted an error? Use our contact page.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM and Agentic AI security. nhimg.org