AML.T0085 Data from AI Services: How Attackers Collect Data Through AI Assistants and Agents

An enterprise AI assistant can usually see more than any single attacker can: shared drives, mailboxes, CRM records, other users' conversations and its own hidden instructions. MITRE ATLAS tracks the use of that reach to gather sensitive information as AML.T0085 Data from AI Services, in the Collection tactic (AML.TA0009). ATLAS notes that as organisations centralise data access through generative and agentic AI, those services become valuable targets, and that ordinary-looking requests can succeed where authorisation, context isolation or disclosure controls are inadequate. This page covers all four sub-techniques, the ATLAS case studies, the mitigations ATLAS maps to each, and how to detect and contain collection. It is for AI platform owners, IAM teams and SOC analysts.

Key takeaways

• The AI service is a collection point. The attacker borrows the service's permissions, so the blast radius equals everything the assistant or agent can read.
• Four sources, one technique. RAG databases (.000), agent tools (.001), conversation context and memory (.002) and system instructions (.003) are all covered.
• AML.T0057 now lives here. The retired AML.T0057 LLM Data Leakage was absorbed into AML.T0085.002 Conversation Context and Memory in ATLAS 2026.10.
• Authorisation beats refusal. ATLAS maps model alignment and guardrails, but most of its mapped mitigations are about identity: scoped service access, delegated user access and per-call tool authorisation.
• Collection is followed by exfiltration. Data leaves through the inference API, the user interface or an agent tool, so collection controls and egress controls must be designed together.

How the technique works

ATLAS created AML.T0085 in September 2025 and updated it in the October 2026 release (2026.10). It is rated demonstrated and applies to the Generative AI and Agentic AI platforms. The attacker either uses access they already hold (a valid account, a public chatbot) or injects instructions into content the service will process, then asks the service to retrieve data. ATLAS describes three request styles: asking directly, supplying contextual cues, and multi-turn interactions that encourage disclosure. AML.T0054 LLM Jailbreak may be used to get past model restrictions. The enterprise parallel in ATT&CK is T1213 Data from Information Repositories; see the T1213 Data from Information Repositories Defensive Guide.

The key point in the ATLAS description is that the information available to the AI system may exceed what the adversary can access directly, including other users' data. That is a confused deputy problem, and it is an identity problem before it is a model problem.

The four sub-techniques

For deeper treatment of each data store see the RAG Security Guide, the AI Agent Memory Security Guide and the OWASP LLM Top 10 LLM07 System Prompt Leakage Guide.

Case studies

EchoLeak is the clearest enterprise example: no credentials were needed, because Copilot retrieved data with the targeted user's own access. ATLAS records that it was assigned CVE-2025-32711 and has been remediated with no evidence of exploitation in the wild. See EchoLeak 2025: The Zero-Click Prompt Injection That Could Make Microsoft 365 Copilot Leak Company Data. In ZombieAgent, Radware reported the issues to OpenAI from 26 September 2025 and OpenAI fixed them on 16 December 2025, per Radware's write-up.

Where identity fits

Every case above is a question of whose authority the AI service used. ATLAS maps three identity mitigations to AML.T0085, .000 and .001:

• AML.M0026 Manage AI Agent Service Access: limit service identities to data required by approved workflows, authorise who may start them, separate identities across workflows and tenants, and remove obsolete grants.
• AML.M0027 Manage User-Delegated AI Agent Access: give the agent an explicitly delegated subset of the user's permissions, bind access to the authorising user, and expire or revoke it when delegation ends. Avoid broadly privileged shared credentials.
• AML.M0028 Enforce Access Controls for AI Agent Tools: authorise each tool call against the caller, operation and resource, outside the model, and check document-level access before returning RAG results.

A shared service account that can read every mailbox or every ticket turns any injected instruction into a tenant-wide query. See the Permission-Aware RAG Guide and the AI Agent Permission Matrix Template.

Mitigations ATLAS maps to each sub-technique

Blank cells mean ATLAS 2026.10 does not map that mitigation to that sub-technique; they are not a judgement that the control is irrelevant. The MITRE ATLAS Mitigations Guide explains each mitigation.

Three practical points from the ATLAS mapping text and OWASP:

