Retrieval must respect the permission model

Relevance is only one retrieval requirement

A search system tries to find information related to a question. A business application must also decide whether the requester may see that information. Those are different decisions. A highly relevant document from the wrong customer or a restricted internal project is still an invalid result. Better ranking cannot compensate for an authorization boundary that is missing or applied too late.

AWS documents metadata filtering for retrieval in Amazon Bedrock Knowledge Bases, including access-control patterns. OWASP's authorization guidance recommends least privilege and validating permissions on every request. These references provide useful mechanisms and principles. The application still needs to define its actual access rules and verify that its retrieval pipeline implements them consistently, including the paths that do not appear in a normal chat demonstration.

Resolve identity before forming the search

Build the authorization context from the authenticated session and trusted application data. It may include the organization, project membership, document relationships, and restrictions that apply to the task. The model may help interpret a topic or generate search terms. It should not be responsible for choosing the tenant identifier or deciding which permissions to apply.

Apply restrictions before retrieved content is passed to the model. Filtering an answer after generation is too late to prevent confidential material from influencing that answer or entering logs. A constrained search can be followed by a fresh permission check on returned records, particularly where the index can lag behind the authoritative system. Define what the application does when authorization data is unavailable instead of silently broadening access.

Design for changes in access

Permissions have a lifecycle. People leave projects, documents move between teams, and records become restricted. If the search index holds an old snapshot of access metadata, a user may retain effective access longer than intended. Decide how quickly changes must propagate and what compensating check protects the interval. The answer depends on the sensitivity of the information and the cost of checking current state.

Caching deserves the same attention. A cache key based only on the question can reuse an answer across users with different rights. Scope cached material to the relevant authorization context, and choose invalidation rules for permission changes. Where the policy is complex, storing references and recomputing an authorized response may be easier to reason about than storing a fully assembled answer for broad reuse.

Follow the data beyond the answer

Citations, document previews, exports, and saved conversations create additional access paths. A citation label can itself reveal sensitive information even when the document link is protected. A downloaded summary can combine information from several sources with different restrictions. Treat generated artifacts as data products with an owner, a purpose, and a policy for who may read them later.

Consider a hypothetical employee who was allowed to read a project report yesterday but loses membership today. Should a saved answer still display the report's contents? There is no universal product answer, but there must be an explicit one. Distinguish immutable records required for an approved purpose from convenience history that should reflect current access. Work with the organization's data owners to define that behavior.

Document which system is authoritative for each permission. Search metadata may be a projection, while project membership lives elsewhere. If two sources disagree, establish precedence and record the decision. This is particularly important after migrations, when an old role field may remain populated even though a newer relationship model now controls access to the same records.

Test denied paths as carefully as useful answers

Create a retrieval test matrix that crosses users, organizations, projects, and document states. Check both direct questions and indirect requests such as comparisons or summaries. Include records with similar titles across tenants, missing metadata, stale index entries, and permissions revoked during a session. Verify what reaches model context, not only what appears in the final response.

Measure authorized retrieval quality separately from leakage prevention. If stricter filtering reduces useful results, improve indexing and permission metadata rather than weakening the boundary. A transparent answer that explains it cannot find enough accessible evidence is preferable to a complete answer assembled from material the user should never receive. For enterprise AI, respecting the existing permission model is part of correctness, alongside factual accuracy and relevance.