ATLAS Collection Tactic (AML.TA0009) Guide: Stopping Data Gathering Through AI Systems

AI assistants and agents are built to find and summarise an organisation's data on request, which makes them the most efficient collection tool an attacker can borrow, and the MITRE ATLAS Collection tactic (AML.TA0009) describes how that borrowing happens. ATLAS defines the tactic as the adversary "trying to gather AI artifacts and other related information relevant to their goal", and notes that the usual next step is exfiltration or staging future operations. Collection in ATLAS covers two kinds of target: AI artifacts such as models, datasets and model outputs, and the enterprise data that AI services, RAG indexes and agent tools can reach. This hub explains the tactic in practice, ranks its 9 techniques for defenders, traces how collection chains in documented cases, and sets detection and mitigation priorities. It is written for AI platform owners, data security and DLP teams, detection engineers and identity teams. For the framework overview, see the MITRE ATLAS Guide.

Key takeaways

• Data from AI Services leads the case data. AML.T0085 appears in 8 of the ATLAS case studies, through RAG databases, agent tools and conversation memory, ahead of every other Collection technique.
• The agent's permissions are the attacker's permissions. ATLAS maps four agent access mitigations (AML.M0026, AML.M0027, AML.M0028, AML.M0032) to AML.T0085, because the data collected is whatever the agent's identity can read.
• Model outputs are a collectable asset. Outputs from AI Models (AML.T0135) appears in 6 cases, including the industrial-scale distillation campaigns attributed by NSA, CISA and FBI.
• Classic collection still matters on AI infrastructure. Data from Local System (AML.T0037) appears in 6 cases and Data from Information Repositories (AML.T0036) in 4, and ATLAS maps no mitigation to either.
• Collection is the last cheap point to intervene. Telemetry on retrieval, tool calls and bulk reads (AML.M0024) catches activity before data leaves through a rendered link, an email or a tool call.

What AML.TA0009 means in practice

ATLAS adapts the ATT&CK Collection tactic (TA0009). Its description names software repositories, container registries, model repositories and object stores as common sources. In 2026 the techniques fall into three groups.

• Collection through the AI service: the attacker uses a prompt, an injected instruction or a compromised agent to make the AI retrieve data for them from RAG databases, agent tools, conversation memory or its own system instructions (AML.T0085).
• Collection from the AI model: the attacker gathers outputs for distillation or analysis (AML.T0135), infers or extracts training data (AML.T0137) or recovers model internals (AML.T0144, also listed under Discovery).
• Collection on AI infrastructure: stealing model files and datasets (AML.T0035), mining repositories (AML.T0036), searching hosts (AML.T0037), automating bulk gathering (AML.T0126) and staging data before exfiltration (AML.T0127).

Every technique in the tactic

The table lists every technique and sub-technique ATLAS (data release 2026.10) assigns to AML.TA0009, with maturity and the number of ATLAS case studies that use it under this tactic.

Method: case counts are distinct ATLAS case studies (77 in the 2026.10 release) with at least one procedure step using the technique, or for a parent technique any of its sub-techniques, tagged to AML.TA0009. In total, 26 of the 77 case studies include a Collection step. A zero means no case study step is currently tagged to Collection, not that the technique is theoretical: maturity is shown separately.

Where to start: the techniques that matter most

1. Data from AI Services (AML.T0085), especially AI Agent Tools and RAG Databases. Eight cases, including EchoLeak, the Zenity Copilot Studio agent, Jira Service Management "Living Off AI", the Gemini calendar invitation attacks, ZombieAgent and the Morris II worm. For most enterprises running copilots and agents, this is the collection that matters first.
2. Data from Local System (AML.T0037). Six cases, from the compromised PyTorch dependency chain to LAMEHUG malware and the GTG-1002 and OpenAI evaluation agent incidents. Developer machines, notebooks and agent hosts hold keys, tokens and configuration.
3. Outputs from AI Models (AML.T0135). Six cases, now dominated by distillation campaigns against model providers. A priority for anyone whose model behaviour is itself the asset.
4. AI Artifact Collection (AML.T0035). Four cases, including ShadowRay and the Google Photos model extraction. Model weights and training data are valuable, and often sit on clusters and buckets built for speed rather than control.
5. Data from Information Repositories (AML.T0036). Four cases, including the ClearviewAI misconfiguration and multi-agent attacks on government systems: wikis, ticketing and code repositories mined directly or by agents.
6. Automated Collection (AML.T0126), Data Staged (AML.T0127) and Training Data Information (AML.T0137). Lower counts today, but automation by agents changes the scale of collection, and training data inference is the privacy risk for models trained on personal data.

How collection chains in real cases

