Provenance, Freshness, and Access Control Inside Context

Provenance, Freshness, and Access Control Inside Context are three attributes that have to survive every stage of the pipeline. They are usually attached at the store and lost by the time the window is assembled, which turns three ordinary engineering properties into three separate classes of incident.

Key takeaways

• Filter by permission inside the retrieval query, not after results come back. Post-filtering leaks through result counts, latency and any code path that forgets to apply it.
• Render the date into the chunk text as well as storing it as metadata. A model cannot reason about recency it was never shown.
• Keep a source identifier on every chunk end to end, so citations are generated from data rather than from the model's memory of what it read.
• Conflicting evidence is normal. Give the model the dates and the sources and an explicit rule for preferring one, rather than hoping it guesses your policy.
• These are the attributes an audit will ask for. Designing them in costs little; retrofitting them means re-indexing the corpus.

Read this beside Chapter 6, which attaches the breadcrumb at chunk time, and Chapter 7, which renders it into the window. Chapter 10 covers what happens when the evidence itself is hostile.

An enterprise customer asks why their internal salary bands appeared in an answer to a contractor. The retrieval layer is working exactly as designed. It was never designed to know who was asking, and nothing in the pipeline noticed the omission, because an answer with the wrong audience looks identical to an answer with the right one.

The fix, in that system, took three months, because permissions had to be attached to every chunk and the corpus had to be re-indexed. The design cost, had it been done at the start, would have been a field.

Permission belongs in the query

There are two places to enforce access control in a retrieval pipeline, and only one of them is safe.

Post-filtering retrieves the top k, then drops what the user may not see. It is easy to implement and it fails in several ways at once. The result count shrinks, which is itself an information leak about how much restricted material matched. Timing differs. Any code path that skips the filter, such as a new endpoint or a background job, leaks everything. And the top k is now the top k of the whole corpus, so a user with narrow permissions gets a nearly empty result set.

Pre-filtering pushes the permission predicate into the retrieval query itself, so the index only ever returns what the requester may see. The count is correct, the ranking is correct within their scope, and a forgotten code path returns nothing rather than everything.

OWASP's 2025 entry on vector and embedding weaknesses is explicit about the risk this addresses, naming unauthorised access and cross-context information leaks in multi-tenant vector databases among its primary concerns, and recommending fine-grained access controls with permission-aware vector stores.

Two implementation notes. Permissions must be copied onto chunks from the source document at index time, and re-copied on every re-chunk. And the identity being filtered on must be the end user's, not the service's, which is the mistake that makes an entire class of system quietly unsafe.

Freshness has to be visible, not just stored

A date in metadata that never reaches the prompt is a date the model cannot use.

Render it. Each chunk's header line in the window should carry the source, the section and the date, as Chapter 7 describes, so the model can say that the figure comes from the 2024 policy rather than the current one.

Then give the model a rule about it, in the instructions. Prefer the most recent document when two disagree. Say when the newest available source is older than some threshold. Do not answer questions about current state from documents older than a stated age without flagging it.

The harder half is knowing what the date means. Three different dates exist for most documents, and they are routinely confused: when it was created, when it was last modified, and when it takes effect. A pricing page modified last week may describe prices effective next quarter. Store the effective date where the corpus has one, because that is the one a reader needs.

Staleness also needs monitoring rather than trust. Track the age distribution of retrieved evidence per query type, and alert when the median age of what you are serving jumps, which is the signal that an ingestion job has been failing quietly.

Provenance is what makes an answer checkable

A source identifier on every chunk is the smallest field with the largest downstream effect.

Citations become mechanical. The model refers to evidence by its index, the application maps indices to sources, and the citation is generated from data rather than from the model's recollection of a URL, which is a well-known way to produce a plausible link that does not exist.

Feedback becomes actionable. "This answer used the wrong document" is only a usable report when a document was identifiably used, and it feeds directly into the labelled set from Chapter 3.

Attribution becomes possible. When the answer is wrong, you can ask whether the evidence was wrong, missing, or present and ignored, which is Chapter 11's whole subject.

And audit becomes a query. In regulated settings, the question of what informed a decision has an answer that takes seconds, which Chapter 2 argued is a term in the architecture decision itself.

Provenance survives the summariser, or it does not exist

The place provenance is most often lost is compaction, which is why Chapter 7 forbids compacting across a source boundary.

Any stage that rewrites evidence has to carry the identifiers forward. A summary of four documents is a new artifact with four parents, and the parents belong in its metadata. Where a system cannot represent that, the summary should not be produced.

The same applies to answer generation. When the model writes a sentence, the citation should refer to the evidence index it used, and the application resolves the index to a source. Asking the model to reproduce a URL is asking it to recall a string, which is the operation it is least reliable at and the one that produces links that do not resolve.

