When retrieval becomes the attack path

Incident response for poisoned RAG pipelines

A poisoned RAG system can produce fluent, well-cited, and operationally dangerous answers without compromising the underlying model.

The attacker may alter an internal wiki, upload a document containing hidden instructions, manipulate ranking metadata, write directly to a vector collection, or contaminate an agent’s persistent memory. Once indexed, that content can influence every user and agent that retrieves it.

The incident is not confined to the original document. Responders must trace every derivative: extracted text, chunks, embeddings, vector records, caches, prompts, model responses, memory writes, and downstream actions.

Operating principle: Do not treat a poisoned document as a single bad file. Treat it as a data-integrity incident affecting every system that transformed, retrieved, trusted, or acted upon that file.

When suspicious retrieval becomes an incident

A poor answer is not automatically a security incident. Escalate when there is evidence that retrieval integrity, authorization, or system behavior may have been deliberately or materially altered.

Signals include:

• A recently ingested document unexpectedly dominates top-K results.
• Retrieved content contains instructions directed at the model or agent.
• Hidden text, unusual Unicode, encoded content, or invisible markup survives extraction.
• A document’s retrieved text differs from its visible source.
• Sources outside the approved repository appear in production results.
• Embeddings or index records are written by an unexpected identity.
• Similar queries begin returning materially different sources without an approved change.
• Ranking metadata, trust scores, or source labels change unexpectedly.
• A document from one tenant or security boundary appears in another.
• An agent changes behavior after retrieving a particular source.
• Poisoned content is copied into conversation summaries or long-term memory.
• Model responses influence tool calls, code changes, messages, approvals, or business decisions.

Microsoft describes grounding compromise as especially persistent because it attacks trusted supporting systems rather than the foundation model. Poisoned documents, embeddings, indexes, and ranking metadata can repeatedly influence downstream behavior. Microsoft: Grounding Data Compromise

OWASP similarly identifies poisoned embeddings and vector stores as integrity risks capable of manipulating outputs and exposing information. OWASP LLM08: Vector and Embedding Weaknesses

Understand the two pipelines

A useful investigation separates RAG into two connected paths.

The indexing path:

1. Acquires a source document or record.
2. Parses and normalizes it.
3. Splits it into chunks.
4. Generates embeddings.
5. Writes vectors, text, and metadata to an index.

The query path:

1. Authenticates the requesting identity.
2. Embeds or interprets the query.
3. Searches the index.
4. Applies metadata and authorization filters.
5. Selects top-K chunks.
6. Assembles the prompt.
7. Invokes the model or agent.
8. Produces output, tool actions, or memory.

Microsoft’s current RAG architecture guidance describes the same indexing and querying split: source documents are parsed, chunked, embedded, and stored; user questions later retrieve selected chunks that are passed to the model. Microsoft: Retrieval-Augmented Generation architecture

The investigative question is therefore not only, “Who changed the source?”

It is:

Which source version entered which ingestion job, produced which chunks and embeddings, appeared in which retrievals, influenced which prompts, and caused which decisions or actions?

RAG integrity and containment architecture

S1 --> G1
S2 --> G1
S3 --> G1
G1 --> I1 --> I2 --> I3 --> I4
I4 --> G2 --> R1 --> R2 --> R3
R3 --> R4
R3 --> R5
R5 -. future context .-> R2
S1 -.-> E1
S2 -.-> E1
S3 -.-> E1
I1 -.-> E2
I2 -.-> E2
I3 -.-> E2
I4 -.-> E3
R1 -.-> E4
R2 -.-> E5
R3 -.-> E5
R4 -.-> E5
R5 -.-> E5
C1 -. control .-> G1
C2 -. control .-> I4
C3 -. control .-> G2
C4 -. control .-> R3
C4 -. control .-> R5
C5 -. recovery .-> I1

The two gates are the primary security boundaries.

The ingestion gate determines whether content is eligible to influence the system.

The retrieval gate determines whether a specific identity may receive and use specific chunks at query time.

Neither decision should be delegated to the model.

The first 30 minutes

0–10 minutes: stop additional contamination

Start by controlling writes.

• Pause automated ingestion jobs.
• Disable event-driven indexing triggers.
• Remove or suspend unexpected ingestion identities.
• Block user uploads if they share the affected path.
• Disable direct vector-store writes outside the approved pipeline.
• Preserve dead-letter queues and failed ingestion records.
• Prevent new memory writes.
• Hold index rebuilds, compaction, and cleanup jobs.
• Freeze changes to parsers, chunking configuration, embedding models, retrieval policies, and ranking logic.

Do not immediately delete the suspicious source or vector records. Deletion can remove the identifiers required to determine where the content propagated.

If agents can perform consequential actions based on retrieval, suspend those actions or move them behind human approval while the scope is unknown.

