Access-Controlled RAG

Access control is not one decision. The same identity and permission decision has to survive indexing, retrieval, assembled context, caches, citations, and logs, and hold through the moment a source permission changes.

A source may be restricted correctly and still surface through an old index entry, cache, citation, or log. We trace identity and permission decisions through the full RAG path, then exercise the places where access can leak or lag behind.

The handoff gives your owner a traceable permission path, cross-tenant and stale-access findings, and a response plan for failures that need containment or retesting.

Discuss this workView the parent service
Illustration of Access-Controlled RAG: a team wiring a document pipeline into a retrieval system

Some of the 500+ brands we've worked with

See all references
  • BMW
  • PWC Türkiye
  • Onedio
  • Sporjinal
  • Duru
  • DYO

Steps, gates, and who decides

How we work

We map one permission decision across every dependent layer, implement the controls, and test authorized, denied, changed, and cross-tenant cases before handoff.

  1. Map identity and source rules

    The map connects identities and query contexts to source ACLs and approved data paths. It also records purpose, retention, environment separation, and least-privilege limits for the test boundary.

    AI assist
    A first identity-permission map clusters source ACLs and query contexts for review.
    Human gate
    Can each source permission be traced to an identity and query context? Your data owner confirms which source permissions and query contexts are in scope.

  2. Carry controls through RAG

    Permission rules are applied during indexing and retrieval, then checked through assembled context, caches, citations, and logs. The expected behavior after a permission change is written down for each layer.

    AI assist
    Flags indexing and cache paths where a permission change has not yet propagated.
    Human gate
    Does a changed permission reach every dependent layer within the agreed threshold? Your platform owner sets the propagation threshold for a permission change.

  3. Challenge the access paths

    The test set covers permitted and denied requests, revoked access, and cross-tenant attempts. We also change permissions during indexing and inspect caches, citations, and logs for material the user should no longer see.

    AI assist
    Generates cross-tenant and stale-permission attack variants to widen the leakage test set.
    Human gate
    Do authorization-enforcement and leakage checks pass on every critical slice? Your security lead approves the attack scope and acceptable leakage threshold.

  4. Prepare response and handoff

    Test evidence is linked to detection, containment, correction, and retest steps. Your incident owner decides which failures require immediate action, and your designated authority accepts the remaining risk.

    AI assist
    Drafts the incident detection and containment runbook from the test findings.
    Human gate
    Can the incident owner reproduce the failure and follow the response path? The incident owner decides which access failures require immediate containment.

Named artifacts you keep

What you get

The handoff shows the expected access decision at every layer and keeps the evidence from denied, revoked, and cross-tenant tests available for later retesting.

  • Architecture document

    Identity-to-citation access path map

    The map links identity, source permissions, query context, retrieval, assembled context, caches, citations, and logs.

  • Matrix

    Layer-by-layer permission change ledger

    The expected permission decision at each layer, including exceptions and what must happen after access changes.

  • Test evidence

    Revoked-access and cross-tenant findings pack

    Reproducible tests for authorized, unauthorized, stale-permission, and cross-tenant behavior, with results kept by critical slice.

  • Playbook

    Access-incident containment and retest plan

    The logging, detection, escalation, containment, stop or rollback, correction, and retest path for access-control failures.

Scope and honest limits

When to bring us in

Use this work when the RAG application must preserve source permissions and your team needs evidence for what happens after access changes.

A good fit when

  • Your identity model and source ACLs are documented, but nobody can trace a permission change through indexing, caches, citations, and logs.
  • The denied and cross-tenant requests are blocked, yet a stale cache still exposes material after access is revoked.
  • An access incident can be reproduced, but the incident owner lacks one trace linking the leak to containment, correction, and retest.
  • Source ACLs and user identities are known, but the expected permission decision changes as a request moves from indexing into retrieval.
  • Query-time filtering blocks the first request, while assembled context, caches, citations, or logs may still retain the restricted material.
  • Authorized and denied requests behave as expected, yet stale-permission and cross-tenant cases have not been exercised on every critical slice.
  • Your incident owner sees a failed access check, but the evidence is not yet tied to containment, rollback, correction, and a dated retest.

Better handled as other work when

  • You need an access-control decision to carry legal, regulatory, audit, or certification weight. Your compliance and legal owners sign that off, not this work.
  • You need proof that no future RAG path can leak data. These checks cover the named identities, sources, permission states, and layers in scope.
  • You need source ACLs, caches, or citations changed in production beyond the approved test boundary. That implementation belongs in separately scoped work.

If one of these is closer to your situation, start here instead: View the parent service

Engineers who ship production AI

This is the part of Zeo that writes and ships code. Our senior engineers build agents, chatbots, and RAG pipelines, along with the automation and data work around them, and they keep operating those systems once they're live. We've worked with more than 500 brands since 2011.

Content we've produced on this topic

Articleby Burak PehlivanWhat is WebMCP? Agentic Web and Websites Interacting with AI AgentsArticleby Yiğit KonurMCP Server Safety: Human-in-the-Loop Controls & Risk Assessment

Tools we use

Tools behind this work

  • LlamaIndex

    the pipeline framework identity and permission metadata actually travels through

  • Qdrant

    the vector store enforcing permission filters at the index level, not just the app layer

  • Datadog

    the log monitor catching the access leak the answer itself never shows

  • Mindgard

    the continuous red-team engine exercising the RAG access paths this page names

  • Jupyter

    the notebook rerunning the propagation-timing analysis as a shown calculation

  • Tonic

    the synthetic test data letting leakage testing run without exposing real restricted content

Next step

Test the permission path before release

Share the identity model, source ACLs, permission-change events, and the person who owns access incidents. We will define one permission path that is useful to build and possible to challenge properly.
Talk to Zeo

Before you decide

Questions we hear a lot

We need the identity and authorization model, source ACLs, permission-change events, query contexts, cache and logging design, adversarial cases, a test environment, and incident owners. Before sensitive material enters the workspace, we confirm its purpose, access limits, confidentiality, retention, and an accountable owner.