Knowledge & actions · Explore this field ↗ · Implementation · 4 min read
Tenant-aware retrieval: authorize before assembling context
Keep isolation, revocation, and document scope at the retrieval boundary so a fluent answer never gets a chance to quote material the user cannot read.
Authorized grounding
- 01Read caller scope
- 02Filter resources
- 03Rank allowed text
- 04Assemble context
Excluded text should not reach ranking or generation.
Original conceptual diagram · not a live trace or measured result.Security trimming comes before relevance
Retrieval has two questions: may this caller see this item, and which permitted items best answer the question? Solve them in that order. Build an authorization scope from current identity, tenant, role or attributes, resource classification, and any time or relationship constraint. Apply it to the candidate set before snippets are assembled for a reranker or model. A prompt saying “only use this customer’s documents” is not a security control.
NIST describes attribute-based access control as evaluating subject, object, operation, and sometimes environment attributes against policy. The guide does not require ABAC; a simple tenant ownership rule may be enough. The point is to make the access decision executable outside generated language.
Model the resource, not just the chunk
Every retrievable chunk needs a durable parent resource ID, tenant or sharing scope, classification, lifecycle state, and version. Inherit or recompute permissions carefully when a document is shared, moved, or split. A chunk copied into a new index without its parent’s policy is an orphaned disclosure risk. Keep source pointers so a permitted citation resolves to a document the user can currently open.
PostgreSQL row security policies illustrate a useful database-level concept: access may be controlled per row and defaults can be restrictive when row security is enabled. Your vector store may not offer the same mechanism. If it does not, enforce equivalent filtering in a trusted retrieval service and test that an unfiltered query path cannot bypass it.
Treat revocation as live policy
Access changes are not only an ingestion event. On every retrieval, evaluate current policy or a deliberately bounded, revocation-aware authorization cache. When an employee leaves a project, a shared link expires, or a file is reclassified, remove or invalidate the resource in indexes and caches. Do not rely on a nightly rebuild as the only revocation path if the content is sensitive.
A practical revocation record includes resource ID, policy version, invalidation time, affected indexes, and completion evidence. It should not include the document body. The same record supports an operator investigation without creating a second uncontrolled knowledge store.
Do not leak through metadata or error language
Titles, filenames, scores, snippets, citation labels, and “no results in Project Falcon” messages can disclose material even when body text is hidden. Filter metadata with the same policy as content. For denied resources, use a neutral outcome such as “I cannot access material for that request,” then offer a legitimate access or handoff path if appropriate.
Worked example, hypothetical: a consultant asks for a contract clause. The index contains a matching clause from two clients. Security trimming admits only the consultant’s assigned client resources before semantic ranking. The response may cite that client’s current policy; it must not reveal that an excluded contract had a stronger textual match.
Test isolation as adversarial behavior
Build paired fixtures with near-identical documents in two tenants, a shared document whose grant is removed, a chunk with stale parent metadata, and a citation request after a session switch. Run normal language questions and direct identifier guesses. Assert not just that the final answer is empty, but that no excluded resource appears in candidates, reranker input, trace displays, cache keys, or status text.
Success criteria are precise: retrieval scope comes from authenticated server state; all returned citations are presently openable by the caller; revocation has a tested maximum effect time; and operator logs retain filter outcomes without protected excerpts. This is a system property requiring integration tests, not a model-evaluation score.
Keep a narrow emergency route
Operations may need a break-glass process, but it must be explicit, time-limited, audited, and separate from routine conversational retrieval. Do not give the assistant a hidden “search everything” fallback to improve answer rates. When information is unavailable, a user can be told what type of access is needed or routed to the document owner.
The limitation is that authorization policy can be incomplete or wrong. Filtering before context minimizes what a defect exposes; it does not cure a bad grant. Review high-impact sharing rules, identity lifecycle, and index synchronization with the accountable security and service owners. Retest revoked resources after every index or policy integration change.
Take it into the review
Retrieval scope record
| Check | Input | Pass record | Denied result |
|---|---|---|---|
| tenant | authenticated tenant ID | tenant-7 | no candidate |
| document grant | resource policy version | grant active | neutral denial |
| lifecycle | resource status | current | exclude stale |
| citation access | current open test | resolves | omit citation |
A starting artifact to adapt to your service—not a ready-made policy, compliance certificate or test result.
Primary reading
Sources and limits
These links support the architecture, policy, or product behavior discussed above. Vendor documentation describes vendor features; it is not independent proof of performance. Current details should be rechecked before a production decision.
What the sources establish
NIST SP 800-162: Guide to Attribute Based Access Control
NIST defines ABAC in terms of evaluating subject, object, operation, and environment attributes against policy rules.
Limits: NIST does not prescribe an architecture for vector retrieval or tenant data stores.
Checked 2026-09-19 · National Institute of Standards and Technology · source publication date not established.
Open original source ↗PostgreSQL documentation: Row Security Policies
PostgreSQL documents row-level policies that restrict rows visible or modifiable for a user, including default-deny behavior when row security is enabled with no policy.
Limits: Database row security does not automatically protect separately indexed or cached retrieval content.
Checked 2026-09-19 · PostgreSQL Global Development Group · source publication date not established.
Open original source ↗Procedures and worked examples are editorial synthesis. Preparation/review dates are not claimed historical publication dates.