Designing Retrieval for Permissions That Change

The fictional service and its boundary

This study proposes a read-only assistant serving two fictional organisational tenants, Alpha and Beta. Each has staff documents and restricted finance documents. Some group names are identical across tenants. The assistant would answer only from material available to the requesting principal.

The immediate deliverable is an evaluation plan, rather than an implemented assistant. It contains a synthetic access matrix, twelve planned scenarios, expected boundary behaviour, and an unfilled evidence template. None of the scenarios has been executed, and no production security outcome is claimed.

Keep user authority separate from service authority

The proposed ingestion worker can read approved source repositories to build an index. Its broad technical access does not determine what the application may reveal to an employee. Each interactive request would carry a verified principal, tenant, and policy context through retrieval and delivery.

NIST SP 800-207 frames access around subjects and resources rather than assuming trust from network location. This study applies that principle to the distinction between a privileged indexing process and the person asking a question. It does not claim to implement a complete zero-trust architecture. [1]

Define a small access matrix

The fictional matrix has three principals: an Alpha staff member, an Alpha finance member, and a Beta finance member. Alpha's staff handbook is available to Alpha's staff group. Its budget document requires the Alpha finance group. Beta's budget document belongs to Beta's finance group.

A fourth document deliberately has no access metadata. It is excluded pending resolution. All names and markers are synthetic. The matrix describes intended test behaviour, not a real organisation's sharing policy.

The deny-default and per-request checks recommended in OWASP's Authorization Cheat Sheet inform this choice. Tests must examine the specific object and operation rather than infer permission from successful access to another document. [2]

Place checks before each disclosure boundary

The proposed flow resolves the principal and current permissions, restricts retrieval to the relevant tenant and source scope, and checks candidate authorization before text enters a reranker or generator. It carries source and policy versions with the context.

A later check applies before delivering a generated or cached answer. In this proposed consistency contract, a relevant policy-version change causes the affected response to be abandoned. Source citations and downloads are separately authorized when opened.

OWASP's RAG Security Cheat Sheet addresses retrieval access metadata, tenant isolation, and failure behaviour. Those recommendations guide the review boundaries here. Actual enforcement, race handling, and storage behaviour still need an implementation and observed traces. [3]

Exercise ordinary access and uncomfortable transitions

The first scenarios pair an allowed staff document with a denied finance document, then allow the finance principal to use the appropriate budget. A cross-tenant scenario uses the same group label in Alpha and Beta to test that tenant membership remains part of the decision.

Missing identity and missing access metadata are explicit denial cases. A permission-service outage is a different condition: the request should report that access cannot be checked, with no affected model call or cached delivery.

Transition scenarios cover revoked group membership, a permission change during generation, a cached response presented to a different principal, and opening a previously issued citation after access is revoked. Another case gives the index an old permission version to test the current check before context assembly.

These are proposed tests with declared expected behaviour. They supply no evidence that a particular retrieval engine, model, or product passes them.

Capture enough evidence to locate a failure

A future run record should identify the scenario, application revision, identity snapshot, document and policy versions, cache state, and the exact point where access changed. Capture the authorization decision and source IDs entering the reranker, generator, answer cache, citations, and download path.

Use synthetic markers to check whether restricted content crossed an unauthorized boundary. Keep test traces in an appropriately restricted evidence store. Production prompts and document contents should not be copied into a public report merely to demonstrate that tracing exists.

The released evidence template leaves actual decisions, traces, outputs, timestamps, reviewer, and result unfilled. The local preparation validator checks the plan's structure and coverage, and that the evidence remains unfilled. It does not connect to an assistant or execute the scenarios.

Make a bounded claim after execution

Execution requires a test application, controlled identities, an authoritative permission source, repeatable access changes, and instrumentation at the named boundaries. A clean result would apply to the tested revision and conditions. It would not establish every possible concurrency behaviour or replace a broader security assessment.

Revocation also has a practical limit: the service can stop future delivery, but it cannot recall information already read or copied by a previously authorized user. The acceptance contract should state that boundary plainly.

The local LLM protocol links the plan, guide, and blank record. Its earlier synthetic quality cases remain intact; the new scenarios develop their permission-testing boundary. The related access-control essay explains the operational choices behind the plan.