RAG Retrieval Authorization and Data Lifecycle: Tenant Filters, Provenance, and Deletion

RAG access control and data lifecycle are retrieval concerns in retrieval-augmented generation (RAG) systems, not work to do after an answer has been generated. A useful RAG system can find relevant chunks. A trustworthy one decides, on the server, whether a caller may receive those chunks, retains the source revision that produced them, and removes derived data when the source or its permissions change.

That framing puts the boundary before prompt construction. A tenant ID sent by a browser is an input to validate, not proof of authorization. Similarly, deleting a source file does not by itself remove its chunks, embeddings, index entries, or cached answers; OWASP says deletion must be explicitly propagated across derived artifacts.

RAG access control and data lifecycle begin before retrieval

A retrieval request has two inputs with very different trust levels: the question and the authenticated identity. The question can be supplied by a caller. The server derives the retrieval scope from the identity and its own authorization rules.

Microsoft's secure multitenant RAG architecture guidance describes the same request path: an identity provider authenticates the user, the orchestrator retrieves tenant-authorized grounding data, and only that grounding data reaches the model. Microsoft also recommends an API layer in front of storage so data-access policy is centralized instead of repeated through the application.

This distinction matters even when every user belongs to only one tenant. A document can have an additional classification, department rule, owner, project membership, or expiry state. Tenant selection routes the request to an appropriate corpus. Access-control list (ACL) evaluation determines which documents inside that corpus remain eligible.

For RAG access control and data lifecycle, make the server-side scope an explicit value. The code below and the remaining snippets were validated with .NET 8 and C# 12; they use only BCL APIs and require no external package references. AuthenticatedIdentity represents a value the server has already validated; RetrievalScope is derived from it. There is no method that accepts a tenant ID from request JSON and turns it into a scope.

using System;
using System.Collections.Immutable;

var identity = new AuthenticatedIdentity(
    SubjectId: "user-42",
    TenantId: "contoso",
    Roles: ImmutableHashSet.Create(StringComparer.Ordinal, "finance-reader"));

var scope = RetrievalScope.From(identity);

Console.WriteLine($"{scope.TenantId}: {string.Join(", ", scope.AllowedClassifications)}");

public sealed record AuthenticatedIdentity(
    string SubjectId,
    string TenantId,
    ImmutableHashSet<string> Roles);

public sealed record RetrievalScope(
    string SubjectId,
    string TenantId,
    ImmutableHashSet<string> AllowedClassifications)
{
    public static RetrievalScope From(AuthenticatedIdentity identity)
    {
        var classifications = identity.Roles.Contains("finance-reader")
            ? ImmutableHashSet.Create(StringComparer.Ordinal, "public", "finance")
            : ImmutableHashSet.Create(StringComparer.Ordinal, "public");

        return new RetrievalScope(
            identity.SubjectId,
            identity.TenantId,
            classifications);
    }
}

The retrieval adapter receives this scope and turns it into a constrained query for its particular store. That adapter can choose a tenant-specific store, apply metadata filtering in a shared store, or do both. The domain contract should not hide which path occurred. Record the tenant, policy version, and effective classifications with the request audit event.

This is separate from a framework-specific RAG build. If you need a walkthrough of an application pipeline, see the existing document Q&A app with Semantic Kernel. The authorization rule remains the same regardless of framework: unauthorized chunks must not be returned to the component assembling model context.

Choose the isolation boundary deliberately

RAG access control and data lifecycle work differently in a silo, pool, or hybrid topology. None of those names declares a universally correct architecture. They make different failure boundaries and operational costs visible.

In a silo model, a tenant has a dedicated store, collection, or index. The store boundary itself is a strong discriminator, and per-tenant capacity or lifecycle operations are easier to attribute. The tradeoff is operational overhead: more stores, more provisioning, more index maintenance, and more capacity planning.

In a pooled model, tenants share a store and each chunk carries tenant and ACL metadata. This can reduce the number of physical resources, but every retrieval path must enforce the derived scope. Microsoft says that a multitenant-store query must include a tenant discriminator, while OWASP recommends access-control metadata on every vector chunk, not only on the source document.

A hybrid model combines the two. For example, an application can use a shared corpus for information authorized to all tenants, pooled storage for ordinary tenant content, and isolated stores where a workload's operational or data-isolation needs justify them. This is an architecture choice based on the tenant model, amount of data, lifecycle differences, and the data service's limits. It is not a vector-store product recommendation.

Whichever topology you use, keep two checks distinct:

1. Select the candidate corpus using the server-derived tenant and data topology.
2. Apply the effective document or chunk ACL before returning retrieval results.

Filtering only after the application has received a broad result set weakens the boundary. The forbidden text, scores, and metadata have already crossed into an application layer that did not need them. OWASP recommends query-time filtering and warns against relying solely on post-retrieval filtering in multitenant or multi-classification environments.

Carry provenance and revisions into every chunk

