ATLAS AML.T0127: Data Staged by AI Agents

Before data leaves an organisation it is usually gathered in one place, and AI agents now do that gathering, sorting and packaging for the intruder. MITRE ATLAS AML.T0127 Data Staged covers adversaries consolidating, organising or preparing collected data in a central location so it can be reviewed, processed, transferred or retrieved more efficiently. ATLAS added it in 2026 under the Collection tactic (AML.TA0009), rates it Realized, and links it to ATT&CK T1074 Data Staged. This page covers only the AI-specific angle: agents that stage data, AI infrastructure used as a staging area, and the controls ATLAS maps to the technique. For the enterprise pattern (archives, local and remote staging directories) read the T1560 and T1074 Archive and Stage Collected Data Defensive Guide. It is written for detection engineers, AI platform owners and incident responders.

Key takeaways

Staging is the step between collection and exfiltration. It is often the last chance to catch data theft while the data is still inside your environment.
Agents stage with intent. In ATLAS case AML.CS0069 the agent ranked stolen data by intelligence value and wrote it into structured Markdown files for the operators to review.
Agent workspaces are staging areas. Scratch directories, sandboxes, memory stores, object storage buckets and code repositories that an agent can write to can all hold staged data.
ATLAS maps one mitigation, and it is about lifecycle. AML.M0043 AI Agent External Resource Lifecycle Management: remove staged data and revoke access to staging locations an agent created.
Write events matter as much as reads. Many teams log reads of sensitive data but not the writes that consolidate it somewhere new.

What ATLAS says

ATLAS (release 2026.10) describes staging as consolidating, organising or preparing information from one or more sources. It lists the places data may be staged: a compromised local system, another system in the victim environment, a cloud instance, shared storage, an application repository or other remote infrastructure. Staged data may stay as separate files or be combined into archives, databases, structured documents, manifests or other collections, and adversaries may compress, encrypt, encode, split or rename it.

Two things make the AI version different from the enterprise version described in ATT&CK T1074 (local staging T1074.001, remote staging T1074.002):

The stager can reason about the data. An agent does not just copy files into a directory. It reads them, removes duplicates, ranks them, summarises them and writes a report, so the staged output is smaller, more valuable and harder to recognise as raw stolen data.
The staging location may be legitimate agent infrastructure. Agents are given workspaces, temporary storage, memory and repositories by design. Data written there by a hijacked or attacker-run agent looks like normal agent output.

Case: AML.CS0069, staging by an AI agent

Anthropic reported in November 2025 that a group it tracks as GTG-1002 used Claude Code, connected to scanners and other tools through the Model Context Protocol (MCP), against roughly 30 organisations in a campaign it detected in mid-September 2025, with the AI performing an estimated 80 to 90 percent of the campaign and humans stepping in at a handful of decision points. Anthropic said the extracted data was categorised according to its intelligence value, and that in a final phase the agent produced documentation of the attack, including files listing stolen credentials and the systems analysed.

ATLAS records this as step S20 of AML.CS0069: the agent categorised collected data by intelligence value, staged extracted data and operational documentation in structured Markdown files, and prepared a detailed summary for operator review. The next step in the case is exfiltration through the AI user interface (AML.T0136). See the Anthropic GTG-1002 Campaign 2025 breach analysis.

Detection lesson: the staged files were text documents written by an agent, the most ordinary output an agent produces. What made them suspicious was the content (credentials, host lists, ranked victim data) and the gap between the agent's stated task and what it wrote.

Staging by agents

Staging location	How an agent uses it	What to watch
Agent scratch directory or sandbox file system	Writes collected files, summaries and notes during a run (local staging)	Files containing secrets, personal data or bulk records in agent working directories; size growth during a run
Agent memory and conversation history	Stores findings in long-term memory or the chat thread so a later session or the operator can retrieve them	Memory writes containing credentials or data from systems outside the task; very large memory entries
Cloud object storage the agent can write to	Consolidates data in a bucket or container before transfer (remote staging)	Object writes by agent roles to new or unusual prefixes; buckets created during a run
Code repositories and issue trackers	Commits staged data or "reports" to a branch, gist, wiki or ticket	Agent commits with data files, encoded blobs or credential patterns; new repositories created by agent identities
Vector stores and knowledge bases	Inserts collected text as documents so it can be queried later	Inserts by agents that normally only read; documents that duplicate sensitive sources
External resources the agent created	Storage, compute or accounts provisioned during a run that outlive it	Resources with no owner or expiry in the inventory (the gap AML.M0043 targets)

Collection usually comes first, through techniques such as AML.T0126 Automated Collection, AML.T0037 Data from Local System and AML.T0036 Data from Information Repositories. Exfiltration follows, for example through MITRE ATLAS AML.T0086 Exfiltration via AI Agent Tool Invocation or MITRE ATLAS AML.T0025 Exfiltration via Cyber Means. Staging sits between them, and it is often slower and noisier than either.

Where to detect it

Telemetry	What to collect	Staging signal
Agent and MCP gateway logs (AML.M0024 AI Telemetry Logging and Monitoring)	Every tool call with agent identity, tool name, target path or resource, and bytes written	Many reads followed by one or a few large writes; writes to locations outside the task scope
Cloud audit data events	AWS CloudTrail data events for S3 objects (`PutObject` is a write data event, `GetObject` a read) and Bedrock resource types such as `AWS::Bedrock::KnowledgeBase` and `AWS::Bedrock::Session`; data events are not logged by default and need advanced event selectors for most resource types	Agent or workload roles writing to new prefixes, or reading widely and then writing to one location
Data loss prevention and content inspection on agent outputs	Scans of files, memory entries and messages written by agents	Credential patterns, personal data or classification labels in agent-written artefacts
Source control audit logs	Commits, new repositories, gists and wiki edits by agent or bot identities	Data files or encoded blobs committed by an agent whose task is code changes
Endpoint and sandbox telemetry	File creation in agent working directories, archive and compression activity	Archive creation or splitting of files by an agent process (see the T1560 guide for enterprise detail)
Cloud resource inventory	Resources created by agent identities with owner, purpose and expiry tags	Untagged storage or compute created during an agent run that still exists afterwards