10–20 minutes: isolate retrieval

Containment can happen at several layers:

• Remove the affected collection or namespace from the production retrieval route.
• Add a deny rule for known document, chunk, or source identifiers.
• Restrict retrieval to a known-good snapshot.
• Disable semantic retrieval while retaining keyword search against trusted content.
• Reduce agents to response-only mode.
• Block high-risk tools at the tool gateway.
• Disable shared memory reads.
• Invalidate affected retrieval and prompt caches.
• Route a small trusted user group to a clean canary index.

The safest action depends on scope. If one document is affected and its lineage is reliable, record-level denial may be sufficient. If provenance is incomplete, the affected collection—or the entire retrieval path—may need to be removed from service.

20–30 minutes: preserve volatile state

Collect before it expires:

• Active ingestion jobs and queues
• Current parser and chunking configuration
• Embedding deployment and model version
• Vector collection configuration
• Recent upserts, updates, and deletions
• Query and retrieval traces
• Top-K chunk identifiers and similarity scores
• Metadata filters and authorization decisions
• Prompt-assembly records
• Model and agent traces
• Tool calls and target-system results
• Cache entries
• Memory reads and writes
• Responder actions

NIST SP 800-61 Rev. 3 places incident response within broader cybersecurity risk management and emphasizes coordinated detection, response, recovery, and improvement. NIST SP 800-61 Rev. 3

Build the affected window from data lineage

The affected window is not simply the time between document upload and discovery.

Use at least four timestamps:

• Source exposure time: when the source first became malicious or untrustworthy.
• Ingestion time: when the pipeline read that source version.
• Index availability time: when poisoned records became retrievable.
• Last influence time: the final retrieval, cache hit, memory read, or downstream action tied to the affected material.

The start of the incident may predate the vector-store write. A compromised source can sit unchanged until the next scheduled ingestion.

The end may extend beyond removal from the index. Poisoned content can survive in:

• Retrieval caches
• Prompt caches
• Conversation summaries
• Agent scratchpads
• Long-term memory
• Evaluation datasets
• Generated documents
• Tickets and knowledge articles
• User decisions
• Tool-generated changes
• Downstream indexes

Microsoft recommends treating indexes, embeddings, vector stores, caches, summaries, scratchpads, and memory as sensitive supply-chain components with provenance, versioning, integrity checks, rollback, and monitoring. Microsoft: Input, Context, and Retrieval Hygiene

Minimum viable lineage record

Every indexed chunk should be traceable without searching raw production logs manually.

{
  "tenant_id": "tenant-blue",
  "source_id": "sharepoint:item:8f27",
  "source_version": "2026-10-07T18:42:11Z",
  "source_digest": "sha256:...",
  "owner": "security-architecture",
  "ingestion_job_id": "ing-20261007-1845-91",
  "parser_version": "parser-4.8.2",
  "chunk_id": "8f27:v19:c0042",
  "chunk_digest": "sha256:...",
  "embedding_model": "embedding-deployment-a",
  "embedding_version": "2026-09-30",
  "collection": "prod-knowledge-blue",
  "vector_record_id": "vec-01J...",
  "indexed_at": "2026-10-07T18:46:03Z",
  "policy_version": "rag-ingest-2026.10",
  "trust_status": "approved"
}

At query time, record:

trace_id
requesting human and workload identity
tenant and purpose
query digest or controlled forensic copy
collection and index version
metadata filters
retrieved chunk IDs
similarity or ranking scores
source trust and freshness
authorization result
prompt-template version
prompt digest
model and agent version
response and citation IDs
tool calls
memory reads and writes

Avoid copying sensitive source passages into broadly accessible telemetry. Use identifiers, hashes, structured decisions, and access-controlled forensic capture.

Determine how the poison entered

Do not assume the vector database was compromised directly.

Common entry paths include:

Compromised authoritative source

An attacker modifies a wiki, repository, file share, ticket, mailbox, database, or content-management system already trusted by the pipeline.

Investigate:

• Source-system audit history
• Actor and workload identity
• Previous and current object versions
• Sharing and ownership changes
• API and application activity
• Automation credentials
• Webhooks and synchronization jobs

Abused ingestion feature

A legitimate upload, email, web-crawl, support, or collaboration feature accepts attacker-controlled content that is automatically indexed.

Investigate:

• Who was allowed to submit content
• Whether review was required
• Whether source trust was inherited incorrectly
• File conversion and extraction behavior
• Hidden markup and attachment handling
• Cross-tenant and anonymous submission paths

Ingestion pipeline compromise

The parser, chunker, embedding service, orchestration framework, or indexing job is changed or executed by an unauthorized identity.

Investigate:

