Context provenance for AI agents: prove what the model actually saw

The amendment existed. The model never saw it.

A software company uses an AI application to decide whether a supplier agreement can renew automatically. The master agreement says 30 days' notice. A later amendment changes that to 90 days whenever regulated customer data is involved.

Retrieval finds both documents. Its log lists the master agreement and Amendment v3 as retrieved sources, and both pass the tenant, legal-entity and document-type checks. Then the application builds the model input. The assembler groups clauses by an internal clause ID, and because the amendment reused the master agreement's ID, a de-duplication rule keeps only one. A summarizer compresses the amendment and drops the regulated-data exception. The remaining context is placed behind conversation memory from an earlier supplier case. The token limit truncates the end.

The model receives the 30-day clause, a stale memory summary and nothing usable from the amendment. It recommends automatic renewal and cites the master agreement.

Every artifact looked reassuring: the source existed, retrieval found it, access allowed it, the answer had a valid citation, and no call failed. What the investigation couldn't answer was the question that mattered: did the model receive the amendment, in what form, in what order, and next to what?

The repository isn't what the model sees

Teams say a model is "grounded in" a database, document set, vector index or knowledge base. That's directionally right, but the model never looks at those systems. It receives a finite, ordered package built by application code: instructions, the user's request, retrieved passages, query results, features, memory, tool results and schemas. And it doesn't receive whatever was left out because of access, freshness, ranking, duplicates, cost or token limits.

So a source can exist in the enterprise and be absent from the model. It can be retrieved and later removed, included but changed beyond recognition, placed under the wrong role, surrounded by conflicting memory, or cut off before the decisive sentence.

What is context provenance?

Context provenance is the record of what information was allowed, considered, selected, transformed, ordered, dropped and finally sent to a model for one decision, under which authority and versions. It covers what the application controlled, not what the model thought.

It's broader than a source list and narrower than a claim about the model's reasoning. It shows what the runtime allowed to shape the decision, rather than what an investigator later assumes did.

Eight stages from source to model

Give each meaningful item (a clause, a feature value, a summary, a memory entry, a tool response) a stable identity at the level where its meaning, authority or lifecycle can change. You don't need to govern every token separately.

Why must eligibility come before ranking?

Because an item can change the outcome just by competing for selection. If access filtering happens after ranking, ineligible content can push eligible evidence out of the top results or the token budget, even though it never appears in the answer.

Many retrieval designs rank globally and filter for permissions afterwards. That prevents direct disclosure but still lets out-of-scope material crowd out what should have been there. The same applies to legal entity, document type, purpose, jurisdiction, freshness, classification, licensing and record state. Apply eligibility at the earliest stage that prevents influence, not just before display, and record each decision: who, for what purpose, under which policy version, with what result. (See permission-aware retrieval.)

What was left out matters too

Most context systems record what was returned. Investigations often turn on what wasn't. In the opening case, the missing exception explains the outcome better than anything that remained.

Record items that were considered but didn't reach the model, with the stage and reason: access or policy denial; out of scope; stale or superseded; low score; top-k, cost or token limits; de-duplication or conflict resolution; lossy summary or redaction; truncation; failed validation.

You don't have to keep every rejected payload forever. For low-stakes paths, identities, scores and reason codes may be enough. For consequential decisions, keep protected snapshots or stronger evidence. Decide the level in advance, per path.

A summary is a new document

Context rarely goes straight from source to model. It's chunked, OCR'd, translated, normalized, redacted, summarized, merged or turned into features. Each step can help, and each can change meaning: a summary drops an exception, OCR misreads a decimal, translation narrows a legal term, a feature uses the wrong time window. A citation to the original doesn't explain the derived item the model actually got.

Treat every derived item as new, linked to its inputs and to the step, version and parameters that produced it. And let it inherit the source's scope: transforming content doesn't widen who may see it or remove its residency and retention rules.

Context is more than retrieved documents

Keep instructions and evidence apart

Models take instructions and data through closely related channels. Documents, emails, web pages and tool results can contain text that looks like an instruction, which is how indirect prompt injection works. If the application doesn't keep each item's source and role, untrusted evidence can be read as a command.

Context provenance doesn't stop prompt injection by itself. It lets the runtime apply stronger controls: mark each item as instruction, user assertion, external evidence, verified fact, memory or tool result; keep roles separate when assembling; restrict which tools are available; and preserve where any influential content came from.

Order, budget and truncation are behavior

A model receives a sequence, not a set. Position, role, repetition, conflict and context-window pressure all affect the result. So record how the final input was rendered: message roles, order, grouping, precedence, token budgets, compression, where truncation cut, and the versions of the prompt template, model, tokenizer and tool schemas. A canonical serialization makes this record easy to hash or sign. It doesn't have to expose raw protected content to every investigator; references, digests and selective snapshots work, with each role seeing what it's allowed to see.

Memory needs the same discipline. A memory entry can outlive the record, role, policy or tenant it came from, then quietly reintroduce something current rules would block. Give memory a source, scope, creation time, expiry and invalidation rules like any other context.

What context provenance can and can't prove

It can show which items were allowed for this run; how candidates were generated, ranked, transformed, ordered and truncated; the exact model input with versions and digests; and the link from that input to the decision, approval and outcome. It supports controlled comparisons: rerun with a different context rule and see whether the result changes.

It can't prove that every visible item changed the output, expose the model's private reasoning, guarantee identical output across providers or hardware, or turn a correlation between source and answer into proof of cause. Saying so plainly makes the record more credible, not less.

The same record makes replay honest. Running today's query against today's index doesn't reconstruct what the model saw last month. Replay needs the stored input record; a rerun with current context is a "what if", not history. (Once the input is recorded, decision lineage carries it through to the outcome.)

Common anti-patterns

Ten rules for context provenance

1. Explain the model's actual input, not the repository.
2. Give every consequential item an identity, revision, role, scope and source.
3. Apply eligibility before items compete for selection.
4. Record what was excluded, where and why.
5. Treat chunking, OCR, translation, redaction and summaries as new, linked items.
6. Include instructions, memory, features, tool results and model output, not only documents.
7. Record order, roles, budgets, truncation and versions in the model input record.
8. Keep instructions and evidence separate; content never assigns its own role.
9. Keep what consequence requires; use references and digests for the rest.
10. Link the model input to the decision, approval and outcome.

The result: evidence of what shaped the outcome

An AI application's quality depends not just on the model or the data, but on what crosses into the model's input. Eligibility, competition between candidates, transformation, memory, order, token limits and omissions all shape behavior.

Context provenance turns an invisible prompt-building process into a versioned record you can govern, audit, compare and replay. You don't need to keep every token forever. You do need a defensible record of what was allowed to shape the outcome and how it became the input the model actually received.