Your Knowledge Assistant Should Know What It Is Allowed to Read

A useful knowledge assistant makes internal information easier to find. That becomes a problem when it also makes information easier to find for people who were never allowed to read it.

Imagine a fictional employee asking about a purchasing procedure. The search index contains a staff handbook, a finance working paper, and a board discussion of next year's budget. All three may look relevant to the question. Only some belong in this employee's answer.

The access decision needs to travel through the whole application: search, document chunks, model context, cached answers, citations, and downloads. This essay develops that design problem. It reports no client implementation or security-effectiveness result.

Start with the person making the request

A service account may need broad access to index documents. An employee using the assistant should receive only the access appropriate to their own identity and task. The indexer's permissions cannot silently become the user's permissions.

Derive the principal and tenant from a verified session, then obtain the applicable group membership or other policy attributes from an authoritative source. A tenant name supplied in a question is a search term, not evidence that the person belongs to that tenant.

NIST's Zero Trust Architecture describes an approach that grants no implicit trust solely because of network location or asset ownership. Applied here, keeping inference inside a company network does not settle who may read a particular document. The application still needs an explicit authorization decision. [1]

Keep permissions attached when documents become chunks

Ingestion often turns a document into smaller passages and an embedding representation for search. Preserve the relationship between each passage and its source: tenant, document ID, version, access policy, and the revision of that policy.

A missing access label should trigger a defined exclusion or review path. It should not make a newly imported document available to everybody. The same principle applies when a connector cannot translate a source system's sharing rules accurately.

OWASP's Authorization Cheat Sheet recommends denying access by default and validating permissions on every request. For a knowledge assistant, that principle needs to cover each source and operation, including the path from a citation to the original file. [2]

Decide access before exposing retrieved text

Apply tenant and permission constraints during retrieval. Before any candidate text reaches a reranker, a generator, or a user-visible diagnostic view, check that the caller is entitled to it under the applicable policy.

OWASP's RAG Security Cheat Sheet discusses permission metadata on retrieved material, tenant isolation, and filtering before retrieval. It provides a useful review reference. The particular combination of search filters, policy checks, and source-version handling still needs to be designed and tested for the chosen system. [3]

A model instruction to avoid confidential information cannot repair an earlier disclosure of restricted text into its context. Likewise, hiding a source link after generation does not establish that the answer was independent of the restricted passage. Inspect the data path that supplied the answer.

Give cached answers an access boundary

Two people can ask identical questions and have different rights to the supporting documents. A cache indexed only by question text can therefore be the wrong abstraction for an internal assistant.

Record which sources and versions contributed to a cached response. Bind reuse to an appropriate tenant and authorization scope, with a way to detect relevant policy changes. Recheck the contributing sources before delivery. A carefully structured cache key helps organise the lookup; it is not a substitute for that access decision.

Consider a finance employee who moves to a different team. A response generated yesterday may still be in the cache today. The system needs a deliberate rule for that transition. Revocation controls future delivery; it cannot make the person forget information they already read or copied.

Handle changes during the request

Permissions can change between retrieval and the moment an answer is ready. Choose a consistency rule and make it testable. One proposed rule is to capture the relevant authorization version at retrieval, check it again before delivery, and abandon an affected response when it has changed.

That rule creates implementation questions. Which policy changes invalidate the response? What happens during a long generation? Can a revoked source still be cited? Does an export job recheck access? Answers need to be part of the application contract, with tests that change access while work is in progress.

When authorization cannot be checked, keep the affected operation closed and report the failure clearly. Do not turn an unavailable permission decision into an apparently successful answer from whatever context happens to be available.

Test the route information actually takes

Pair allowed and denied cases around the same fictional document. Repeat them through ordinary retrieval, a warm cache, a saved citation, and a source download. Include two tenants with similarly named groups so a shared label cannot accidentally cross the tenant boundary.

Use synthetic markers in controlled fixtures and capture which source IDs reached each stage. An absence of restricted text in the final answer is insufficient evidence if that text entered a reranker or prompt earlier. Inspect the stage boundaries as well as the output.

The companion permission-aware retrieval design study turns these questions into a proposed twelve-scenario evaluation plan. It is linked from the local LLM research protocol, with a blank evidence record. An implemented assistant and actual traces are still required before any scenario can be called a pass.