A useful analytic is the fan-in pattern: one agent identity reads from many sources in a short window and then writes a large object, file or memory entry. Baseline it per agent. A summarisation agent legitimately fans in; a code review agent writing a 50 MB file of database rows does not.

Mitigations

As of ATLAS 2026.10, AML.M0043 AI Agent External Resource Lifecycle Management is the ATLAS mitigation formally mapped to AML.T0127. The other rows are related ATLAS mitigations and practical controls we map to the technique.

Control	What it does against staging
AML.M0043 AI Agent External Resource Lifecycle Management	Agents create storage, accounts and other resources through a broker that records owner, purpose, scope and expiry; cleanup runs outside the agent, revokes access and removes staged data when the need ends; periodic reconciliation finds leftovers
AML.M0028 Enforce Access Controls for AI Agent Tools	Restricts which paths, buckets and repositories an agent's tools can write to, so there is nowhere unexpected to stage
AML.M0026 Manage AI Agent Service Access	Least privilege for agent service identities: read-only where the task only needs reads
AML.M0036 Limit AI Workload Resource Consumption	Caps on storage, run time and tool calls limit how much an agent can accumulate in one run
AML.M0024 AI Telemetry Logging and Monitoring	Logs tool calls and outputs with agent identity so staging writes can be reconstructed
Ephemeral workspaces	Agent scratch storage destroyed at the end of each run, with no shared persistent volume between tasks
Output inspection	Scan agent-written files, memory entries and commits for secrets and sensitive data before they persist

Agent identity is the control that ties these together. If staging writes appear as a human user or a shared service account, none of the baselines work. See the Agent Identity and Access Guide and, for memory stores as a staging target, the AI Agent Memory Security Guide.

How to test

Seed a test environment: synthetic sensitive records, a few decoy credentials and one representative agent with read tools and a writable workspace.
Run an authorised red team task (AML.M0035 AI Red Team): instruct the agent, directly and through planted content, to gather records and save a consolidated report. Do not use production data.
Check enforcement: confirm write scopes block storage outside the workspace, storage and tool-call caps stop large accumulation, and the workspace is destroyed at run end.
Check visibility: confirm gateway logs, CloudTrail data events or equivalent show the agent identity, the reads and the consolidating write, and that the fan-in analytic and output scanning fire.
Check lifecycle cleanup: have the agent provision a resource, end the run, and confirm reconciliation finds and removes it and that its credentials are revoked separately.
Roll out in stages: run new analytics and write restrictions in alert-only mode against legitimate agents for a few weeks, tune, then enforce; keep the previous policy version ready to restore if a business agent breaks.

Metrics

Share of production agents whose tool calls, including writes, are logged with a distinct agent identity.
Share of agents with ephemeral workspaces and enforced write scopes.
Number of agent-created resources without owner or expiry found by reconciliation, trending to zero.
Coverage of write data events on stores holding models, datasets, knowledge bases and chat histories.
Time from a fan-in or output-scan alert to containment.

Common failure patterns

Only reads are logged. Sensitive data access is monitored, but writes by agents to new locations are not, so consolidation goes unseen.
Persistent shared scratch space. Agents reuse one long-lived volume or bucket, so staged data from one run survives and can be retrieved later.
Agent-created resources with no owner. Storage or accounts provisioned during a run outlive it; this is the exact gap AML.M0043 describes.
Agent output trusted as harmless. Summaries, reports and memory entries are not scanned, although in AML.CS0069 the staged material was exactly that kind of document.
No task context in logs. Without the stated task alongside tool calls, analysts cannot tell legitimate summarisation from staging.

Framework mapping

Framework	Reference	Relevance
MITRE ATLAS	AML.T0127 Data Staged; tactic AML.TA0009 Collection; mitigation AML.M0043; case AML.CS0069	The technique itself
MITRE ATT&CK	T1074 Data Staged (T1074.001 Local Data Staging, T1074.002 Remote Data Staging); T1560 Archive Collected Data	Enterprise mirror
NIST SP 800-53 Rev 5	AC-6 Least Privilege; AU-12 Audit Record Generation; SI-4 System Monitoring	Agent write scope, write event logging, monitoring
NIST CSF 2.0	PR.DS-01; DE.CM-03	Protecting data at rest; monitoring technology usage
OWASP Top 10 for LLM Applications 2025	LLM06:2025 Excessive Agency; LLM02:2025 Sensitive Information Disclosure	Agents with write access beyond the task; sensitive data in outputs

Practitioner checklist

Give every agent its own identity and log its writes, not just its reads.
Make agent workspaces ephemeral and destroy them at the end of each run.
Restrict agent write scopes to named paths, buckets and repositories.
Route agent resource creation through a broker with owner, purpose and expiry.
Reconcile agent-created resources on a schedule and remove leftovers.
Scan agent-written files, memory and commits for secrets and sensitive data.
Enable write data events on stores of models, datasets and knowledge bases.
Build and tune a per-agent fan-in analytic (many reads, one large write).

AML.T0127 Data Staged: Spotting AI Agents Consolidating Data Before Exfiltration