AML.T0064 Gather RAG-Indexed Targets: Protecting RAG Sources From Attacker Target Mapping

An attacker who knows which mailboxes, sites and repositories your retrieval system reads knows exactly where to plant content that your AI will later trust. MITRE ATLAS tracks this reconnaissance step as AML.T0064 Gather RAG-Indexed Targets, in the Reconnaissance tactic (AML.TA0002). ATLAS describes adversaries identifying the data sources used in retrieval augmented generation (RAG) systems so they can focus poisoning or manipulation on the external repositories the AI relies on, and notes that those sources can be found in public documentation or by interacting with the system and watching for references to external data. This page covers how that mapping happens, what it leaves in your logs and how to make it expensive. It is for teams that run copilots, RAG chat assistants and agents with knowledge connectors. The poisoning that follows is AML.T0070 RAG Poisoning; for RAG architecture controls see the RAG Security Guide.

Key takeaways

• It is the planning step for poisoning. Target mapping tells the attacker which source to write to; without it, poisoning is guesswork.
• Write paths matter more than secrecy. The most useful finding for an attacker is a source they can write to from outside, such as an inbox the assistant indexes or a shared site with broad edit rights.
• Your assistant may answer the question for them. Citations, connector names and tool descriptions returned in answers reveal the index layout to anyone who can chat with the system.
• ATLAS maps one mitigation. AML.M0000 Limit Public Release of Information, applied as withholding public documentation that identifies RAG data sources, indexes and retrieval architecture.
• Detection lives in conversation and retrieval logs. Questions about the system's own sources, and sessions that probe many topics to see what gets cited, are the observable signal.

What the technique is

A RAG system answers questions by searching an index built from connected sources, then placing the retrieved chunks into the model's context. The answer is only as trustworthy as the least controlled source in that index. AML.T0064 is the attacker working out what those sources are and which of them they can influence.

ATLAS created the technique on 12 March 2025, last modified it on 27 May 2026, rates its maturity as Demonstrated and lists the Generative AI and Agentic AI platforms. It sits beside other AI reconnaissance and discovery techniques, and the distinction decides which controls apply.

In practice these are often done in the same session, together with AML.T0133 Discover AI Agent Runtime Capabilities on the agent tooling side.

How attackers map RAG sources

Public information

• Product and help documentation: pages that say "our assistant answers from the help centre, the community forum and release notes" give the attacker a list of sources and, for a forum, a write path.
• Vendor platform behaviour: widely deployed copilots have documented indexing behaviour. ATLAS case study AML.CS0026 (Financial Transaction Hijacking with M365 Copilot as an Insider) records that the researchers identified that Microsoft Copilot for M365 indexes all emails received in an inbox, even if the recipient does not open them. That single fact turns every external sender into a potential author of indexed content.
• Job adverts, conference talks and engineering blogs: descriptions of the vector store, connector set and chunking approach.

Interacting with the system

• Citations and source cards: an answer that shows file names, site paths or mailbox subjects tells the user, and an attacker posing as one, where the index reaches.
• Self-description: asking the assistant what it has access to. Zenity Labs showed an email-triggered Copilot Studio agent disclosing its knowledge source names, connected tools and the internal search tool it used; the researchers reported it to MSRC in February 2025 and Microsoft fixed it in April 2025.
• Topic sweeps: asking about many subjects and noting which return grounded, cited answers. This reveals coverage without ever asking about sources directly.
• Exposed agents: at Black Hat 2024 Zenity reported finding tens of thousands of publicly reachable Copilot Studio bots, attributing much of it to bots published without authentication by default. Anyone who can reach an agent can map its knowledge.

Why it matters: the EchoLeak pattern

In EchoLeak 2025 (CVE-2025-32711), the researchers knew that inbound email would be retrieved alongside internal material, and spread their payload across emails about common topics such as onboarding and HR so that routine questions would pull it in. That is target mapping put to work: knowing the source (the inbox) and the queries that hit it. Microsoft fixed the issue server-side and reported no exploitation in the wild.

Which sources attackers want

Rank your own sources the way an attacker would. The question is not "is this source sensitive" but "can someone outside the trust boundary put text into it that will be retrieved".

Deeper threat modelling of each source is covered in Threat Modelling RAG Systems.

Reducing what can be mapped

