Retrieval and Context

Authorizing retrieved content per item before it enters a model context window: ingest, per-item decisions, partial authorization, and memory.

Retrieval is where the largest volume of sensitive data moves in most AI systems, and where the conventional access model breaks down most completely. A vector search returns the chunks that are semantically closest to a query. Semantic proximity has no relationship to authorization.

This page covers configuring the retrieval boundary so that authorization is resolved per item, before anything reaches a context window.

The ordering rule

The rule that governs this entire page:

Decide, then decrypt. Policy is evaluated before the item is decrypted, not after. Content the requesting principal is not authorized to see is never in plaintext in the retrieval path.

This matters more than it initially appears. A design that retrieves, decrypts, and then filters has already produced plaintext in a process the requester influences. A filtering bug, a logging statement, an error path that echoes context, or an exception trace becomes a disclosure. Deciding first removes that class of failure entirely.

Step 1: Protect at ingest

Content must be protected before it is indexed. An index built over unprotected content cannot be governed retroactively, because there is no policy bound to the items it returns.

At ingest, each item receives:

Classification, applied from your tag schema: either by the connector, by an explicit call, or by a configured default for the source.
A content-addressed identity, so the item is referenceable in policy and lineage independent of where it is stored. See Content Addressing.
A policy binding, attaching the access rules that will be evaluated on every subsequent retrieval.
Source trust, recording where it came from. See Attribute Schema.

Two configuration decisions to make explicitly at this step:

Chunk granularity and inheritance. Where you chunk a document for indexing, decide whether chunks inherit the parent's classification or are classified independently. Inheritance is the safe default and the right starting point. Independent classification is more precise and considerably more work, and is worth it only where a single document genuinely spans classification tiers.

Untagged content. Decide what happens to content arriving with no classification: rejected, admitted at a default tier, or admitted and quarantined pending review. Choose deliberately. The failure mode of leaving this to a default is an index where the governed fraction is smaller than anyone believes.

Step 2: Authorize per item at retrieval

At retrieval time, each candidate item is authorized individually against the requesting principal, purpose, model class, and current policy.

Per-item rather than per-query, for a specific reason: a query is authorized or denied as a unit, which forces a choice between denying the whole query because one result was sensitive, or admitting the whole query because most results were fine. Per-item authorization produces the correct answer (the authorized subset) and makes the exclusions visible.

Configure how excluded items are represented in the response. The options and their trade-offs:

Representation	Behavior	When to use
Silent omission	Item is absent, no indication given	Where the existence of an item is itself sensitive
Explicit placeholder	A marker indicating an authorized-but-withheld item, with a reason code	Default recommendation, the model can acknowledge incompleteness rather than answering confidently from a partial set
Deny the query	Entire retrieval fails if any candidate is unauthorized	High-assurance workflows where a partial answer is worse than no answer

The explicit placeholder is the recommended default because of how models behave on partial context. Given silently truncated context, a model answers as though the context were complete. Given an explicit gap marker, it can say the answer may be incomplete. That difference is often the whole difference between a wrong answer and a useful one.

Step 3: Govern memory the same way

Conversational memory and agent scratchpads are retrieval surfaces, and they are frequently the least governed part of an AI system, because memory feels internal, and because it accumulates quietly.

Every memory entry is a protected artifact. Configure:

Scope binding. Each entry is bound to a scope: session, user, agent, workflow, or tenant. A memory written in one user's session is not retrievable in another's.
Authorization on recall, not only on write. Entitlements change. A memory written when a principal was authorized must be re-authorized when recalled, against current policy.
Classification inheritance. A memory derived from classified content carries that classification. Summarization is not declassification. This is the most common memory governance failure: sensitive content is correctly denied at retrieval, then reaches an unprotected memory entry via a summary and is freely recalled thereafter.
Retention. Memory retention is separate from ledger retention. Set it against purpose, not convenience.

Step 4: Handle indirect injection at the boundary

Retrieved content is untrusted input. A document in your index may contain instructions aimed at whatever model reads it.

The controls that apply here are the source trust attributes from the attribute schema, used at the retrieval boundary:

Restrict retrieval to source trust tiers appropriate to the workload. An agent with tool access to act on the world should draw from a narrower, higher-trust corpus than a read-only summarization workload.
Ensure derived artifacts inherit the trust tier of their least-trusted input, so a summary of an untrusted document does not enter the system as trusted content.

What makes this defensible is what the injected instruction cannot reach. Content that successfully manipulates a model still cannot alter the authorization for the next retrieval, or the tool allowlist, or the output rules, those are resolved outside the model, by a component that does not accept model output as an input. Injection can corrupt an answer. It cannot escalate access.

Verification

Test each of these before considering the retrieval boundary configured:

A query whose nearest matches include unauthorized items returns only the authorized subset, with exclusions represented as configured.
Unauthorized content does not appear in plaintext anywhere in the retrieval path, including logs, traces, and error responses.
Revoking a principal's access to a classification immediately changes retrieval results, without reindexing.
A memory entry derived from classified content carries that classification and is denied on recall by an unauthorized principal.
An item with no classification is handled according to your configured policy, not silently admitted.
Every retrieval decision (allow and deny) appears in the ledger with the principal, item identity, and reason.

Attribute Schema: purpose, model class, and source trust.
Workload Identity, the principals being authorized here.
Connectors, protecting content in the systems your index is built from.
Output Controls, governing what the model produces from authorized context.