The EchoLeak case shows collection by proxy: Copilot searched the data the victim could access and placed it into a link the browser fetched automatically. In the Gemini calendar case, the assistant summarised private meetings into a new event the attacker could see; Google's response included asking for user confirmation before creating events. ShadowRay is the infrastructure version: exposed Ray clusters yielded cloud and AI service tokens, database credentials and SSH keys alongside models and datasets. The OpenAI and Hugging Face incident shows autonomous agents collecting service-account tokens, instance role credentials and stored secrets at scale.

Detection priorities across the tactic

ATLAS does not publish per-technique analytics; these priorities follow from the technique descriptions, the case procedures and AI Telemetry Logging and Monitoring (AML.M0024).

• Retrieval telemetry: log which documents each RAG query returned, for which identity, and alert on retrieval of sensitive labels in sessions that also contain external content such as inbound email or web pages (AML.T0085.000).
• Tool call telemetry: log every agent tool call with caller, delegated user, parameters and data volume; alert on read-then-send sequences and on tools reading far more records than the task needs (AML.T0085.001, AML.T0126).
• Memory and context access: log reads and writes of long-term memory and alert on responses that echo system instructions or other users' context (AML.T0085.002, AML.T0085.003).
• Query volume and pattern: track per-account and cross-account query volume, prompt templates and capability targeting to spot distillation and training data extraction (AML.T0135, AML.T0137).
• Artifact and repository reads: alert on bulk downloads from model registries, dataset buckets, wikis and code repositories by unusual principals, including AI workloads (AML.T0035, AML.T0036).
• Host and staging: reads of credential files and configuration by agent processes, and archive or staging directories created on AI hosts (AML.T0037, AML.T0127).

For telemetry design, see the AI Agent Observability and Incident Response Guide.

Mitigation priorities from ATLAS

Data from Information Repositories and Data from Local System have no ATLAS mitigation mapped. Rely on repository access control, data classification and endpoint controls on AI hosts. The MITRE ATLAS Mitigations Guide covers each mitigation in depth.

Where identity fits

Collection through AI is bounded by the identity the AI acts as. A user-delegated copilot collects what the user can read; a service agent collects what its workload identity can read, often more than any single user. That is why ATLAS separates service agent access (AML.M0026) from user-delegated access (AML.M0027).

• Prefer user-delegated access for retrieval: so the agent cannot read beyond the requesting user, and enforce document permissions at query time in RAG. See the RAG Security Guide.
• Scope tool credentials to the task: read-only where possible, limited record counts, no send capability on the same agent that reads sensitive data unless approved.
• Keep secrets out of reach: agent hosts and CI runners are rich collection targets; inject short-lived credentials at runtime instead of files and environment variables. See Runtime Secrets Injection for AI Agents Without Prompt Exposure.

Framework mapping

Common failure patterns

• Service identity for retrieval: a copilot indexes everything with one service account, so any user or injected prompt can retrieve anything.
• Read and send on one agent: the same agent can read sensitive data and email or post externally, with no approval step between them.
• No retrieval logs: prompts are logged but retrieved documents and tool results are not, so investigators cannot see what was collected.
• Exposed AI compute: clusters and notebooks reachable without authentication, holding models, datasets and credentials, as ShadowRay showed.
• Secrets in agent environments: tokens in environment variables of processes that read untrusted input.
• Unlimited query volume: no per-account or cross-account controls on model queries, leaving distillation and extraction unchecked.

Coverage checklist for AML.TA0009

• For each AI service and agent, list the data sources, tools and identities it uses and the technique rows above that apply.
• Confirm retrieval honours source permissions for the requesting user.
• Log retrieval results, tool calls and memory access with identity, and retain them for investigations.
• Separate read and send capabilities, or gate sends with approval.
• Protect model and dataset stores with authentication, encryption and listing restrictions.
• Apply query limits and extraction detection on externally exposed models.

Practitioner checklist

• Run a prompt injection test that asks each agent to gather and send sensitive data, and confirm it is blocked or logged.
• Switch RAG retrieval to user-delegated, permission-aware access where possible.
• Cap records per tool call and alert on bulk reads by agents.
• Block rendering of external links and images in assistant output unless allow-listed.
• Require authentication on Ray, Jupyter and other AI compute endpoints, and remove internet exposure.
• Move agent and CI secrets from files and environment variables to runtime injection.
• Monitor model query volume per account and across related accounts.
• Review memory features: what is retained, for how long, and who can read it.

Standards and references

• MITRE ATLAS: Collection (AML.TA0009)
• MITRE ATLAS: atlas-data repository (techniques, mitigations and case studies)
• MITRE ATLAS: Data from AI Services (AML.T0085)
• MITRE ATLAS: AI Telemetry Logging and Monitoring (AML.M0024)
• MITRE ATT&CK: Collection (TA0009)
• OWASP: LLM02:2025 Sensitive Information Disclosure
• OWASP: LLM06:2025 Excessive Agency

Related NHI Mgmt Group resources: MITRE ATLAS Guide, MITRE ATLAS Mitigations Guide, RAG Security Guide, Context Window Data Exposure, Membership Inference Attacks.