An attacker who can run code in your environment no longer needs to write a full toolkit: they can start an AI agent, give it a goal and your credentials, and let it work. MITRE ATLAS records this as AML.T0103 Deploy AI Agent, an Execution (AML.TA0005) technique added in January 2026 for the Agentic AI platform and rated as realised. The agent may be a legitimate tool already installed, such as a coding assistant command line, or an open source agent framework the attacker brings in. This guide covers how the technique appears in real cases, what to log and alert on, the inventory and identity controls that make an unregistered agent stand out, and how to contain one. It is for detection engineers, endpoint and cloud security teams, and owners of agent platforms. Finding unsanctioned agents your own staff run is covered in the Shadow AI Discovery Guide; this page focuses on agents launched by an adversary.
Source note: technique, tactic, mitigation and case study details on this page are from MITRE ATLAS release 2026.10 (ATLAS data modified 28 October 2026). Confirm against the official text before relying on it.
Key takeaways
- The agent is the payload. ATLAS describes adversaries launching agents with a system prompt and tools that define their goals, often with excessive trust permissions and user interaction disabled.
- Look for agents running without a human. Non-interactive launches that auto-approve every tool are the clearest host signal, as the Amazon Q extension case (AML.CS0047) shows.
- A registry turns detection into a lookup. If every sanctioned agent has an identity, an owner and a known host, an agent process or agent API traffic that matches no record is an alert.
- Credentials decide the blast radius. A deployed agent uses whatever the host and user can reach: cloud profiles, provider keys, SSH keys and tokens.
- Containment is identity work. Stop the process, revoke the keys it could use, and review what it did through the provider and downstream logs.
What the technique is
ATLAS defines AML.T0103 as adversaries launching AI agents in the victim's environment to act on their behalf. The agent may have access to tools, data sources and permissions across other services. The attacker configures it with an initial system prompt and tool access, which effectively sets its goals, and may grant excessive trust and disable user interaction so that nothing blocks its actions. ATLAS notes that autonomy also means a loss of control for the attacker: the agent decides how to reach its goal, and may do so noisily or incorrectly.
AML.T0103 differs from neighbouring techniques. AML.T0081 Modify AI Agent Configuration changes an agent that is already deployed; AML.T0053 AI Agent Tool Invocation uses a victim's agent to call tools; AML.T0103 brings up a new agent run that the attacker controls. In ATLAS 2026.10 the only mitigation mapped directly to AML.T0103 is AML.M0013 Code Signing ("Allow only trusted signed agent applications to execute in the environment"), so the other controls below draw on the agent permission and monitoring mitigations ATLAS defines for related techniques.
| Deployment form | Example | Where it shows |
|---|---|---|
| Legitimate agent CLI already on the host, launched with a malicious prompt | AML.CS0047: code shipped in an IDE extension started the Amazon Q agent non-interactively with all tools trusted | Process creation and command line on developer endpoints |
| Open source agent framework installed by the attacker | Carbonato: Hermes Agent installed unmodified on compromised Docker hosts, persona file replaced | New files, containers, outbound chat and model API traffic on servers |
| Agent run in attacker infrastructure, acting on your systems | AML.CS0069: GTG-1002 connected a Claude Code agent to scanners and other tools through MCP | Your external logs: scanning, authentication bursts, credential reuse |
Real cases
Amazon Q Developer extension (AML.CS0047)
On 13 July 2025 an actor used an over-scoped GitHub token to commit code to the Amazon Q Developer extension repository for VS Code. The code, released in version 1.84.0 on 17 July, would start an Amazon Q agent with a prompt to return a system to a near-factory state and delete file system and cloud resources. ATLAS records the launch as q --trust-all-tools --no-interactive followed by the prompt. AWS bulletin AWS-2025-015 states the code failed to run because of a syntax error, and AWS published version 1.85.0 and CVE-2025-8217. See Amazon Q Developer Extension Compromise 2025.
GTG-1002 (AML.CS0069)
Anthropic reported in November 2025 that a group it assessed with high confidence as Chinese state-sponsored used Claude Code as the engine of an attack framework against about 30 organisations, with a small number of successful intrusions. Anthropic estimated that AI performed 80 to 90 percent of the campaign, with humans involved at about four to six decision points. The operators split the work into small, innocent-looking tasks and claimed to work for a security firm. ATT&CK tracks the campaign as C0062. See Anthropic GTG-1002 Campaign 2025.
Carbonato botnet
ThreatDown reported in September 2026 that the Carbonato operation compromised Docker daemons exposed without authentication on port 2375, started privileged containers, installed the open source Hermes Agent and replaced its persona file with instructions to collect credentials and take tasks over Telegram. AI provider keys were collected first. See Carbonato Botnet 2026.
What to detect and where
| Signal | Source | Notes |
|---|---|---|
| Agent CLI started with auto-approve or non-interactive options | EDR process events, shell history, CI logs | Expected in some CI jobs; alert when the parent process is an editor extension, package install script or unknown binary |
| Agent process on a host with no registered agent | EDR, software inventory compared with the agent registry | Servers and containers rarely need interactive coding agents |
| New agent framework files or persona and instruction files | File integrity monitoring, container image scanning | Carbonato indicators included /root/.hermes/SOUL.md and a .env with CARBONATO_API_KEY |
| Model API traffic from unexpected hosts or keys | Egress proxy, AI gateway, provider usage logs | Route sanctioned agents through a gateway so direct provider traffic stands out |
| Chat platform traffic from servers | Egress and DNS logs | Carbonato used Telegram for tasking |
| Machine-speed activity from one identity | Identity provider, cloud audit, database logs | GTG-1002 lessons: bursts of authentication, credential reuse across services, account enumeration |
| New agent definitions or API keys on agent platforms | Platform audit logs | Tie each new agent to a change record and owner |
ATLAS mitigation AML.M0024 AI Telemetry Logging and Monitoring supports these signals: keep prompts, tool calls and results for sanctioned agents so that an agent with no telemetry is itself an anomaly. AML.M0038 AI Agent Scope Drift Detection applies when an attacker reuses a sanctioned agent identity for new goals.
Prevention
- Register every agent: record each sanctioned agent with an identity, owner, host or platform, model, tools and credentials. See the AI agent registry guide.
- Give agents their own identities: sanctioned agents should authenticate as themselves with scoped credentials, not with a developer's full cloud profile. Then a process using a human's credentials to drive an agent is detectable. See the Agent Identity and Access Guide.
- Limit permissions (AML.M0026, AML.M0027, AML.M0028): ATLAS defines Manage AI Agent Service Access, Manage User-Delegated AI Agent Access and Enforce Access Controls for AI Agent Tools mitigations for agents. Apply least privilege so an agent started with stolen context inherits little.
- Keep humans on destructive actions (AML.M0029): require confirmation for deletion, credential and infrastructure changes, and alert when that requirement is turned off.
- Control where agent CLIs run (AML.M0013): use application control and signature checks to allow agent binaries only on approved developer endpoints and named CI runners.
- Control egress: allow model and chat API traffic only through approved gateways. See the Agent Egress Control and Network Isolation Guide.
- Protect the delivery paths: the Amazon Q case began with an over-scoped CI token and an automatic release. Scope repository tokens and require review before release.
- Remove reachable secrets: keep provider keys, cloud keys and SSH keys out of files on hosts where agents could be started.
Decision guidance
| Situation | Approach |
|---|---|
| Developer endpoints with sanctioned coding agents | Allow the agent binaries; alert on non-interactive or auto-approve launches whose parent is not the user's terminal or IDE; block auto-approve where the tool supports a managed policy |
| Servers and containers | Treat any agent framework or model API traffic as unexpected unless registered; block by default |
| CI/CD runners | Allow agents only in named workflows with scoped, short-lived tokens; log prompts and tool calls |
| Small organisation | Start with an agent list, provider key inventory and egress allowlist; these cost little |
| Large organisation | Add an AI gateway, EDR detections on agent launches and a registry integrated with identity governance |
Containment and response
- Stop the agent: kill the process or container and isolate the host. See the AI Agent Kill Switch and Containment Guide.
- Preserve evidence: keep the prompt, persona or instruction files, tool configuration, shell history and agent logs before cleanup.
- Revoke credentials: rotate every AI provider key, cloud credential, SSH key and token reachable from the host or user, not only those you saw used.
- Trace actions: use provider usage logs and downstream audit logs to list what the agent did.
- Close the entry point: fix the exposure that let the attacker run code (exposed Docker API, compromised extension, stolen token).
The wider runbook is in the AI Agent Observability and Incident Response Guide.
How to test
- Launch drill: in a test endpoint, start a sanctioned agent CLI non-interactively from an unusual parent process and confirm an alert fires.
- Unregistered agent drill: run an open source agent framework in a test container with a test key and confirm egress controls and the registry comparison catch it.
- Revocation drill: time how long it takes to revoke all AI and cloud credentials on one host.
Measuring it
- Registry coverage: share of agent processes and agent API keys seen in telemetry that match a registry record.
- Unregistered agent alerts: count and mean time to triage.
- Agents with own identity: share of sanctioned agents using a dedicated, scoped credential.
- Direct provider traffic: volume of model API traffic that bypasses the gateway.
Common failure patterns
- Trusting the binary: allowing an agent CLI everywhere because it is a known vendor tool, without watching how it is launched.
- Agents on human credentials: agents using developers' full cloud profiles, so an attacker-started agent looks like the developer.
- No server baseline: no expectation of which servers should talk to model or chat APIs.
- Unscoped release tokens: CI tokens able to commit and release to tools that ship agents to many users.
- Partial rotation: revoking the key seen in use but not the others on the host.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| MITRE ATLAS | AML.T0103 (AML.TA0005); case studies AML.CS0047, AML.CS0069 | The technique and its documented cases |
| MITRE ATLAS mitigations | AML.M0013 (mapped by ATLAS); AML.M0024, AML.M0026, AML.M0027, AML.M0028, AML.M0029, AML.M0038 (related) | Signed agent binaries, telemetry, permissions, human approval, scope drift |
| MITRE ATT&CK v20 | C0062; T1610 Deploy Container; T1059 Command and Scripting Interpreter | Related enterprise behaviour around the agent launch |
| OWASP Agentic Top 10 | ASI10 Rogue Agents; ASI03 Identity and Privilege Abuse | See OWASP Agentic Top 10 ASI10 Guide |
| NIST SP 800-53 Rev. 5 | CM-7, CM-8, AC-2, SI-4 | Least functionality, inventory, accounts, monitoring |
| NIST CSF 2.0 | ID.AM-02, DE.CM-09 | Software inventory and monitoring of runtime environments |
Practitioner checklist
- Register every sanctioned agent with identity, owner, location, tools and credentials.
- Give agents dedicated, scoped credentials.
- Alert on non-interactive or auto-approve agent launches from unusual parents.
- Block agent frameworks and model API traffic on servers unless registered.
- Route model API traffic through an approved gateway.
- Remove AI and cloud secrets from files on hosts.
- Scope CI tokens that can release tools containing agents.
- Rehearse agent containment and full credential rotation.
Standards and references
- MITRE ATLAS: Deploy AI Agent
- MITRE ATLAS: Code to Deploy Destructive AI Agent Discovered in Amazon Q VS Code Extension
- MITRE ATLAS: GTG-1002 Claude Code Espionage Campaign
- AWS: Security Bulletin AWS-2025-015
- Anthropic: Disrupting AI-orchestrated cyber espionage
- MITRE ATT&CK: Anthropic AI-orchestrated Campaign
Related NHI Mgmt Group resources: MITRE ATLAS Guide · Unsanctioned AI Agents and MCP Servers Guide · AI agent registry · MITRE ATLAS AML.T0081 Modify AI Agent Configuration · MITRE ATLAS AML.T0053 AI Agent Tool Invocation · MITRE ATLAS AML.T0050 Command and Scripting Interpreter