RAG Knowledge Base Poisoning Response Playbook

When a retrieval augmented generation (RAG) assistant starts giving answers that come from a planted document, deleting the file at its source rarely ends the incident, because copies survive as chunks, embeddings, cached answers and stale index entries. This template is an editable response playbook for a poisoned RAG knowledge base: how to confirm the poisoning, find every place the content now lives, purge it, re-index cleanly and decide who must be told. It covers both false or misleading content and documents carrying hidden instructions (indirect prompt injection). It is written for AI platform teams, security operations and incident managers who run production RAG systems. Preventive controls are in the AML.T0070 RAG Poisoning guide and the RAG Security Guide; this page is the procedure for when those controls have already been passed.

How to use this template

Replace text in square brackets, such as [Organisation], [AI Platform Lead], [vector store] and [4 hours], with your own terms. Bracketed timings are NHI Mgmt Group suggested values, not external requirements.
Run it under your main incident response plan. NIST SP 800-61 Rev. 3 (April 2025) frames incident response as a CSF 2.0 Community Profile, so map the phases below to your existing Respond and Recover activities rather than creating a parallel process.
If the poisoned content was written by an agent into its own long-term memory rather than ingested from a source, use the AI Agent Memory Poisoning Response Playbook instead. The Agent Memory Poisoning vs RAG Poisoning guide explains the difference.
If the poisoning reached training or fine-tuning data, also open the AI Model Poisoning Incident Playbook.
Complete the pipeline map in section 4 before an incident. Teams that discover during an incident that they do not know where their caches live lose the first day.

1. Purpose

This playbook sets out how [Organisation] detects, scopes, contains, purges and recovers from malicious or corrupted content in a RAG knowledge base, so that no poisoned chunk is served after containment, the root cause is closed, and affected users and decisions are identified.

2. Scope and triggers

In scope: every RAG knowledge base listed in the [AI system register], including its source connectors, ingestion pipeline, chunk store, embedding index or [vector store], semantic or answer caches, and any agent that uses retrieval results to call tools.
Out of scope: model weights and training data (see the model poisoning playbook) and agent-written memory (see the memory poisoning playbook), except where this incident spreads into them.

Open an incident under this playbook when any of the following occurs:

Trigger	Typical source	Initial severity
Answers cite a document that should not exist, or state false facts consistently for one query topic	User report, answer quality review	[Medium]
Retrieved text contains instructions aimed at the model, hidden text or a fake "document" embedded in another document	Retrieval log review, content scanning	[High]
An agent called a tool or sent data externally after retrieving a low-trust chunk	Agent tool-call logs, DLP	[Critical]
Unauthorised write to an indexed source (wiki, shared drive, ticketing, bucket) by an unknown or compromised identity	Source audit logs, identity alerts	[High]
Ingestion of a source outside the approved connector list	Pipeline change review	[Medium]

MITRE ATLAS describes the two behaviours this playbook responds to: AML.T0070 RAG Poisoning, where content placed in an indexed location contaminates later results and may be targeted to surface for a specific query, and AML.T0071 False RAG Entry Injection, where content inside a normal entry is crafted so the model treats part of it as a separate retrieved document. ATLAS notes that a false entry hidden inside a regular entry can bypass data monitoring and cannot be deleted directly, which is why section 6 purges by source record, not by visible title.

3. Roles and decision rights

Role	Responsibility	Decides
[Incident Manager]	Runs the incident, keeps the timeline, coordinates notification	Severity, when to close
[AI Platform Lead]	Owns the ingestion pipeline, index and caches; executes purge and re-index	Rebuild versus targeted purge
Knowledge base owner (business)	Confirms which content is genuine, approves restored content	Whether the assistant stays online in degraded mode
Security operations	Investigates the write path and any compromised identity; preserves evidence	Credential revocation
[Privacy or Legal Lead]	Assesses personal data exposure and regulatory or contractual notice	External notification
Downstream system owners	Check decisions, tickets or records the assistant influenced	Reversal of affected actions

4. Preparation: the pipeline map

For each knowledge base, record the following before an incident and review it at each pipeline change. Every row is a place poisoned content can persist.

