MITRE ATLAS AML.T0082 RAG Credential Harvesting: Detection, Mitigation and Response

Every password, API key and connection string that people paste into wikis, tickets, chat channels and shared drives becomes searchable the moment an AI assistant indexes those sources. MITRE ATLAS tracks the abuse of that search as AML.T0082 RAG Credential Harvesting, in the Credential Access tactic (AML.TA0013): an adversary uses access to a large language model on the victim's system to pull credentials that were ingested into a retrieval augmented generation (RAG) store. The Threat Modelling RAG Systems guide places this threat in the wider RAG model; this page goes deeper on the technique itself: how harvesting happens, how to find credentials before an attacker does, what to log, and what to do when a secret has been retrieved. It is for platform owners of AI assistants and enterprise search, secrets management teams and SOC analysts.

Key takeaways

• The secret was already exposed; RAG makes it findable. A key pasted into a ticket in 2021 was hard to find. Once indexed, a single natural language question can surface it.
• Two attacker paths, one fix. Harvesting works through a stolen user account or through an injected prompt that makes the assistant search for keys on the victim's behalf; both fail if the corpus holds no live secrets.
• Scan before you index. Secret detection belongs in the ingestion pipeline, not only in code repositories.
• Permissions decide the blast radius. ATLAS maps two mitigations to AML.T0082: AML.M0026 for privileged agents and AML.M0027 for agents that inherit the user's permissions.
• A retrieved secret is a leaked secret. If logs show a credential in a retrieval result or model response, rotate it; deleting the source document is not enough.

How the technique works

ATLAS added AML.T0082 on 30 September 2025 and rates it as demonstrated. Its description is short: credentials stored in internal documents can be ingested into a RAG database by accident, where an AI agent can later retrieve them. The technique sits next to several related ATLAS entries that describe the same chain from other angles.

Route 1: an attacker with a user's access

An adversary who holds a valid account (AML.T0012 Valid Accounts), a stolen session or a compromised device can ask the assistant directly for "the production database password" or "any AWS keys in the platform team's pages". The assistant returns whatever that user is entitled to read. Keyword search could do the same, but semantic retrieval is better at finding secrets described in prose, such as "the login for the billing portal is ...".

Route 2: an outsider steering the assistant

ATLAS case study AML.CS0035 (Data Exfiltration from Slack AI via Indirect Prompt Injection, August 2024) shows the indirect path. A researcher with an ordinary account posted a message in a public channel containing retrieval bait and hidden instructions. When the victim later asked the assistant for their API key, the assistant retrieved both the key from the victim's private channel and the planted instructions, then rendered a link with the key encoded in the URL. The planted content reached the index through a public-facing input, which is the pattern covered in the MITRE ATLAS AML.T0093 Prompt Infiltration via Public-Facing Application guide.

Where credentials hide in a RAG corpus

Most RAG corpora are built from collaboration content, not code, and that content is rarely covered by secret scanning. In our experience the following sources produce most of the findings.

Embeddings do not make a secret safe. The vector store usually keeps the original text chunk next to the vector for retrieval, and research referenced in the Vector Database Security Guide shows text can be partly recovered from embeddings. Treat the index as a copy of the source.

Prevention: keep secrets out of the index

The steps below are NHI Mgmt Group recommendations, drawn from the ATLAS mitigations and our own practice.

1. Scan at ingestion. Add a secret detection step between the connector and the chunker. The OWASP Secrets Management Cheat Sheet advises combining pattern rules with entropy checks so that human-chosen passwords are not missed, and using more than one detection tool. Quarantine any document with a finding instead of indexing it.
2. Scan the existing index. Run the same detectors over stored chunks, because the corpus was probably built before the scanner existed.
3. Fix at the source. A finding in the index means a live secret in the wiki or ticket system. Revoke it, move the credential to a secrets manager and replace the text with a reference to the vault path. See the Developer Secret Scanning Triage guide for triage rules.
4. Exclude high-risk spaces. Keep infrastructure runbooks, break-glass procedures and credential handover channels out of general assistant indexes unless they have been cleaned and are tightly permissioned.
5. Enforce permissions at query time. Retrieval must check the caller's rights on each chunk; see the Permission-Aware RAG Guide. A shared service identity that reads everything turns every user into a reader of every secret.
6. Filter outputs. ATLAS mitigation AML.M0033 Input and Output Validation for AI Agent Components includes checks for sensitive information leakage. Apply the same secret detectors to retrieval results and to the final response, and redact matches.
7. Block the exfiltration channel. In AML.CS0035 the key left inside a rendered link. Restrict link and image rendering to approved domains so that a retrieved secret cannot be encoded into an outbound URL.