• Inspect outputs against the requester: AML.M0020 asks that proposed disclosures of history, summaries and memory be checked against the requesting user's authorisation and current task, and that responses reproducing protected instructions be blocked or redacted.
• Keep secrets out of instructions: OWASP LLM07:2025 says the system prompt should not be considered a secret or used as a security control; credentials and connection strings do not belong there.
• Test with canaries: AML.M0035 suggests synthetic secrets or canary records in representative data sources, then attempted extraction through prompts, retrieval, tools and rendered output.

Detection

Measuring it

• Delegation coverage: share of AI data connections using per-user delegated access rather than a shared service identity.
• Retrieval scope: number of collections each agent identity can read versus the number its workflows use.
• Canary hits: canary record retrievals in production (any hit is an incident) and in red team tests (target falling).
• Bulk read alerts: volume and triage time of bulk retrieval alerts from AI services.
• Memory review: share of assistants where stored memory is reviewable and has a retention limit.

Implementation

1. Map reach: for each assistant and agent, list the identities it uses and every data source, tool and memory store reachable through them.
2. Switch to delegated access where possible: agents acting for a user should use that user's scoped, delegated token; service identities only for approved workflows with narrow grants.
3. Enforce authorisation outside the model: tool servers and retrieval layers check caller, operation and document permissions on every call.
4. Separate untrusted input from privileged context: content from external email, tickets or web pages should not drive tool calls over sensitive data without confirmation. Microsoft's CI/CD guidance describes this as not combining untrusted input, access to sensitive data or tools, and external communication in one workflow.
5. Turn on logging and output inspection: start in alert-only mode for two to four weeks, tune, then block for high-confidence patterns such as canary values and secret formats.
6. Red team: seed canary records and attempt collection through each of the four sub-techniques before release and after model or connector changes.
7. Roll back safely: keep previous permission sets and connector configurations versioned so tightened scopes can be reverted if a workflow breaks, and review the gap rather than restoring broad access permanently.

Response when collection is suspected

• Contain: disable the affected connector or agent trigger, and revoke the tokens of the agent identity involved.
• Preserve: prompts, retrieved document IDs, tool call logs, memory entries and model responses for the session window.
• Scope: use retrieval and data source audit logs to list exactly which records were read, since this drives breach notification decisions.
• Clean: remove injected content from mailboxes, tickets, documents and memory so it does not fire again.
• Rotate: any secret that appeared in context, instructions or retrieved content.

Framework mapping

Common failure patterns

• Tenant-wide service identity: one agent account that can read every mailbox, site or ticket; in AML.CS0039 the AI action ran with an internal engineer's broad privileges.
• Trusting the refusal: relying on model alignment alone when ATLAS also maps access control and segmentation.
• Retrieval without document checks: RAG indexes built with an admin crawler and served to every user.
• Unbounded memory: memory that any processed content can write to, with no user review or retention limit.
• Secrets in context: keys in system prompts or environment variables an agent can read, as in AML.CS0067.
• Output scanning only on exact patterns: secret scanners missed a key with its prefix removed in AML.CS0067.

Practitioner checklist

• List every data source, tool and memory store each AI service can reach.
• Use per-user delegated access for assistants acting for users.
• Scope service identities to approved workflows and review grants quarterly.
• Authorise every tool call and retrieval outside the model.
• Keep credentials and access rules out of system instructions.
• Log requests, retrievals, tool calls, memory changes and responses.
• Seed canary records and alert on any production retrieval of them.
• Require confirmation before tools act on data after processing external content.
• Include all four sub-techniques in AI red team tests.

Standards and references

• MITRE ATLAS: Data from AI Services
• MITRE ATLAS: Enforce Access Controls for AI Agent Tools
• MITRE ATLAS: EchoLeak, Zero-Click Prompt Injection Targeting M365 Copilot
• MITRE ATLAS: Living Off AI, Prompt Injection via Jira Service Management
• OWASP: LLM02:2025 Sensitive Information Disclosure
• OWASP: LLM07:2025 System Prompt Leakage
• Cato Networks: PoC attack targeting Atlassian's MCP
• Radware: ZombieAgent

Related NHI Mgmt Group resources: MITRE ATLAS Guide · MITRE ATLAS AML.T0024 Exfiltration via AI Inference API · MITRE ATLAS AML.T0083 Credentials from AI Agent Configuration · OWASP LLM Top 10 LLM02 Sensitive Information Disclosure Guide