RAG Access-Control Leakage Investigation

Investigate whether the RAG system described below retrieved, embedded, cached, cited, or exposed content outside the requesting identity, tenant, purpose, region, or document authorization boundary.

Do not perform a general RAG quality review, connector security review, model safety review, or relevance evaluation unless it directly affects authorization leakage evidence. Use only the evidence provided. Do not claim that a log, policy, source, command, system, test, approval, or remediation was inspected or completed unless it is present in the supplied materials.

Context and inputs:
- RAG system and deployment context: [RAG system and deployment context]
- Identity, tenant, purpose, region, and document authorization model: [Identity tenant purpose region and document authorization model]
- Evidence bundle, including any retrieval logs, citation traces, document ACLs, embedding ingestion records, cache records, query logs, response samples, tickets, diagrams, or policy excerpts: [Evidence bundle]
- Suspected leakage scenarios or query samples: [Suspected leakage scenarios or query samples]
- Time window and affected environments: [Time window and affected environments]
- Accountable owners and decision deadline: [Accountable owners and decision deadline]

Investigation rules:
1. Separate observations from inference. Label each material statement as Evidence, Inference, Gap, or Decision.
2. Preserve uncertainty. If evidence is missing, conflicting, sampled, redacted, or outside the time window, say so plainly.
3. Trace authorization from requesting identity to document exposure. Include retrieval, ranking, embedding, cache, citation, prompt assembly, generated response, export, telemetry, and feedback paths where evidence exists.
4. Treat access-control boundaries independently: identity, tenant, purpose, region, document-level authorization, group membership, delegated access, service account access, and temporal entitlement changes.
5. Distinguish content that was indexed, embedded, retrieved, ranked, cached, cited, included in context, generated in the answer, logged, or externally exposed.
6. Do not assume that document-level authorization at source ingestion remains valid at query time. Look for entitlement drift, stale indexes, overbroad service accounts, cache reuse, citation leakage, and post-filter bypass.
7. Do not recommend broad rewrites. Recommend the smallest containment and verification actions that fit the observed risk.
8. Assign owner accountability by role where needed: security reviewer, data owner, product owner, release owner, search/retrieval owner, platform owner, or legal/privacy owner.

Deliverable:

1. Investigation scope
- State the system, environments, time window, suspected boundary, and query/document populations covered.
- State what is explicitly out of scope.
- List the supplied evidence types and any major missing evidence.

2. Evidence register
Create a table with columns:
- Evidence ID
- Evidence type
- Source or artifact name
- Time range
- What it shows
- Authorization boundary relevance
- Limitations or uncertainty

3. Identity-to-document authorization map
Create a map or table showing:
- Requesting identity or role
- Tenant or account
- Purpose or workflow
- Region or data residency boundary
- Entitlement source
- Allowed document classes or IDs
- Disallowed document classes or IDs
- Query-time enforcement point
- Retrieval/index/cache/citation enforcement point
- Evidence supporting the mapping
- Gaps requiring owner confirmation

4. Leakage-path reconstruction
For each suspected or observed leakage path, reconstruct the sequence from request to exposure:
- Query or trigger
- Requesting identity and authorization state at the time
- Retrieval/index candidate set
- Filter or authorization check expected
- Filter or authorization check observed
- Document, chunk, citation, cache entry, embedding, or response involved
- Exposure mode: retrieved, ranked, cached, cited, placed in prompt context, generated in response, logged, exported, or visible in UI/API
- Boundary crossed: identity, tenant, purpose, region, document authorization, or timing/entitlement drift
- Evidence supporting the path
- Alternative explanations
- Confidence level: confirmed, probable, possible, or not supported

5. Affected corpus and query scope
Estimate the likely scope without overstating certainty:
- Affected tenants, identities, groups, regions, document classes, indexes, embeddings, caches, and environments
- Query patterns likely to trigger the issue
- Whether exposure appears isolated, systemic, configuration-specific, connector-specific, cache-specific, or time-bound
- Known false-positive or false-negative risks in the evidence
- Additional evidence needed to narrow scope

6. Containment decision
Provide a decision-ready containment assessment for the accountable owners:
- Immediate risk level and rationale
- Recommended containment action: no action, monitor, disable affected queries, invalidate cache, remove affected index, restrict service account, re-ingest with corrected ACLs, disable citation/source display, tenant isolate, region isolate, or pause release
- Why this is the smallest safe containment action supported by the evidence
- Operational impact
- Data owner, security reviewer, product owner, and release owner decisions required
- Conditions for lifting containment

7. Regression test matrix
Create a test matrix that can be used by engineering and security reviewers. Include:
- Test ID
- Boundary tested
- Test identity or role
- Allowed corpus
- Forbidden corpus
- Query pattern
- Expected retrieval behavior
- Expected citation behavior
- Expected cache behavior
- Expected response behavior
- Required logs or traces
- Pass/fail criteria
- Owner responsible for verification

Include tests for at least:
- Same-tenant allowed document retrieval
- Same-tenant forbidden document exclusion
- Cross-tenant exclusion
- Region boundary exclusion
- Purpose-boundary exclusion where applicable
- Stale group membership or entitlement removal
- Cache reuse across identities or tenants
- Citation/source leakage without answer leakage
- Embedding/index rebuild after ACL correction
- Service account or delegated access path

8. Open questions and evidence requests
List only the missing items that materially affect the containment decision, scope estimate, or regression coverage. Assign each request to a specific owner role.

9. Completion checks
End with a concise checklist confirming whether the current evidence is sufficient to:
- Determine if leakage occurred
- Identify the likely leakage path
- Estimate affected corpus and query scope
- Make a containment decision
- Define regression tests
- Proceed to remediation planning

If any check cannot be completed from the supplied evidence, mark it as incomplete and explain the exact missing evidence.