Choosing the permission model

The two ATLAS mitigations mapped to AML.T0082 describe the main decision for anyone deploying an assistant over a shared corpus.

Small organisations: prefer assistants that use the signed-in user's own permissions and keep the indexed scope narrow. Large organisations: where a privileged indexer is unavoidable, add document-level access filters, separate indexes per sensitivity tier and scheduled re-scans. Either way, the identity the indexer uses is a non-human identity with broad read access: inventory it, scope it and rotate its credentials like any other service account.

Detection and measurement

Seed the corpus with canary credentials in plausible pages so that a harvest attempt trips an alert; the AI Agent Honeytokens and Canaries guide covers placement. D3FEND D3-FA File Analysis supports content scanning at ingestion, and D3-UBA User Behavior Analysis supports spotting unusual query patterns.

Metrics

• Index secret count: live secrets found in the RAG store at the latest scan (target zero).
• Ingestion coverage: share of connected sources whose content passes through secret detection before indexing.
• Time to revoke: median hours from a corpus finding to revocation of the credential.
• Output redactions: number of responses where a secret was redacted, trending down as sources are cleaned.
• Permission model: share of assistants that retrieve with user-scoped rather than shared service permissions.

Responding to a harvested credential

1. Confirm exposure. Find the prompt, the retrieved chunks and the response in the assistant logs. Record which credential was served, to which identity, and when.
2. Revoke and replace. Revoke the credential first, then issue a replacement through the secrets manager. Follow the Credential Rotation at Scale guide if many credentials appear in the same space.
3. Hunt for use. Search the target system's audit logs for use of the old credential from the time it was first indexed, not only from the time of the alert.
4. Clean the source and the index. Remove the secret from the wiki, ticket or chat, then confirm the chunk has been deleted or re-indexed. Check backups and caches of the vector store.
5. Check for injection. If the retrieval was triggered by planted content, find and remove it, and handle it under the Prompt Injection Incident Response Playbook.
6. Close the gap. Add the missed pattern to the ingestion scanner and re-scan the whole corpus.

Framework mapping

Common failure patterns

• Scanning code but not collaboration content: repositories are clean while the wiki that feeds the assistant holds the same keys in prose.
• Deleting the page but not rotating: the secret has already been indexed, cached and possibly served.
• One service identity for the whole index: permission filtering is assumed but never tested, so any user can retrieve any chunk.
• No prompt or retrieval logs: without them there is no way to tell whether a secret was ever served.
• Trusting the model to refuse: a system prompt that says "never reveal passwords" is not a control; injected instructions and paraphrased requests get around it.

Practitioner checklist

• List every source connected to each AI assistant and its RAG index.
• Add secret detection, with pattern and entropy rules, before chunking and indexing.
• Scan the existing index and revoke every live secret found.
• Replace secrets in wikis and tickets with references to a secrets manager.
• Retrieve with the caller's permissions, or test document-level filters if a privileged indexer is used.
• Run secret detectors on retrieval results and responses, and redact matches.
• Log prompts, retrieved chunk IDs and responses, and alert on credential-themed queries.
• Place canary credentials in the corpus.
• Treat any served secret as leaked: revoke, hunt, clean the source and the index.

Standards and references

• MITRE ATLAS: RAG Credential Harvesting
• MITRE ATLAS: Data Exfiltration from Slack AI via Indirect Prompt Injection
• MITRE ATLAS: Single-User AI Agent Permissions Configuration
• MITRE ATLAS: Privileged AI Agent Permissions Configuration
• OWASP: Top 10 for LLM Applications 2025
• OWASP: Secrets Management Cheat Sheet
• NIST: SP 800-53 Rev. 5
• MITRE D3FEND: File Analysis

Related NHI Mgmt Group resources: Threat Modelling RAG Systems · RAG Security Guide · Secret Sprawl Measurement Guide · MITRE ATLAS Guide