• Deployment history
• Package and image provenance
• CI/CD runs
• Runtime identity
• Environment and configuration changes
• Secrets and managed identities
• Unexpected network destinations

Vector-store manipulation

An attacker writes, updates, deletes, or changes metadata directly.

Investigate:

• Administrative and data-plane access
• Collection and namespace creation
• Bulk upserts
• Metadata-only changes
• Ranking and trust-score changes
• Backup restoration
• Index aliases
• Write activity outside normal ingestion windows

Memory promotion

A model response, tool result, or user conversation is summarized and written into persistent memory or a shared knowledge store.

Investigate:

• Memory-write policy
• Writer identity
• Source references
• Review and approval path
• Schema validation
• Cross-agent synchronization
• Retention and version history

Detection opportunities

A poisoning detection program needs retrieval-specific telemetry. Conventional endpoint and network alerts may never see the harmful behavior.

Ingestion detections

Alert on:

• Writes from a new identity, region, workload, or API route
• Indexing outside approved schedules
• Large changes in source count or chunk count
• A document producing an unusual number of chunks
• New external domains entering approved sources
• Hidden markup, encoded instructions, or Unicode control characters
• Imperative language or model-directed text in data fields
• Missing owner, source version, ACL, tenant, or digest
• Parser output that differs substantially from visible content
• Sudden embedding-distribution or cluster changes
• Changes to embedding models or chunking configuration

Retrieval detections

Alert on:

• A newly indexed source dominating common queries
• One document appearing across unrelated queries
• Abrupt top-K source-distribution changes
• Large ranking increases without content approval
• Retrievals from low-trust or expired sources
• Missing or bypassed metadata filters
• Cross-tenant result attempts
• Repeated retrieval of a suspicious chunk across users
• Retrieval results containing instruction-like language
• Citation and retrieved-source mismatches

Runtime detections

Alert on:

• Tool proposals shortly after a suspicious retrieval
• Memory writes derived from low-trust content
• New workflows, recipients, destinations, or cloud resources
• Model refusals or policy-engine denials clustered around one source
• Agent behavior changes tied to a document or index version
• Retrieval followed by credential, IAM, code, payment, or messaging activity

OWASP recommends authenticated sources, fine-grained vector-store access, logical separation, data validation, and immutable retrieval logs. OWASP LLM08

Quarantine without destroying evidence

Quarantine should sever influence while retaining the material needed to reconstruct the incident.

For the source:

• Restrict normal-user access.
• Preserve the original malicious version.
• Export source-system history and audit records.
• Record owner, ACL, timestamps, and digest.
• Create a sanitized working copy only after preservation.

For the index:

• Snapshot the collection and its configuration.
• Export affected vector IDs and metadata.
• Record aliases, namespaces, shards, and replicas.
• Deny retrieval of affected records.
• Stop writes before bulk remediation.
• Preserve query and mutation logs.

For runtime state:

• Isolate affected caches.
• Disable memory reads and writes.
• Preserve prompt and agent traces.
• Block high-impact tools.
• Identify outputs already delivered to users or systems.

A backup of the poisoned index is evidence—not a recovery source.

Removing poisoned derivatives

Deleting the original document is insufficient.

Track and invalidate:

1. Parsed text and OCR output
2. Extracted tables and metadata
3. Chunks
4. Embeddings
5. Vector and keyword index records
6. Retrieval caches
7. Prompt and response caches
8. Generated summaries
9. Conversation and agent memory
10. Evaluation and fine-tuning datasets
11. Generated documents or tickets
12. Secondary indexes
13. Downstream actions

Each derivative should be linked to its source through stable identifiers and version metadata.

If the system cannot answer, “Which derived objects came from this source version?”, responders cannot prove that eradication is complete.

Hunt downstream from the retrieved chunk

Start with retrieval traces, not the conversation transcript.

For each suspicious chunk:

1. Find every retrieval event containing its chunk or vector ID.
2. Identify the requesting user, workload, agent, and tenant.
3. Reconstruct the assembled prompt.
4. Identify the model response and citations.
5. Find memory writes derived from the interaction.
6. Enumerate proposed and executed tool calls.
7. Validate each action in its authoritative target system.
8. Identify generated artifacts subsequently ingested elsewhere.
9. Extend the hunt through asynchronous jobs and agent handoffs.

Classify outcomes as:

• Retrieved but not used
• Used in a response
• Presented to a human
• Written to memory
• Used in a decision
• Used to propose an action
• Used in a successful action
• Propagated into another system
• Unknown

Do not treat a model’s explanation of its behavior as authoritative evidence.

Rebuild from trusted state

For narrow, well-instrumented incidents, responders may safely remove known records and re-embed affected sources.

For broad or uncertain incidents, build a new index rather than cleaning the active one in place.

A defensible rebuild should:

