RAG Poisoning: Preserve Provenance Before Rebuilding the Index

Separate the document from the ingestion path

Record where the source came from, who could change it and which ingestion job processed it. Preserve identifiers and versions. An altered document, a permission error and an unexpected retrieval result are distinct possibilities.

Map the consumers

Identify the applications, users and workflows that could retrieve the affected material. Check caches, replicas and persistent memory where relevant. Do not infer every consumer received the content without supporting records.

Contain through authorised owners

Quarantine a source or suspend an ingestion route when appropriate, preserving evidence of the original state. Document the effect on legitimate retrieval and service continuity. Avoid destructive cleanup that removes the only available history.

Validate the restored source boundary

Rebuild from trusted sources when the agreed plan requires it. Verify provenance, permissions and representative retrieval behaviour. Record which stores were rebuilt and what remains uncertain.

Recovery is a provenance question

Before rebuilding, name the trusted source set and the owner who approves it. Identify ingestion jobs, caches, replicas and memory stores that may preserve the suspect content. An index rebuilt from the same untrusted material can recreate the problem.

Choose representative queries and access contexts for validation. Confirm that approved content is retrieved for authorised users and that the suspect material is no longer available through the affected path. Keep the validation tied to the actual implementation; a successful query in one session does not prove every replica or application is clean.

Use our RAG poisoning response to turn these questions into an agreed scope.

Prepare the next step

Explore AI incident response from Atlant Security, use the evidence checklist or prepare a non-sensitive incident brief for the team.