RAG Security Testing: Tenant Isolation, Permissions and Data Leakage

A RAG assistant can give a plausible answer while crossing a data boundary. The security question is whether the requesting identity was allowed to retrieve, quote, cache and act on the underlying documents at the time of the request. RAG security testing should establish those permissions throughout the retrieval pipeline, rather than score the wording of the final answer alone.

This guide provides a staging acceptance method for application owners and pentesters. It uses designated accounts and synthetic documents, with a positive control for each denial test. The matrix below is a proposed assessment design, not a report of tests performed against a customer system.

Map the retrieval path before testing the model

Record the source connector, document owner, ingestion job, chunk identifiers, vector index or namespace, retrieval service, reranker, context assembly, answer cache and citation endpoint. Include any tool that can fetch source text after generation. For each stage, identify where the user and tenant are derived and where authorization is enforced.

OWASP’s RAG Security Cheat Sheet covers cross-tenant retrieval, stale permissions, cache leakage and deletion verification. The practical consequence is that an answer-only check is incomplete: a forbidden chunk may already have reached a model, trace or citation route even if the final response refuses to quote it.

Build a small fixture with known permissions

Create two test tenants, A and B. Give each a reader account and a private document containing a distinct synthetic marker, such as RAG-A-ORCHID-731 और RAG-B-CEDAR-482. These are inert fixture labels, not secret values. Add a public document and a document visible to a selected group inside tenant A. Record all expected access relationships before ingestion.

Use two A identities: one allowed to read the group document and one excluded from it. This catches the common gap where tenant filtering works but document-level or group-level permissions do not. Have the allowed reader retrieve its own marker first. If ingestion or retrieval is broken, a subsequent missing marker cannot establish that authorization is effective.

Run a RAG penetration testing acceptance matrix

Keep queries, corpus revision and application configuration stable while changing one permission condition at a time. Test through the real application entry point. Direct database checks can explain a failure, but do not replace the end-to-end path used by a reader.

Check vector database access control at the service boundary

A namespace is an organizational mechanism until the application binds it to an authenticated principal. Inspect whether the retrieval service chooses the tenant from a trusted server-side identity, or accepts a caller-supplied tenant or namespace without verifying it. Prefer a fixture request created through the application’s documented interface; do not invent an endpoint to fit a test script.

Test ACL metadata on every derived chunk, not just its parent document. Re-indexing, document moves and ingestion retries can create inconsistent copies. Where a service account can query multiple tenants, the application must still restrict the result set for the requesting user. Collect the effective policy, not only a configuration file that may differ from the deployed service.

Separate retrieval leakage from prompt injection

Place an inert instruction in an authorized staging document asking the assistant to include a made-up marker in its answer. Its appearance can show that retrieved instructions influenced output. It does not by itself prove data theft or unauthorized tool execution. Record those as separate outcomes.

For indirect prompt injection testing, define a forbidden action in advance, such as reading the other tenant’s synthetic document or invoking a write tool without approval. Use a stub tool with no production side effect. Then inspect the authorization decision and attempted action. The security finding is the failed boundary, not how dramatic the generated prose sounds. The broader LLM penetration testing workflow explains how to separate model behavior from application impact.

Make revocation and deletion measurable

Agree on the access-revocation and deletion deadlines before running tests. Record whether a deadline comes from product behavior, an internal policy or a contractual requirement. Do not substitute an arbitrary delay and call the system compliant. Check new sessions, existing sessions, cached answers and direct citation access separately.

Removing a source from a vector index does not automatically remove application caches, logs, exports or backups. Define which stores the deletion requirement covers and which retention exceptions apply. Keep the report scoped to what was inspected. A test that checks only retrieval should not claim that every copy was erased.

Use evidence that supports a reproducible finding

{
  "case_id": "rag-tenant-boundary-01",
  "requesting_tenant": "A",
  "fixture_owner_tenant": "B",
  "corpus_revision": "staging-fixture-01",
  "policy_revision": "record-at-test-time",
  "expected": "deny private retrieval",
  "observed": "not yet tested",
  "retrieved_chunk_ids": [],
  "citation_access": "not yet tested",
  "cache_behavior": "not yet tested"
}

This is an empty evidence template. Replace placeholders with observed results and retain sanitized request IDs and timestamps. Do not store access tokens or real document contents in the report. Use pass, fail, inconclusive and not tested as distinct states. A missing trace makes an internal claim inconclusive; it does not erase a visible leak in the application response.

Retest the boundary that failed

If tenant A received B content, retest the same fixture and request after remediation, together with the allowed control. If the fix changes ingestion metadata, rebuild the affected fixtures and record that new revision. If the defect was in cache scoping, prove both denial and a legitimate cache hit. A prompt-only change cannot close a finding whose cause was a missing retrieval authorization check.

For a scoped engagement, require the report to name tested identities, data boundaries, propagation windows, excluded stores and evidence gaps. That makes the outcome useful to the engineer who must fix it and the owner who must accept the result.

Keep the retrieval-boundary evidence with the remediation record. If you are evaluating AI-assisted penetration testing for the surrounding application and API attack surface, create a Penligent account and confirm the supported scope before starting. The assessment method here does not imply that every model, identity provider or agent runtime is automatically covered.

Use the product demo as workflow orientation

The official Penligent 3.0 video shows the general testing interface. For this RAG assessment, carry the synthetic tenants, retrieval boundaries and evidence matrix above into your own approved evaluation; the video does not demonstrate those RAG controls.