• Begin from approved source versions.
• Revalidate ownership, tenant, classification, ACL, and AI-use approval.
• Verify source and content digests.
• Use pinned parser, chunking, and embedding configurations.
• Generate new chunk and vector identifiers.
• Write to a new collection or index version.
• Prevent unreviewed sources from entering during the rebuild.
• Produce a signed or otherwise protected manifest.
• Run retrieval tests before changing the production alias.
• Retain a rollback path.

NIST’s Generative AI Profile emphasizes lifecycle risk management and provenance as mechanisms for tracing origins, transformations, and downstream effects. NIST AI 600-1

Recovery validation

Do not restore retrieval because the index build succeeded.

Integrity tests

• Known documents produce expected digests and chunk counts.
• Every record maps to an approved source version.
• No quarantined source or chunk exists in the new index.
• Index configuration matches the approved build manifest.
• Embedding and parser versions are correct.

Authorization tests

• Cross-tenant queries return no unauthorized results.
• Removed users and groups cannot retrieve prior content.
• Missing security metadata fails closed.
• Alternate APIs enforce the same filters.
• Cache keys preserve tenant and authorization scope.

Retrieval tests

• Golden queries return expected trusted sources.
• Adversarial queries do not surface quarantined content.
• Newly added content does not dominate unrelated queries.
• Citations resolve to the retrieved source version.
• Similarity and ranking distributions remain within reviewed tolerances.

Runtime tests

• Retrieved text cannot alter system instructions.
• Tool calls still require independent authorization.
• Memory writes are policy checked and traceable.
• Poisoned historical memory is absent.
• High-impact actions require the intended approval.
• Complete retrieval and action telemetry reaches the monitoring platform.

Operational recovery

Use staged release:

1. Offline: Build and validate without production traffic.
2. Canary: Use synthetic and trusted responder queries.
3. Limited: Release to a small internal population without high-risk tools.
4. Controlled production: Restore read scenarios with enhanced monitoring.
5. Full service: Restore agent actions only after retrieval and authorization controls are proven.

Rollback should change an index alias, collection reference, or configuration version—not require emergency deletion under pressure.

Engineering controls after the incident

The durable fixes should address the control failure that allowed poisoned content to become trusted context.

• Separate public, external, internal, and privileged sources.
• Require source registration and accountable ownership.
• Treat ingestion as a privileged production deployment.
• Use dedicated least-privilege identities for each pipeline stage.
• Restrict vector-store writes to the approved ingestion service.
• Preserve source and transformation provenance at chunk level.
• Version parsers, chunking logic, embedding deployments, and indexes.
• Scan visible and extracted content before embedding.
• Remove hidden markup and normalize Unicode.
• Keep retrieved data separate from system instructions.
• Enforce authorization on every retrieval.
• Require schema-bound memory writes.
• Make caches and memory expirable and recoverable.
• Monitor upserts, deletions, source distribution, and top-K drift.
• Maintain a known-good index and tested alias rollback.
• Test poisoned-document scenarios in CI/CD and exercises.
• Require independent policy enforcement before agent tool execution.

Microsoft’s retrieval-hygiene guidance recommends treating every prompt, document, retrieved chunk, tool result, and memory write as untrusted input. It also recommends typed, policy-checked memory interfaces and recoverable, versioned memory. Microsoft: Input, Context, and Retrieval Hygiene

Responder checklist

• Pause new ingestion and persistent memory writes.
• Restrict agent tools while retrieval integrity is uncertain.
• Preserve the suspicious source and its version history.
• Snapshot the affected index and configuration.
• Record source, chunk, embedding, vector, query, prompt, and action identifiers.
• Establish source-exposure, ingestion, index-availability, and last-influence times.
• Determine whether the source, pipeline, index, or memory was compromised.
• Quarantine affected records without destroying evidence.
• Invalidate derived chunks, vectors, caches, summaries, and memory.
• Hunt downstream from every affected retrieval.
• Validate actions in authoritative target systems.
• Rebuild from approved source versions when scope is uncertain.
• Test integrity, authorization, retrieval, memory, and tool controls.
• Restore through canary and limited stages.
• Preserve a rollback path and enhanced monitoring.

Closing position

A poisoned RAG incident is not fundamentally a model incident.

It is a compromise of the data supply chain that the model was permitted to trust.

The effective blast radius includes every retrieval, user, agent, memory entry, and downstream action influenced by the contaminated material. Recovery requires more than deleting the source. Responders must remove its derivatives, reconstruct its influence, rebuild trusted retrieval state, and prove that the same content cannot quietly return through a cache, backup, shared memory, or secondary index.

The discipline: Control what enters the index, preserve how it was transformed, record what was retrieved, and keep enough separation between data and authority that one poisoned document cannot become an operational command.