Passwords, API keys and tokens often sit in wikis, tickets and chat exports. If your RAG pipeline ingests those, the assistant can retrieve them for anyone who asks. Scan sources for secrets before ingestion, filter at retrieval, rotate anything found, and test by asking the assistant for credentials.
What ATLAS says
ATLAS describes RAG Credential Harvesting: an adversary with access to an LLM on the victim's system can try to collect credentials that were stored in internal documents and inadvertently ingested into a RAG database, where an AI agent can retrieve them. A related technique collects data from RAG databases by prompting the service to retrieve it, and ATLAS notes this can include the majority of an organisation's internal documents.
The attacker does not need to break into the vector database. They need to ask.
Where secrets hide
- Setup pages in internal wikis with example commands that include real tokens
- Support tickets where customers pasted config files
- Chat exports and meeting notes
- Code snippets in documentation
- Spreadsheets that list service accounts
- Old runbooks
Before ingestion
Scan sources. Run a secret scanner over the files and exports you plan to index. Use patterns for known key formats and entropy checks for random-looking strings. Neither is perfect, so combine them.
Exclude by source. Some sources are not worth indexing. A raw chat export is high risk and low value. Decide which sources are in scope, and write it down.
Redact, do not just flag. If a document is useful but holds a secret, replace the secret with a placeholder before chunking. Keeping the original in the index while flagging it still lets retrieval return it.
At retrieval and output
Filter outputs. Run a deterministic check on model output for known secret formats and block or mask matches. ATLAS suggests validation external to the agent, which fits here.
Respect permissions. If a secret must remain in a document that some users may read, retrieval should still enforce who is asking. See permission-aware retrieval.
When you find one
- Treat the secret as exposed. Rotate it. Removing it from the index does not make it safe again.
- Find the source document and fix it there, or the next re-index brings it back.
- Delete the chunks and vectors, and check backups and replicas.
- Check retrieval logs to see whether anyone could have pulled it. See what to log.
A simple test
Ask the assistant, as a normal user, for "the API key for" a few internal services, for a database password, and for "any tokens in the docs". Use a test account, and do not record real values. A refusal is not proof of safety, so also check the index directly with your scanner.
If you also want to look at the libraries your RAG application depends on, Safeguard's dependency scanning and the free scan at gold.safeguard.sh/scan can show known vulnerable packages in your SBOM.
Quick check
If I delete the secret from the index, is the problem solved?
No. Assume it was exposed, rotate it, and fix the source so it does not return on the next ingestion.
Is a system prompt rule enough to hide credentials?
No. OWASP notes that system prompt restrictions on data types are not reliable, since injection or other methods can bypass them.
Sources
- MITRE ATLAS data repository (mitre-atlas/atlas-data), techniques AML.T0082 and AML.T0085.000, 2026.09 release.
- OWASP LLM02:2025 Sensitive Information Disclosure
Last reviewed: 19 October 2026.