1. Apply AML.M0000 to RAG architecture. Review public documentation, trust centre pages and marketing for statements that list the exact sources, connectors and index layout. Describe the assistant's capability to users without publishing an index map. Keep the architecture in internal documentation with need-to-know access.
2. Require authentication on every agent. In Microsoft Copilot Studio, for example, the No authentication option lets anyone with the link chat with the agent; Microsoft recommends applying authentication, especially for agents used inside the organisation. Inventory agents and their authentication setting, because older agents may predate current defaults.
3. Control what the assistant says about itself. Instruct the system not to enumerate its sources, connectors or tool names, and enforce it with an output check, since instructions alone are not a boundary. Keep internal tool and index names out of user-visible text.
4. Show citations users need, not the index layout. Return a document title and a link the user can already open. Avoid exposing storage paths, collection names or source system identifiers in answers.
5. Close or label the write paths. For each high-value source in the table above, decide whether external-origin content is indexed at all. Where it must be, tag it at ingestion and keep it in a separate, lower-trust collection.
6. Treat the index map as sensitive configuration. Record each source, its owner, who can write to it and whether external parties can, in the same inventory as other non-human identities and service connectors. See the Vector Database Security Guide for store-level access.

Secrecy alone does not stop a determined attacker: a topic sweep still reveals coverage. Reducing the write paths is what removes the payoff; reducing disclosure raises the cost and makes the probing visible.

Detection and measurement

Detection depends on AML.M0024 AI Telemetry Logging and Monitoring: keep the user prompt, retrieved chunk IDs and source, the answer, and the caller identity for every request. Then look for:

• Self-referential questions: prompts asking which sources, connectors, folders, mailboxes or tools the assistant uses. Classifiers can help here; Microsoft Prompt Shields, for example, lists "Information Gathering" as one of its document attack categories.
• Coverage sweeps: one identity asking many unrelated questions in a short window, with a high share of responses that return citations, and little follow-up on any one topic.
• Anonymous or external callers: any conversation with an agent from an unauthenticated channel that touches internal topics.
• Retrieval of fresh external-origin content: chunks from inbound email, forms or public pages that were ingested recently and are being retrieved for many users' questions. This is the downstream sign that mapping has turned into placement.
• Decoys: AML.M0039 AI Honeypots suggests monitored decoy resources that legitimate users have no reason to touch. A decoy document or collection that should never be cited, or a canary phrase in documentation, gives a high-confidence alert when an outsider finds it.

How to test

1. From an ordinary user account, and separately from any unauthenticated channel, ask the assistant to describe its sources, then run a topic sweep. Record what it reveals.
2. Search your own public sites for statements that name connectors, indexes or sources.
3. Send an email from an external test domain on a common topic and check whether it is retrieved, and whether it is labelled as external. Do this in a test tenant first.
4. Confirm that each test triggers the detection you expect, and fix the gap before moving to poisoning tests in a red team exercise (see the AI Red Teaming Guide).

Common failure patterns

• Citations that print storage paths. Helpful for users, and a free map for anyone who can chat.
• Public agents created for a pilot. An agent published without authentication and connected to internal knowledge stays reachable after the pilot ends.
• Inbound mail treated as internal data. Indexing every received email gives every outside sender a write path into the index.
• Trusting the system prompt to keep secrets. An instruction not to list sources is easily bypassed; see OWASP LLM Top 10 LLM07 System Prompt Leakage Guide.
• No source inventory. Teams cannot say which sources an assistant reads, so they cannot rank write paths or notice a new connector.

Framework mapping

Practitioner checklist

• List every source each RAG assistant indexes, with owner and who can write to it.
• Mark every source with an external write path and decide whether it is indexed.
• Remove index maps, connector lists and storage paths from public documentation.
• Require authentication on every agent connected to internal data.
• Strip storage paths and internal tool names from answers and citations.
• Log prompt, retrieved chunk IDs, source and caller for every request.
• Alert on source-enumeration questions and coverage sweeps.
• Place a decoy document or canary phrase and alert on any retrieval of it.

Standards and references

• MITRE ATLAS: Gather RAG-Indexed Targets (AML.T0064)
• MITRE ATLAS: Limit Public Release of Information (AML.M0000)
• MITRE ATLAS: Financial Transaction Hijacking with M365 Copilot as an Insider (AML.CS0026)
• OWASP: Top 10 for LLM Applications 2025
• Microsoft Learn: Configure user authentication in Copilot Studio
• Microsoft Learn: Prompt Shields
• Zenity Labs: A Copilot Studio Story, discovery phase in AI agents
• The Register: Copilot vulnerabilities presented at Black Hat 2024

Related NHI Mgmt Group resources: RAG Security Guide, MITRE ATLAS AML.T0071 False RAG Entry Injection, Securing Microsoft Copilot Studio Agents Guide, MITRE ATLAS Guide.