Layer	What to record	Why it matters in a purge
Sources and connectors	Each source system, connector identity, who can write to it, sync schedule	The write path is the root cause; the schedule tells you how fast new poison arrives
Raw and parsed copies	Staging buckets, extracted text, OCR output	Hidden text often survives here after the original is fixed
Chunk store	Chunk IDs, source record ID, content hash, ingestion job ID	Lets you find every chunk from one source record
Embedding index	Index name, embedding model and version, key field, deletion method	Some indexers do not remove entries when the source is deleted
Caches	Semantic cache, answer cache, conversation history, summaries	Cached answers can keep serving poisoned text after the index is clean
Derived content	Generated summaries or documents written back to indexed sources	One poisoned answer can become a new corpus entry
Consumers	Assistants, agents and tools that query the index; their tool permissions	Defines who received poisoned answers and what they could do
Logs	Query, retrieval (chunk IDs returned), prompt and tool-call logs, retention	Scoping is impossible without retrieval logs

Also record how each platform handles deletion, because behaviour differs. Platforms are listed alphabetically; confirm current behaviour in each vendor's documentation.

Amazon Bedrock Knowledge Bases: the documentation describes sync as incremental, processing only documents added, modified or deleted since the last sync; a deleted document is removed from the vector store and a modified one is re-parsed, re-chunked, re-embedded and re-indexed. Sync runs through the StartIngestionJob API, and GetIngestionJob reports status and per-document statistics. AWS notes that with vector stores other than Amazon Aurora it can take a few minutes for newly synced data to be reflected. See the Amazon Bedrock Security Guide.
Azure AI Search: the documentation states that an indexer does not track object deletion in data sources and recommends a soft delete strategy, either native blob soft delete or a custom metadata flag set through a dataDeletionDetectionPolicy. Microsoft warns the policy must apply from the first indexer run: documents deleted before it was set remain in the index even after a reset, and the remedy is a new index with a new indexer. One-to-many indexing is outside both policies and needs the REST document delete operation.

5. Detection and triage

Within [1 hour] of the trigger, the [AI Platform Lead] and security operations answer these questions and record the answers in the incident ticket:

Is it poisoning or a quality fault? Pull the retrieval log for the reported answer and identify the chunk IDs returned. If the false content is in a retrieved chunk, treat it as poisoning until proved otherwise. If no retrieved chunk contains it, the model generated it and this playbook does not apply.
What is the source record? Map each chunk ID to its source system, record ID, author, last modified time and ingestion job.
Who wrote it, and how? Check the source system audit log for the writing identity. An unknown user, an external sharer, a compromised account or a service connector writing content it should only read all raise severity.
Does it carry instructions? Review the raw extracted text, not the rendered file. OWASP's LLM08 example describes a résumé with white-on-white text instructing the system to recommend the candidate; rendered views hide this.
Did an agent act on it? Search tool-call logs for actions taken in the same session after the chunk was retrieved. Any external send, write or privileged call makes the incident [Critical] and brings in the credential steps in section 6.

6. Containment, purge and re-index

6.1 Contain (target: [4 hours])

Stop new poison arriving: pause scheduled sync for the affected connector, or the whole knowledge base if the write path is unknown.
Stop serving it: apply a retrieval-time block on the identified chunk IDs and source record IDs, or exclude the source by metadata filter, so the assistant can stay online in degraded mode while the purge runs.
Flush caches: clear semantic and answer caches for the affected knowledge base. Partial cache invalidation by query is unreliable because poisoned text may have been cached under many phrasings.
Restrict agents: require human approval for tool calls from agents that use this knowledge base until the purge is verified. This is the intent of ATLAS mitigation AML.M0030 Restrict AI Agent Tool Invocation on Untrusted Data.
Handle identities: if a compromised account or connector credential wrote the content, revoke its sessions and rotate its credentials following the Leaked Credential Response Playbook.

6.2 Find every copy

Search the chunk store by source record ID, content hash and distinctive phrases from the poisoned text, across all knowledge bases that share the source.
Search the source systems for near copies: the same text pasted into other pages, attachments or tickets by the same identity in the same period.
Query the index with the trigger questions and their variants, and record every chunk returned that is not on the known-good list.
Check derived content: summaries, FAQs or reports generated by the assistant during the exposure window and written to indexed locations.

6.3 Purge

Preserve evidence first (section 8).
Remove or correct the content at its source. A purge of the index alone is undone at the next sync.
Delete the matching chunks and embeddings by key, using the deletion method recorded in the pipeline map. Where the platform relies on a soft delete flag, set it and confirm the indexer has processed it before physically deleting the source.
Delete raw and parsed copies in staging.
Delete or correct derived content found in 6.2.