Authorization is only one metadata lineage. A retrievable chunk should also retain a durable source ID, source URI or repository reference, source revision, content hash, ingestion time, and the policy metadata that applied at ingestion. Those fields let an operator answer basic questions after a result has been used: Which source produced this? Which revision? Which derived record was returned? Was the source known when the chunk was indexed?

The OWASP RAG Security Cheat Sheet recommends document hashing and provenance at ingestion, source attribution in responses, and audit records for retrieval. Those practices are useful for ordinary lifecycle work too. A source revision gives re-indexing and deletion a stable target rather than a search for text that might have changed during extraction.

Here is a second runnable .NET console example. It creates a revision record from source text. A real ingestion service would persist the record and copy its immutable identity fields onto every chunk before that chunk becomes searchable.

using System;
using System.Security.Cryptography;
using System.Text;

var source = SourceRevision.Create(
    documentId: "handbook-2026",
    revision: "42",
    sourceUri: new Uri("https://docs.example.test/handbook"),
    content: "Expense reports require manager approval.");

Console.WriteLine($"{source.DocumentId}@{source.Revision} {source.Sha256}");

public sealed record SourceRevision(
    string DocumentId,
    string Revision,
    Uri SourceUri,
    string Sha256,
    DateTimeOffset IndexedAt)
{
    public static SourceRevision Create(
        string documentId,
        string revision,
        Uri sourceUri,
        string content)
    {
        var hash = Convert.ToHexString(
            SHA256.HashData(Encoding.UTF8.GetBytes(content)));

        return new SourceRevision(
            documentId,
            revision,
            sourceUri,
            hash,
            DateTimeOffset.UtcNow);
    }
}

Do not confuse provenance with a citation-shaped string generated after the fact. Retrieval should return the selected chunk identifier and its stored provenance. The response layer can then display or serialize that evidence without asking a model to invent it. For background on a framework-specific retrieval implementation, the existing Semantic Kernel RAG guide is a useful companion, but it does not replace the source and policy records described here.

Revisions also prevent a subtle stale-data problem. If a document is re-indexed with a different chunking policy or embedding model, the application can distinguish the previous derived representation from the current one. A retrieval audit can therefore say which revision was used, while lifecycle processing can retire the superseded revision instead of assuming that similarly named chunks are interchangeable.

RAG access control and data lifecycle include permission changes

Source deletion is one lifecycle event. Permission revocation and source expiry are others. A user may lose a role, a document can change classification, and an entire tenant can be deprovisioned. In all three cases, the safe immediate behavior is to derive a new scope at query time and enforce it during retrieval. Ingestion-time checks alone cannot capture a later policy change.

The OWASP RAG Security Cheat Sheet says that permissions can change after ingestion and recommends re-evaluating access controls on stored chunks when source permissions change. It also treats embeddings as sensitive derived data rather than anonymous numeric values. That is why RAG access control and data lifecycle need the same identity and policy boundary for source text, chunk metadata, embeddings, and retrieval results.

Response caches need the same discipline. A cache key should incorporate the authorization context that affects the answer, such as tenant, effective policy version, classification set, and source revision watermark. Caching a response only by normalized question can return a previously authorized answer under a different caller's scope, so the OWASP RAG Security Cheat Sheet recommends cache isolation and invalidation when a source is updated, deleted, or changes permissions.

The related Microsoft Agent Framework middleware article can help when you are learning about application pipeline concerns. Here, the important rule is narrower: performance caching must not become an alternate retrieval path that skips current authorization.

Make deletion propagation an explicit work item

Deleting a source record does not automatically remove data derived from it. The OWASP RAG Security Cheat Sheet recommends a propagation workflow that identifies the source revision, prevents it from serving new retrievals, deletes or tombstones its chunks and vectors through the storage adapter, invalidates affected permission-scoped caches, and records outcomes for follow-up.

This third complete example creates a provider-neutral deletion work item. It does not claim to delete anything. A background worker can dispatch each target to the appropriate adapter and record a success, retry, or failure outcome. Keeping that orchestration explicit makes it possible to audit incomplete propagation. For high-impact deletion requests, a tool-approval and human-in-the-loop boundary can keep approval separate from adapter dispatch.

using System;
using System.Collections.Immutable;

var workItem = DeletionWorkItem.Create(
    documentId: "handbook-2026",
    revision: "42",
    reason: "Source removed");

foreach (var target in workItem.Targets)
{
    Console.WriteLine($"{workItem.DocumentId}@{workItem.Revision}: {target}");
}

public enum DeletionTarget
{
    ChunksAndVectors,
    DerivedIndexes,
    PermissionScopedCaches
}

