Freshness, Access Control, and Updates

Goal

Treat freshness, deletion, tenant/access eligibility, and index updates as explicit retrieval controls that are enforced before sensitive evidence reaches generation.

A RAG system can retrieve a highly relevant document and still be wrong or unsafe to use it. Two questions come before similarity:

1. Is this source current enough for the task?
2. Is this user/request allowed to receive it?

Similarity is not authorization.

Freshness is a versioning problem

Suppose the corpus contains:

policy-v3 updated 2026-08-01
policy-v4 updated 2026-09-20

Both may mention the same product. A retriever that ignores version/freshness may return the older policy because its wording matches the query more strongly. Useful metadata can include:

• source version;
• updated_at;
• valid_from / valid_until;
• supersedes;
• active/deprecated status.

Then the eligibility layer can remove stale versions before ranking.

Updating the source is not enough

A source system may be correct while the retrieval index is stale. Think of two identities:

source revision
index build revision

If policy-v4 exists in source storage but the index was built before it was ingested, users still retrieve v3. Record index build time/version and ingestion status. For high-change collections, updates may be incremental rather than full rebuilds. The invariant remains:

The searchable representation must correspond to the source state you claim to serve.

Deletion must propagate

Deleting a source from the document store is not complete if its chunk vectors remain searchable. A robust deletion/update workflow should address:

• source record;
• chunks;
• vector/index entries;
• lexical index entries;
• caches;
• evaluation fixtures or references when appropriate.

A tombstone/version mechanism can help track whether old index entries should remain eligible.

Access control belongs before exposure, not inside persuasive prompt wording

Imagine a multi-tenant corpus:

chunk A → tenant red
chunk B → tenant blue

A red-tenant user asks a query semantically close to chunk B. The system should not retrieve B into the model prompt and then say:

Please do not reveal the confidential text.

The content has already crossed the boundary. Filter eligible chunks by authenticated request context before model-facing inclusion. Depending on architecture, authorization can happen:

• before vector search;
• during search via metadata filters;
• after candidate search but before any untrusted consumer sees the text.

The key requirement is that unauthorized content never reaches the generator or user-visible trace.

Access metadata must not come from the user alone

A request saying:

tenant=blue

is not proof the user belongs to blue tenant. Access claims should come from trusted application/authentication context. This is the same trust-boundary principle used in Level 7.

Evaluate updates and ACL explicitly

Include regression cases such as:

• old policy must not be retrieved after replacement;
• deleted chunk must not appear;
• authorized user retrieves expected private chunk;
• unauthorized user receives no private result;
• shared public chunk remains available;
• cache/index rebuild does not resurrect old content.

Security/freshness controls need executable evidence, not only design documentation.

Filter eligibility before ranking

A document can be semantically relevant and still be ineligible. It may belong to another tenant, be expired, or have been superseded. Those are system constraints, not soft preferences for the language model. Apply them in retrieval or index logic so forbidden evidence never enters the candidate context.

Freshness also requires lifecycle discipline. When a source changes, remove or replace the old chunks that no longer apply. Recompute affected embeddings, rebuild or update indexes, and refresh or invalidate caches as needed. Record both source and index versions. Then a surprising answer can be traced to the snapshot that actually served it. “The current document is correct” is not enough if the request used yesterday's index.

Predict

A document is highly relevant but belongs to another tenant. What should happen?

It should be excluded by the trusted access-control eligibility policyIt should be retrieved and the prompt should ask the model not to reveal itIt should rank lower only if its cosine score is small

Run the local eligibility validator

Start with the trusted session:

python labs/notebooks/level-09/l09-13-eligibility.py

The eligible set is computed before ranking from freshness and tenant rules.

Next, predict whether a tenant name typed by the user should change authorization, then run:

python labs/notebooks/level-09/l09-13-eligibility.py --user-claims-tenant blue

The eligible set should stay tied to the authenticated session. Contrast that with an actual trusted-session change:

python labs/notebooks/level-09/l09-13-eligibility.py --session-tenant blue

Finally, simulate deleting a source without removing its index entry:

python labs/notebooks/level-09/l09-13-eligibility.py --delete-source policy-v4

That command intentionally exits non-zero because an index that still points at deleted content is stale.

Loading lab…

Quick Check

1. What does a stale index mean?

The embedding vectors have zero normThe searchable representation no longer matches the current source stateA stale index means scores are old, not the indexed text

2. Why is prompt-only access control weak?

Prompt instructions can safely enforce access control if the user and source roles are clearly labeledVector search cannot read metadata fields at allUnauthorized evidence may already have been exposed to the model context

3. Where should tenant identity come from?

Trusted authenticated application contextA free-form user sentence claiming a tenantThe tenant named in the highest-scoring retrieved chunk

0 of 3 questions answered.

Explain it back

Describe a retrieval request for a private corpus. Show the order of authentication context, eligibility filtering, similarity ranking, prompt construction, and citation. Explain where a stale index could break the result.

Key Takeaways

• Relevance does not override freshness or authorization.
• Source revisions and index revisions both matter.
• Deletion must propagate to every searchable representation.
• Access control should prevent unauthorized evidence from reaching generation.
• Tenant/user claims must come from trusted context.
• Freshness and ACL require explicit regression tests.

Next Lesson

Next, integrate indexing, eligibility, retrieval, reranking, grounding, citation validation, and evaluation into one reproducible RAG package.

References

• NIST, Zero Trust Architecture — SP 800-207.
• Lewis et al., Retrieval-Augmented Generation.