RAG Security Assessment
RAG systems can leak sensitive data when retrieval, indexing, chunking, permissions, or tenant boundaries do not match the business model. SCS tests what the system retrieves and what it exposes.
RAG Security Assessment.
Secure Consulting Solutions (SCS) provides a RAG Security Assessment for retrieval-augmented generation systems that search, retrieve, cite, or summarize internal documents and knowledge bases.
The assessment validates whether retrieval filters, tenant boundaries, document permissions, citations, chunking, and indexing decisions expose sensitive data or allow document-driven manipulation.
Deliverables include retrieved-document evidence, sensitive category findings, tenant or role exposure context where applicable, remediation guidance, and retest plans.
Assessment summary
| Identity | Which roles, tenants, or personas can retrieve sensitive documents or generated answers. |
| Evidence | Prompts, assistant output, retrieved docs, citations, source paths, metadata, and canary matches. |
| Risk | Retrieval data leakage, document injection, tenant leakage, authorization failure, and source-path exposure. |
| Deliverable | Executive summary, technical report, findings CSV, retrieved-document evidence, remediation guidance, and retest plan. |
What this assessment answers
- Can one role or tenant retrieve another role or tenant's documents?
- Can poisoned documents alter answers, citations, or tool behavior?
- Do retrieval filters enforce authorization consistently?
- Does the model reveal sensitive chunks, metadata, or source paths?
- Can prompt injection inside retrieved content change system behavior?
What we test
- RAG data leakage
- Tenant leakage and cross-role retrieval
- Document injection and poisoning
- Retrieval manipulation
- Embedding and chunking edge cases
- Citation and source-path leakage
- Knowledge base access control
- Sensitive document exposure
Deliverables
- Findings report with reproduction steps
- Retrieved-document evidence
- Sensitive category findings
- Remediation guidance for retrieval and access controls
- Retest plan for fixed filters and indexes
How SCS tests retrieval pipelines.
RAG findings are grounded in retrieved context and source evidence. Inventory context can explain likely causes, but SCS does not treat inventory alone as proof of exposure.
What a RAG security assessment produces.
Teams evaluating a vendor for retrieval-pipeline testing usually want to know what evidence they will hold at the end. Every SCS RAG assessment produces the same package, scoped to the retrieval path rather than to the model alone.
Report contents
| Retrieval evidence | The query issued, the chunks returned, the source paths, and the metadata attached to each result. |
| Authorization findings | Where retrieval crossed a role, tenant, or workspace boundary that the business model does not permit. |
| Exposure paths | The specific route by which restricted content reached an answer, including indirect paths through ingested content. |
| Reproduction steps | The account, query, and system state required to reproduce the behavior. |
| Findings CSV | Machine-readable export for ticketing and remediation tracking. |
| Remediation guidance | The indexing, chunking, filtering, or permission change that closes the gap. |
| Retest cases | Named cases so a fix can be verified after remediation. |
Why retrieval is tested separately from the model
A retrieval pipeline can leak data even when the model behaves correctly. If indexing ingests documents the requesting user cannot open, or if chunking separates content from the permissions attached to its source, the model will faithfully summarize material that should never have reached it.
For that reason SCS tests the retrieval layer as its own attack surface. The assessment examines what the index contains, which identity the retrieval step runs as, whether filters apply before or after ranking, and whether tenant boundaries survive the chunking and embedding process.
Findings therefore point at a fixable component. Remediation usually lands in indexing scope, permission propagation, or query-time filtering rather than in prompt wording.
RAG assessment questions.
What is RAG security testing?
It is security testing for systems that retrieve documents or data before generating answers, with focus on retrieval behavior, source evidence, authorization, and data exposure.
Can you test tenant isolation?
Yes, when scoped identities, tenants, or representative test accounts are available. SCS compares retrieval and answer behavior across those boundaries.
Do you inspect citations and retrieved documents?
Yes. Findings capture retrieved context, citations, source paths, metadata, and answer output when those signals are available from the system or operator evidence.
Do you use canaries?
Where approved, canaries can help validate whether sensitive markers appear through retrieval or answers. SCS reports canary matches as evidence, not as a substitute for broader assessment.
We need a vendor to test data exfiltration risk in our RAG pipeline. Is that in scope?
Yes. Data exfiltration through retrieval is a core scope area. SCS tests whether restricted documents can be surfaced through crafted queries, whether chunk boundaries expose content that permissions should have withheld, and whether ingested content can carry instructions that redirect retrieval or disclosure.
How do you test chunking and embedding boundaries?
SCS seeds identifiable markers into content at known permission levels, then measures which markers can be retrieved by which identity. That shows whether chunking, embedding, or ranking has separated content from the access control attached to its source document.
Does the assessment cover the ingestion and indexing stage?
Yes, when it is in scope. Many retrieval exposures originate at ingestion, where a connector indexes more than the requesting user can open. SCS reviews what the index contains and which identity the ingestion and retrieval steps run as.
How is this different from testing the model itself?
Model testing asks what the model will say. Retrieval testing asks what reached the model in the first place. A pipeline can leak data through retrieval while the model behaves exactly as instructed, so the two are assessed as separate layers.