public sealed record DeletionWorkItem(
    Guid Id,
    string DocumentId,
    string Revision,
    string Reason,
    DateTimeOffset RequestedAt,
    ImmutableArray<DeletionTarget> Targets)
{
    public static DeletionWorkItem Create(
        string documentId,
        string revision,
        string reason)
    {
        return new DeletionWorkItem(
            Guid.NewGuid(),
            documentId,
            revision,
            reason,
            DateTimeOffset.UtcNow,
            ImmutableArray.Create(
                DeletionTarget.ChunksAndVectors,
                DeletionTarget.DerivedIndexes,
                DeletionTarget.PermissionScopedCaches));
    }
}

The work item is not a substitute for an implementation. Its value is the contract: adapters report what they removed against the same document and revision identity. If an adapter fails, the event remains visible and the source is not quietly assumed to be absent from every derived system. Backups, immutable audit records, and retention-managed telemetry can have different handling rules from online retrieval artifacts, so list them separately instead of making a blanket deletion claim.

Audit the decision, not just the answer

An answer audit should connect the authenticated subject, tenant, effective scope, policy version, query identifier, selected chunk IDs, source revisions, cache outcome, and deletion state. Avoid using the audit log as an uncontrolled copy of source text or prompts. A trace that cannot identify the retrieved revision is too weak for investigation; a trace that duplicates sensitive content indefinitely creates a second lifecycle problem.

For RAG access control and data lifecycle, a useful audit event answers these questions:

• Which server-derived scope was applied?
• Which store, collection, or isolation path was queried?
• Which chunk and source revision were returned?
• Which policy decision admitted each result?
• Was a cache used, and under what scope?
• Has a deletion or de-permissioning work item completed for that revision?

The OWASP RAG Security Cheat Sheet calls for logging retrieved chunks with identity and access-control metadata, cache activity, and data-deletion verification. Microsoft similarly recommends access logs for grounding information through the API layer. Those records make a cross-tenant retrieval test or stale-permission incident diagnosable without pretending that the model itself enforced authorization.

The approved Semantic Kernel vector-store article provides framework-oriented vector-store context. This article intentionally stays above that API layer: an index implementation may change, but the authorization, provenance, deletion, and audit contracts should remain.

Test the lifecycle at the retrieval boundary

Testing only that an index receives a chunk is insufficient. The important tests start from a server-derived scope and verify observable behavior at the retrieval boundary.

The OWASP RAG Security Cheat Sheet includes cross-tenant retrieval, stale-permission, cache-leakage, and data-deletion verification in its minimum deployment test cases. Use an isolated test corpus with at least two tenants, two classifications, and a document revision. Verify that a scope for tenant A never receives tenant B's chunk. Revoke a role and verify that a subsequent retrieval no longer returns the protected chunk. Then remove or de-permission a source revision, run the deletion work item, and verify that its chunks, vectors, and permission-scoped cache entries are no longer eligible.

Test failure behavior too. If the policy service cannot produce a scope, the retrieval adapter should not broaden the query. If a deletion adapter fails, record the failure and keep the work item actionable. If a cached answer lacks a matching policy context, treat it as a miss rather than as evidence that the caller is allowed to see it.

These tests keep RAG access control and data lifecycle focused on facts the application can observe: a result is either eligible under the current scope or it is not; a revision is either still retrievable or it is not. They do not require a product benchmark, a client-supplied filter, or a claim that a particular vector-store API cascades deletion.

Frequently asked questions

Should a RAG system trust a tenant ID sent by the client?

No. The server should derive tenant and authorization context from the authenticated identity and its policy rules. Client values can help route an application request, but they are not proof that the caller is entitled to a corpus or document.

Is a store per tenant enough to authorize every retrieval?

No. A tenant-specific store narrows the data boundary, but users in the same tenant can still have different document permissions, roles, or classifications. Evaluate the effective ACL during retrieval as well.

Do document permissions automatically apply to vector chunks?

Not by default. Chunking and embedding create derived records. OWASP recommends preserving the document's tenant and access-control metadata on each chunk and enforcing it at query time.

Does deleting a source document automatically remove its vectors?

Not by default. Do not assume that deleting a source document removes chunks, vector records, derived indexes, or relevant caches; design and verify explicit propagation for the stores your system uses, as OWASP recommends.

What provenance should a retrieved chunk retain?

Keep a durable source ID, source location, revision, content hash, ingestion time, and policy metadata. This lets a response cite actual retrieval evidence and lets an operator find all derived artifacts for a source revision.

Should RAG audit logs contain the entire prompt and source text?

Not by default. Retain identifiers, scope, policy decision, chunk IDs, source revisions, cache state, and timing needed for investigation. Treat raw prompts and content as data with their own access and retention requirements.

Keep retrieval, lifecycle, and evidence connected

The durable lesson is that RAG access control and data lifecycle form one chain: authenticated identity becomes a server-derived scope, the scope limits candidate chunks, provenance explains which revision was used, and a source or permission change triggers explicit work across derived artifacts. That chain produces answers with evidence while leaving authorization and deletion in application-controlled boundaries, where they can be tested and audited.