There is a test worth running on any pipeline that claims to cite. Take fifty answers with citations, resolve every citation mechanically, and check two things: that the target exists, and that the cited passage actually contains the claim. The second check fails more often than teams expect, and it fails hardest where a summariser sat between the evidence and the answer.

Conflicting evidence is the normal case

Real corpora contradict themselves. Two versions of a policy, a wiki page that disagrees with the source of record, a support macro written before a pricing change.

Do not resolve that silently in retrieval. Bring the conflict into the window with its attributes visible, and give the model a stated precedence rule: the system of record beats documentation, the newer effective date beats the older, the customer's own contract beats the general policy.

Where the conflict cannot be resolved by rule, the correct behaviour is usually to say so. An answer that names the disagreement and cites both sources is more useful than a confident pick, and it is the behaviour that builds trust in a system whose corpus is imperfect.

There is a retrieval-side consideration too. Near-duplicate documents crowd the window, since several versions of the same page all match the query. Deduplicate by source and keep the authoritative version plus, at most, one dissenting one, because Chapter 7's distractor argument applies with force to near-identical text.

Permission changes are events, not states

Access control in a retrieval system has a time dimension that ordinary application authorisation does not, because the index is a copy.

When a document's permissions change, the index is wrong until it is updated. A document moved into a restricted folder on Monday is still answerable by everyone until the re-index runs. That window is invisible, and its length is whatever your ingestion schedule happens to be.

Three mitigations, in order of cost. Re-check permissions at read time against the source system for high-sensitivity classes, accepting the latency, which is the only approach that closes the gap entirely. Subscribe to permission-change events from the source and update affected chunks immediately, which is cheaper and covers most cases. Or run a frequent reconciliation for sensitive corpora and a slower one elsewhere, which is the pragmatic default.

Deletion deserves its own path. When a document is deleted or a user's access is revoked, the requirement is usually immediate, and a nightly job does not meet it. Wire deletions and revocations to a synchronous index update, and test that path deliberately, because it is the one that appears in a legal request rather than in a support ticket.

What the fields cost, and what retrofitting costs

The design cost is small and worth stating precisely, because it is usually overestimated during planning and underestimated afterwards.

At index time: three or four extra columns per chunk, populated from the source document. At query time: one predicate in the retrieval call. At assembly: a header line per chunk, costing a handful of tokens. At logging: the identifiers you were already storing.

The retrofit cost is different in kind. Permissions that were never attached require a re-index of the whole corpus, and a re-index is a migration with a bill, as Chapter 6 describes. Provenance that was never kept means historical answers cannot be explained at all, and no amount of later work recovers that.

There is a cheap middle path for a system already in production. Add the fields to the schema now and populate them for newly ingested documents, then backfill the corpus in priority order, starting with whatever is sensitive. Partial provenance is more useful than none, provided the absence is recorded as absence rather than left blank and assumed.

That asymmetry is the argument for doing it on the first day. It is also the reason this chapter sits before the security chapter rather than inside it: these are ordinary data-modelling decisions that happen to have security consequences, and treating them as security work gets them scheduled after the launch.

Chapter summary

Three attributes have to survive from the store into the prompt: where evidence came from, when it was last true, and who may see it. Enforce permissions inside the retrieval query rather than after it, because post-filtering leaks through result counts and timing, breaks ranking within a user's scope, and fails open on any code path that forgets it, while OWASP's 2025 guidance specifically recommends permission-aware vector stores against cross-context leakage in multi-tenant systems. Copy permissions onto chunks at index time, re-copy on every re-chunk, and filter on the end user's identity rather than the service's. Make freshness visible by rendering dates into the chunk header, give the model an explicit recency rule, and store the effective date rather than whichever timestamp the file system offered, since created, modified and effective are three different things. Monitor the age distribution of served evidence, because a jump is how a failing ingestion job announces itself. Keep a source identifier end to end, which makes citations mechanical rather than hallucinated, makes feedback actionable, makes attribution possible and turns audit into a query. Treat contradiction as normal, bringing conflicts into the window with their dates and sources under a stated precedence rule, saying so plainly when no rule resolves it, and deduplicating near-identical versions so they do not crowd the window. And do all of it early, because the design cost is a few columns, a predicate and a header line, while the retrofit cost is a full re-index and a permanent gap in what can be explained about past answers.

Attaching provenance assumes the evidence is honest. Chapter 10 is Poisoned Memory and Untrusted Evidence, which drops that assumption: retrieved text, including your own memory, is attacker-controlled input, and the defences are structural rather than persuasive.