6.4 Targeted purge or full rebuild

Condition	Choose
Few source records, all identified, platform deletion behaviour known and verified	Targeted purge and incremental re-index
Deletion detection was not in place from the first indexer run	Full rebuild into a new index
Write path unknown, or the poisoning window cannot be bounded	Full rebuild from sources verified against a known-good snapshot
False entries embedded inside legitimate documents (AML.T0071 pattern)	Correct the parent documents, then rebuild the affected collection
Small knowledge base that rebuilds in under [2 hours]	Full rebuild, because it is simpler to verify

For a rebuild, create the new index alongside the old one, ingest from verified sources, run the verification in section 7, then switch the assistant to the new index and keep the old one read-only as evidence for [30 days].

7. Recovery and verification

Re-run the trigger queries and a regression set of [50] representative questions; no poisoned chunk may appear in retrieval results.
Compare chunk counts and content hashes for the affected sources against the pre-incident snapshot.
Confirm the source write path is closed: permissions corrected, connector scoped to read only, compromised identities rotated.
Re-enable sync, then lift agent tool restrictions only after one full sync cycle shows no reappearance.
The knowledge base owner signs off restored content before the incident moves to monitoring for [14 days].

8. Evidence to preserve

The poisoned source file or record as stored, including version history and audit log entries for its creation and edits.
Raw extracted text and parsed output, which may show hidden content the rendered file does not.
Chunk records, embeddings and index metadata for affected entries, exported before deletion.
Query, retrieval and tool-call logs for the exposure window. OWASP's LLM08 mitigations call for detailed immutable logs of retrieval activity; if yours are mutable, copy them to protected storage at once.
Ingestion job IDs and their logs, and the cache contents if they can be exported.

9. Impact assessment and notification

Use retrieval logs to list every session, user and agent that received a poisoned chunk during the exposure window.
Ask downstream owners to review decisions, tickets, code or customer replies produced from those sessions and reverse any that relied on poisoned content.
If the poisoned content exposed or moved personal data, the [Privacy or Legal Lead] applies the organisation's personal data breach procedure and any applicable regulatory clock. See the AI Incident Reporting Clocks Map.
If customers saw false information that could affect them, agree a correction message with the business owner.

10. Post-incident review

Within [10 working days], hold a review covering how the content entered, why ingestion controls did not stop it, how long detection took, and which layers of the pipeline map were missing or wrong. Feed new cases into the RAG Security Test Plan Template.

Implementation guidance

Log chunk IDs, not just prompts: without the IDs of retrieved chunks per answer, sections 5 and 9 cannot be done. Make retrieval logging a launch requirement.
Carry the source record ID on every chunk: purge by source record, not by file name or title, so embedded false entries are found with their parent.
Set deletion detection on day one: where a platform needs a deletion policy, an index created without it may need a full rebuild to remove deleted content.
Treat connector identities as NHIs: read-only scopes, an owner and rotation. A connector that can write back to its source turns a poisoned answer into a poisoned corpus. See the Permission-Aware RAG Guide.
Exercise it: plant a benign marker document in a test knowledge base twice a year and time how long it takes to find, purge and verify every copy.

Metrics

Metric	Suggested target
Time from trigger to retrieval-time block	[under 4 hours]
Knowledge bases with a current pipeline map	[100%]
Answers with retrieved chunk IDs logged	[100%]
Poisoned chunks reappearing after purge	[0]
Exercise time to full purge and verification	[under 1 working day]

Framework mapping

Framework	Reference	Playbook sections
MITRE ATLAS	AML.T0070 RAG Poisoning; AML.T0071 False RAG Entry Injection; AML.M0030	2, 6
OWASP Top 10 for LLM Applications 2025	LLM08 Vector and Embedding Weaknesses; LLM04 Data and Model Poisoning; LLM01 Prompt Injection	2, 5, 8
NIST SP 800-53 Rev. 5	IR-4 Incident Handling; IR-5 Incident Monitoring; IR-8 Incident Response Plan; SI-7 Software, Firmware, and Information Integrity	3 to 10
NIST CSF 2.0	RS.MA-01 (plan executed once an incident is declared); RS.AN-03 (analysis establishes what happened and root cause)	5, 6, 10

RAG Knowledge Base Poisoning Response Playbook: Find, Purge and Re-Index