A staff member asks an internal assistant for a project summary. The answer is accurate, well written, and supported by a source. It can still be a security failure if that source belongs to another client, contract, or restricted team. Retrieval quality and access authorization are separate requirements.
The retrieval boundary
A relevant document is not automatically an authorized document
Retrieval-augmented generation connects a model to an external collection of information. Documents are often split into chunks, converted into embeddings, and searched for material related to a query. Every step can create a new place where permissions or sensitive content are lost.
A connector may read a repository using a broadly privileged service account even though the requesting user has narrower access. If the retrieval service treats the connector’s access as the user’s entitlement, it can disclose information through an otherwise normal answer. The authorization decision must follow the user and the purpose of the request.
The model should receive only the information the requesting user is authorized to use for that task.TDG perspective
Control surface
Protect the whole retrieval path
OWASP identifies unauthorized retrieval, cross-context leakage, embedding inversion, and data poisoning as material risks. The practical boundary includes more than the vector database.
Source connectors
Limit ingestion identities to approved repositories and purposes. Preserve source identity and access metadata.
Chunks and metadata
Keep document identifiers, classifications, tenant boundaries, versions, and permission relationships attached to each chunk.
Embedding services
Review what text leaves the environment, where it is processed, and how provider retention and access are configured.
Vector stores
Restrict query and administrative access. Use partitions and enforced filters appropriate to the sensitivity and tenant boundary.
Rerankers and caches
Apply the same authorization rules before sending text to a reranking service or returning cached results.
Answers and records
Protect citations, conversation history, traces, and evaluation data that may preserve retrieved information.
Authorization design
Filter before sensitive text leaves the retrieval boundary
Derive the user identity, tenant, and entitlements on the trusted server. A client-supplied tenant identifier or filter should not be accepted as proof of access.
| Control point | Required behavior | Evidence |
|---|---|---|
| Ingestion | Carry source permissions and classification into the index. | Source identifier, chunk identifier, version, and access metadata. |
| Query | Constrain candidate selection to the authorized scope. | Authenticated identity, policy decision, and enforced retrieval constraints. |
| Reranking | Send only authorized candidates to downstream processors. | Candidate identifiers and processor boundary. |
| Caching | Partition by the relevant authorization context and invalidate stale access. | Cache scope, permission version, and invalidation result. |
| Response | Expose only permitted content and citations. | Retrieved source identifiers and output review result. |
A final output filter is useful as an additional safeguard, but it is too late to serve as the primary permission check once restricted content has already reached a model or external processor. When permissions cannot be resolved, fail closed and explain that the requested material is unavailable.
Information lifecycle
Do not treat a vector as anonymized source material
An embedding is a numerical representation of information. Its format does not establish that the information is anonymous or safe to disclose. Source chunks, metadata, and access patterns can also reveal sensitive facts.
Classify the collection according to its contents and use. Minimize unnecessary fields before ingestion, encrypt stored information and transport, separate administrative duties, and define retention for each derived copy. Review the embedding provider and any reranking service as part of the data flow.
Permission changes and source deletion need explicit propagation. Remove or invalidate affected chunks, embeddings, caches, and search replicas according to the service design. Document backup retention and restoration behavior so that recovery does not quietly reintroduce deleted or unauthorized material.
Source integrity
Treat retrieved instructions as untrusted document content
A document can contain text that asks the assistant to ignore its rules, disclose other records, or call a tool. A trusted repository can still contain an untrusted document or a compromised revision.
Validate sources, record versions, constrain ingestion, and quarantine suspicious material. Keep document text separate from system instructions and tool authority. Retrieval should supply evidence for an answer; it should not grant new permissions to the assistant. Bound tool access independently and require the appropriate checks for consequential actions.
Preserve source references so a reviewer can determine which version supported an answer. Where sources conflict or evidence is weak, the service should communicate that uncertainty instead of converting a plausible passage into an unsupported conclusion.
Acceptance evidence
Test the failures that a normal demonstration will miss
Create a test collection with synthetic restricted records and distinct users. Verify the intermediate retrieval results as well as the visible answer.
| Test | Expected outcome |
|---|---|
| Cross-user or cross-tenant query | Restricted chunks, titles, and citations do not reach unauthorized users or downstream processors. |
| Permission revoked after indexing | The user loses retrieval access within the defined propagation interval, including cached results. |
| Poisoned source document | Embedded instructions do not change system authority or trigger unauthorized tool activity. |
| Deleted source | Derived retrieval copies are removed or invalidated under the documented lifecycle. |
| Missing authorization metadata | The query denies access rather than broadening the search scope. |
| Diagnostic logging | Useful audit records are retained without unnecessary raw document text or credentials. |
Record who ran each test, the configuration, the source and index versions, and the outcome. Repeat the relevant cases when connectors, permission logic, embedding models, retrieval configuration, or cache behavior change. A successful answer on a public document does not demonstrate isolation of restricted information.
Operational accountability
Make retrieval incidents investigable
Retain enough information to reconstruct the authorization and retrieval decision: request identity, policy version, source identifiers, index version, outcome, and relevant timestamps. Limit who can access these records and how long they remain available.
Monitor denied access, unusual retrieval volume, repeated cross-boundary queries, ingestion failures, and delayed permission updates. Assign owners for the connector, index, application, and underlying source. During an incident, those teams need a common way to isolate the affected collection and determine which requests may have received it.
Leadership questions
Questions to answer before connecting another repository
Adding a source increases both the service’s usefulness and its responsibility for information handling.
- Question 01 Can source permissions be enforced throughout retrieval, reranking, caching, and citations?
- Question 02 Which providers receive source text, and under which retention and processing settings?
- Question 03 How quickly do access revocation and deletion propagate?
- Question 04 Who can stop ingestion or disable an affected collection?
- Question 05 What evidence demonstrates that restricted content stays within its authorized audience?
Selected references
Primary guidance informing this article
Coming next in the series
Identity and Least Privilege for Agents
The next installment examines how user identity, delegated permissions, tool access, and bounded authority shape the actions an agent may take.
