A RAG security audit is an evidence-based review of how a retrieval-augmented generation system ingests, transforms, authorizes, retrieves, presents, logs, and deletes information. It must follow data from the source repository through chunks, embeddings, indexes, prompts, model output, caches, telemetry, and backups. Auditing only the vector database leaves major attack and leakage paths untested.
The core questions are whether the right content enters the system, whether each user retrieves only authorized evidence, whether untrusted documents can manipulate the model, and whether outputs, logs, and derived copies follow the same data rules as their sources. The audit should produce test results and owners, not a list of unchecked security features.
Map the Complete RAG Trust Boundary

Draw every component and identity in the request and ingestion paths: source repositories, connectors, parsers, chunking, embedding services, queues, object storage, vector and metadata stores, retrievers, rerankers, prompt templates, model endpoints, tools, gateways, caches, logs, and backup systems. Mark which inputs are trusted, user-controlled, externally sourced, or provider-administered.
For each connection, record protocol, authentication, authorization, encryption, data type, destination, and owner. A private AI infrastructure boundary can keep compute and data under dedicated control, but the audit must still identify SaaS connectors, remote model APIs, telemetry exports, and support paths that cross it.
Audit Ingestion and Source Provenance
Verify who can add, modify, approve, and remove sources. Connectors should ingest only approved repositories and retain source identifiers, versions, timestamps, owners, and access labels. Test malformed files, unsupported content, duplicate documents, hidden text, oversized inputs, and documents containing instructions aimed at the model.
Data and retrieval poisoning can introduce misleading or malicious content that ranks highly for targeted queries. Use integrity checks, approval workflows for sensitive corpora, anomaly detection, source allowlists where appropriate, and periodic sampling of recently changed material. No single filter is foolproof, so pair prevention with monitoring and response.
Prove Authorization Survives Chunking and Indexing
Source permissions can be lost when a document becomes chunks and embeddings. Define how document, folder, tenant, group, user, purpose, and expiry attributes are carried into the index and enforced at query time. Do not rely on the model to ignore unauthorized text after retrieval; authorization must prevent that text from entering the model context.
| Authorization test | Expected result | Evidence |
| User removed from a source group | New queries cannot retrieve restricted chunks within the stated propagation time | Identity change, index update, query trace, and denial |
| Two tenants use similar terms | Each tenant receives only its own documents | Filtered candidate set and cross-tenant negative test |
| Document access expires | Chunks and caches become unavailable on schedule | Expiry event and retrieval test |
| Privileged support account is used | Access is approved, attributable, limited, and logged | Session record and reviewed audit event |
Test Retrieval Manipulation and Indirect Prompt Injection
Retrieved content is untrusted input, even when it comes from an approved repository. A compromised page or document can contain instructions that try to override the system prompt, expose secrets, change tool behavior, or suppress other evidence. RAG does not eliminate prompt injection; it creates an additional delivery path through retrieved context.
Test documents that tell the model to ignore policy, reveal hidden instructions, call an unauthorized tool, exfiltrate other context, or cite a false authority. Separate content from instructions in the prompt design, restrict tool permissions independently of model output, validate structured actions, and make high-impact operations require deterministic authorization or human approval.
Audit Retrieval Quality as a Security Control
Poor retrieval can become a security problem when the system cites obsolete policy, omits a critical warning, or selects a poisoned document. Measure recall and ranking on a controlled question set, including conflicting versions and near-duplicate sources. Verify that authoritative and current documents are identifiable and that the system can show provenance for the evidence it used.
Monitor sudden rank changes, unusual source concentration, repeated retrieval of newly added documents, and low-evidence answers. AI storage architecture should preserve metadata and deletion semantics while meeting the latency needs of retrieval.
Inspect Prompt Assembly, Output Handling, and Tools
Review the exact prompt template and the maximum context assembled for each application path. Confirm that system instructions, user input, retrieved text, memory, and tool results are clearly separated and that sensitive fields are minimized. Output filters should be treated as one layer, not proof that unauthorized data never reached the model.
Downstream applications must treat model output as untrusted. Escape rendered content, validate code and structured fields, restrict database queries and tool calls, and enforce authorization outside the model. Log enough information to investigate an event without creating a new repository of sensitive prompts, retrieved passages, or responses.
Verify Deletion, Retention, and Incident Response
Delete a test source and trace its chunks, embeddings, metadata, caches, evaluation sets, logs, snapshots, and backups. The result should match the approved retention policy, including documented exceptions for immutable copies. Confirm that a source permission change propagates faster than the maximum acceptable exposure window.
Run an incident exercise for a poisoned document or cross-tenant retrieval. The team should identify affected sources, queries, users, outputs, and downstream actions; disable the source; rebuild affected indexes; preserve evidence; notify owners; and test that the issue is contained. Managed AI Infrastructure can support monitoring and response, while AI infrastructure observability can connect workload and audit events.
Use a RAG Security Acceptance Checklist
- Inventory all sources, derived stores, identities, model endpoints, tools, logs, and recovery copies.
- Prove source provenance, integrity, approval, versioning, and change ownership.
- Run cross-user and cross-tenant negative retrieval tests after permission changes.
- Test poisoned documents, indirect prompt injection, malicious metadata, and ranking manipulation.
- Validate prompt assembly, tool authorization, output handling, and sensitive-data minimization.
- Measure retrieval quality for current, conflicting, and high-risk documents.
- Execute source deletion, cache invalidation, index rebuild, and incident-response procedures.
FAQ
Does a private vector database make RAG secure?
No. A private database can strengthen the infrastructure boundary, but security also depends on connector permissions, source provenance, metadata, query-time authorization, prompt assembly, model and tool behavior, logs, and deletion. Test the complete application path. Unauthorized content must be excluded before it reaches the model, not merely hidden in the user interface.
How can RAG systems prevent cross-tenant data leakage?
Carry tenant and access attributes from each source into every chunk and index record, enforce filters before or during retrieval, isolate credentials and caches, and run negative tests with similar queries across tenants. Monitor filtered candidate counts and authorization failures. Do not depend on prompt instructions asking the model not to reveal another tenant's content.
What is indirect prompt injection in RAG?
Indirect prompt injection occurs when retrieved content contains instructions that influence the model in an unintended way. The attacker may place the content in a document or webpage rather than the user prompt. Mitigation requires treating retrieved text as untrusted, constraining tools, validating actions, separating data from instructions, and testing adversarial documents.
How often should RAG security be audited?
Monitor critical controls continuously and run a formal audit based on application risk and change rate. Trigger targeted testing after new connectors, model or prompt changes, authorization redesign, tool integration, major source migrations, incidents, or index changes. Repeat cross-tenant, prompt-injection, deletion, and recovery tests before material production releases.
Summary
Audit RAG as a complete data and decision pipeline: prove source integrity, permission inheritance, retrieval quality, resistance to malicious context, safe tool and output handling, and reliable deletion and response. Teams can request a OneSource Cloud RAG infrastructure review to map security requirements to compute, storage, network, orchestration, and operational evidence.