Need-to-know access

Need-to-know access is an authorization principle: a person or process receives information because a defined task requires that information, not merely because it has a broad role or technical ability to retrieve it. The relevant unit may be a record, field, source excerpt, or export. The principle is often paired with least privilege, which limits capabilities to those needed for assigned functions. Neither principle by itself specifies the correct business decision.

A practical policy maps tasks to permitted information and reviews those permissions as duties change. Retrieval systems must enforce restrictions before exposing snippets, search results, generated summaries, or citations; hiding the original document while revealing its contents in an answer defeats the purpose. Audit records can show access and policy changes. Exceptional access should have a defined reason, duration, and review path rather than becoming a standing blanket permission.

Defending a value requires showing evidence to an authorized reviewer while respecting the evidence owner's restrictions. That tension calls for a controlled inspection path, not for dropping provenance or exposing source material to everyone. Data residency governs permitted locations, while retention schedules govern duration. Need-to-know access governs who or what may inspect the information for a particular purpose, including during evaluation and later audit.

Systems that retrieve documents for a language model add new ways to leak. A search index built over all documents can return passages the user may not see, if the permission check is applied to the document list and not to the passages. A summary generated from restricted documents carries their content into an answer visible to someone without permission. A cache that stores an answer keyed on the question serves it to the next user. A log of prompts holds restricted text in a place with different access. Permission must therefore be enforced at retrieval time, per passage, with the user's identity, and the context passed to the model must contain only what that user may read.

Test it. The article on permission-aware RAG evaluation describes how to construct users with different permissions and probe for leakage through retrieval, summaries and citations. Include the negative case that matters for defensibility: a user without permission asks a question whose answer exists only in restricted material, and the system should say that it cannot answer from what the user may see, without revealing that restricted material exists if the existence is itself sensitive.

Ask where permissions are enforced: at the document, the passage or the answer. Run a set of probe questions as users with different permissions. Check caches, logs and indexes for restricted content. Ask how access decisions are logged and reviewed. Ask how permissions are removed when a role changes.