When a vector database behind a retrieval augmented generation (RAG) system is compromised, the attacker can read the knowledge your AI applications draw on, plant content that changes what they say and do, and use the credentials that ingestion pipelines and agents use to reach it. Two threats matter at once: confidentiality, because embeddings and the text stored beside them can reveal the source documents, and integrity, because a handful of planted entries can steer answers or carry prompt injection into agents. The incident can start with a leaked API key, an exposed admin endpoint, a compromised ingestion pipeline or a hosted provider breach. This playbook is for AI platform, data and incident response teams. It is vendor-neutral and covers managed and self-hosted deployments; confirm exact feature names in your own product's documentation. Hardening is covered in Securing the vector database itself and the Vector Database Security Guide.
Key takeaways
- Treat embeddings as the data. Published research recovered 92% of 32-token inputs exactly from their embeddings, so stolen vectors count as stolen text for scoping and notification.
- Stop retrieval before you investigate writes. If the store may be poisoned, AI applications and agents reading from it must stop trusting it now, or they keep acting on planted content.
- Every client credential is in scope. Ingestion jobs, application back ends, agents and notebooks all hold keys to the store; rotate all of them, not just the one you think leaked.
- Rebuild from source, not from the store. A clean re-ingest from authoritative documents is the reliable way to remove poisoning; snapshots taken after the intrusion are not a clean baseline.
- Check what flowed downstream. Answers, tickets, emails and agent actions produced while the store was tainted may need review or correction.
What the vector database holds
This table is NHI Mgmt Group analysis: our view of the common components and what each gives an attacker.
| Component | What an attacker gains | First containment action |
|---|---|---|
| Collections or indexes of embeddings | A representation that can be inverted towards source text | Block reads from unknown clients; snapshot for evidence |
| Stored text chunks and metadata (payload) | The source text directly, plus file paths, owners and access labels | Same as above; identify which collections hold sensitive data |
| Write and upsert access | Ability to insert or alter entries the model will retrieve (ATLAS AML.T0070 RAG Poisoning, AML.T0071 False RAG Entry Injection) | Revoke write keys; freeze ingestion |
| Admin access (create or delete collections, users, keys, backups) | Persistence, deletion (ATT&CK T1485 Data Destruction) and backup tampering | Rotate admin credentials; lock key management |
| Ingestion pipelines and connectors | Credentials to source systems (file shares, wikis, ticketing, code) | Pause pipelines; rotate their source credentials |
| Embedding model API keys stored with the store or pipeline | Paid model access and a way to generate convincing poison | Rotate keys at the model provider |
| Backups and snapshots | A full offline copy of every collection | Check backup access logs and storage permissions |
How the compromise shows up
| Signal | Where you see it | What it can mean |
|---|---|---|
| Query or scroll volume far above baseline, or full collection exports | Database API and access logs, network egress | Bulk theft of vectors and payloads (ATT&CK T1530 Data from Cloud Storage) |
| Upserts or deletes from a client that normally only reads, or outside ingestion windows | Write logs, collection point counts over time | Poisoning or tampering (ATT&CK T1565.001 Stored Data Manipulation) |
| New API keys, users, roles or network rules | Admin audit log, cloud control plane logs | Persistence |
| AI answers citing unfamiliar sources, odd instructions in retrieved chunks, agents taking unexpected tool actions | Application traces, retrieval logs, user reports | Planted content reaching the model, including indirect prompt injection |
| Admin or API port reachable from the internet with no authentication | External attack surface scans, cloud security posture findings | Exposure that may already have been used |
| Provider security notice | Status page, trust centre | Possible exposure of your keys or data at the provider |
OWASP's LLM08:2025 Vector and Embedding Weaknesses recommends immutable logs of retrieval activity for exactly this reason: without them you cannot say what was read or changed. If retrieval logging was off, say so early, because it changes the scoping assumption to "everything".
Triage: the first hour
- Read, write or both? Decide whether the evidence points to theft, tampering or both; plan for both until disproven.
- Which collections? List each collection with its data source, sensitivity, tenants or user groups and the applications that read it.
- Which clients? List every key or identity with access: ingestion jobs, application back ends, agents, notebooks, admin tools.
- Which consumers act on retrieval? Agents that call tools, send messages or change records are the highest priority to pause.
- Is there a clean source? Confirm the authoritative documents still exist and were not altered, so a rebuild is possible.
- Is it ongoing? Recent activity from unknown clients means containment starts now.
Containment by priority
- Pause high-impact consumers. Switch agents that act on retrieval to read only or manual approval, or route RAG applications to a fallback that does not use the affected collections.
- Close exposure. Remove public network access, restrict to private endpoints or allow lists, and enforce authentication on every endpoint.
- Revoke write access. Rotate or delete write and admin keys; stop ingestion pipelines so nothing new lands while you investigate.
- Rotate read keys. Issue new keys per client, scoped to the collections each needs, and deploy them through your secrets manager.
- Freeze evidence. Take a snapshot of affected collections and export logs before any clean-up; store them with restricted access, because they contain the same sensitive data.
- Contain upstream. If an ingestion pipeline was the entry point, rotate its credentials to source systems and treat those systems as possibly accessed.
Rollback: keep a record of every key, rule and consumer change. Consumers return to the store only after the rebuild is verified, so a premature rollback cannot restore poisoned answers.
Credential rotation
| Credential | Action | Check afterwards |
|---|---|---|
| Database admin keys and root accounts | Rotate, then remove any keys not in your inventory | Only listed keys authenticate |
| Application and agent read keys | One key per client, scoped to named collections, read only | No shared keys across applications |
| Ingestion write keys | New key per pipeline, write only to its own collections | Writes come only from known pipelines |
| Source system credentials used by ingestion | Rotate at each source; reduce to read only | No access with old credentials |
| Embedding and LLM provider API keys | Rotate at the provider; check usage for spikes | Usage returns to baseline |
| Cloud identities for managed or self-hosted deployments | Rotate roles, service account keys and storage access for backups | Backup storage access only from the backup service |
Stolen model keys are often resold or used for free inference; the LLMjacking breach page shows how quickly that happens once keys leak. For key clean-up across systems, see the Secrets Manager Compromise Playbook.
Eradication and rebuild
Finding every poisoned entry by inspection is unreliable: the PoisonedRAG study reported about a 90% attack success rate from adding five malicious texts per target question to a knowledge base of millions. Small, targeted changes are hard to spot, so rebuild rather than clean.
- Verify sources: confirm the authoritative documents and their versions; check source systems for changes made in the window.
- Re-ingest into new collections: rebuild from verified sources with fresh credentials, recording a content hash and source reference for each chunk.
- Compare old and new: diff point counts, IDs and payloads between the compromised and rebuilt collections; entries with no source match are your poisoning evidence.
- Check hidden content: OWASP recommends extraction that detects hidden text before documents enter the knowledge base; apply it to the rebuild.
- Rebuild hosts: for self-hosted deployments, redeploy from clean images rather than cleaning in place.
- Delete or quarantine: retire the compromised collections once evidence is preserved.
Recovery and downstream review
- Cut over one application to the rebuilt collections and test retrieval with known questions, including ones aimed at the suspected poison.
- Enforce permission-aware retrieval so each user and tenant sees only what they are entitled to, as OWASP LLM08 recommends.
- Restore agents last, with tool approvals for sensitive actions until monitoring is proven.
- Review outputs from the window: answers, generated documents and agent actions that used affected collections, starting with external communications and changes to records.
- Restart ingestion with validation, provenance checks and alerts on unexpected writes.
Where identity fits
Most vector database incidents begin with a non-human identity: an API key in an application's configuration, a pipeline credential, an agent's token or a notebook with an admin key. ATLAS lists RAG Credential Harvesting (AML.T0082) separately because credentials that end up inside indexed documents can be retrieved through the model itself, so the knowledge base can leak keys as well as hold them.
- One identity per client: give each application, pipeline and agent its own key or workload identity, so containment can cut one without breaking all.
- Scan before you index: run secret detection on documents during ingestion, and treat any credential found in a compromised collection as exposed.
- Agents inherit the user's limits: retrieval for an agent should be filtered by the entitlements of the person it acts for, not by a broad service key. See the Permission-Aware RAG Guide.
Scoping cross-tenant and cross-group exposure
OWASP LLM08 describes context leakage where several user groups or applications share one vector database. During an incident, the same weakness widens the scope. The table below is NHI Mgmt Group analysis.
| Design | Scoping consequence | Rebuild choice |
|---|---|---|
| Separate database or project per tenant | Scope limited to the tenants whose keys or hosts were reached | Rebuild only affected tenants |
| Separate collection per tenant or group, shared keys | Any leaked key reaches every collection it can list | Rebuild all collections the key could reach; split keys |
| Shared collection filtered by metadata | One leaked key or a filter bypass exposes every tenant's chunks | Treat all tenants as affected; consider separate collections |
Evidence to preserve and notification
- Collection snapshots: the compromised state, kept separately with restricted access.
- Logs: query, write and admin logs; network and cloud control plane logs.
- Application traces: prompts, retrieved chunks and outputs for the window, where retained.
- Pipeline records: ingestion runs, sources and versions.
Because embeddings can be inverted, assess personal data in stolen collections as if the text was taken. Under GDPR Article 33 a controller notifies the supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware. See the Cyber Incident Reporting Requirements Map for other regimes. For scoping help, use the Data Security Incident Scoping Playbook.
Decision guidance
| Situation | Choose | Trade-off |
|---|---|---|
| Read-only exposure, writes ruled out by logs | Rotate keys, close exposure, keep serving | Fast, but depends on trustworthy write logs |
| Writes possible or logs missing | Pause consumers, rebuild from source | Downtime for AI features; the only reliable integrity fix |
| Agents with tool access read the store | Pause or require approval for every action | Workflow disruption versus actions taken on planted instructions |
| Small deployment, a few collections | Full rebuild of everything | Simple and cheap; re-embedding cost is low |
| Large deployment, very large collections | Rebuild sensitive and agent-facing collections first, others in stages | Embedding cost and time; residual risk in later stages |
Detection and measurement
- Time to pause consumers: from declaration to agents and RAG applications off affected collections.
- Rebuild coverage: share of affected collections rebuilt from verified sources.
- Provenance coverage: chunks with a source reference and content hash, target 100% for agent-facing collections.
- Key hygiene: clients with their own scoped key versus shared keys, target no shared keys.
- Write anomaly alerting: alerts on writes outside known pipelines, tested by injection drills.
Framework mapping
| Framework | Reference | Where it applies |
|---|---|---|
| OWASP Top 10 for LLM Applications 2025 | LLM08 Vector and Embedding Weaknesses; LLM04 Data and Model Poisoning | Inversion, leakage and poisoning risks and mitigations |
| MITRE ATLAS | AML.T0070, AML.T0071, AML.T0082, AML.T0025 | RAG poisoning, false entry injection, RAG credential harvesting, exfiltration |
| MITRE ATT&CK | T1530, T1565.001, T1485, T1552.001 | Collection, data manipulation, destruction, credentials in files |
| NIST CSF 2.0 | RS.MI-01, RS.MI-02, RS.AN-03, RC.RP-03, RC.RP-05 | Containment, eradication, root cause, verified restoration |
| NIST SP 800-53 Rev. 5 | IR-4, AC-3, AC-6, IA-5, SI-7, CP-9 | Incident handling, access enforcement, least privilege, authenticators, integrity, backup |
| ISO/IEC 27001:2022 Annex A | 5.24 to 5.28, 8.13 | Incident management and evidence, information backup |
Common failure patterns
- Restoring from a recent snapshot. Snapshots taken after the intrusion carry the poison; only verified source documents are clean.
- Treating embeddings as anonymous. Inversion research shows they leak text, so scoping that excludes them under-reports exposure.
- One shared key for every client. Rotation then breaks everything at once and logs cannot say which client did what.
- Leaving agents running. An agent that keeps retrieving planted instructions continues the incident.
- Forgetting the ingestion credentials. Pipelines hold access to the source systems, which is often the larger exposure.
Practitioner checklist
- Keep an inventory of collections, sources, sensitivity and consumers.
- Pause agents and RAG applications that use affected collections.
- Close public exposure and enforce authentication on every endpoint.
- Revoke write and admin keys, then reissue scoped read keys per client.
- Snapshot and export logs before clean-up.
- Rotate ingestion, source system and model provider credentials.
- Rebuild from verified sources into new collections with provenance.
- Review outputs and agent actions from the window.
- Assess personal data as if the text was stolen.
Standards and references
- OWASP: Top 10 for LLM Applications 2025 (LLM08 Vector and Embedding Weaknesses)
- MITRE ATLAS: RAG Poisoning
- MITRE ATLAS: False RAG Entry Injection
- MITRE ATLAS: RAG Credential Harvesting
- NIST: SP 800-61 Rev. 3, Incident Response Recommendations and Considerations for Cybersecurity Risk Management
- Morris et al.: Text Embeddings Reveal (Almost) As Much As Text
- Zou et al.: PoisonedRAG, Knowledge Corruption Attacks to Retrieval-Augmented Generation of Large Language Models
Related NHI Mgmt Group resources: RAG Security Guide · Permission-Aware RAG Guide · Vector database integration security guide · AI Agent Memory Poisoning Response Playbook