A source provenance register lists every source an AI agent may draw on, who owns it, which provenance class its facts carry (sealed, signed, declared or external), how fresh it must be, and what actions it may support. Copy the template below, start with one agent's sources, and add each new agent as it is briefed.
Why keep a provenance register?
An agent's answer is only as trustworthy as the fact it rests on. A balance read from the core ledger and a balance typed by a customer into a chat can look identical inside the agent's context. The register is how you keep them apart, so that the operating system can treat them differently at the moment of action.
The practical rule it supports: what a fact is allowed to authorise depends on where it came from. A customer's stated income can start a conversation; it cannot approve a loan. An emailed instruction can open a case; it cannot release a payment. The definitions behind the classes are covered in what a provenance class means for AI agents.
The register is one of the records that make a governed agentic operating system auditable. It pairs with the AI agent inventory register template: one lists your agents, this one lists what they read.
How do you assign a provenance class?
Use four classes and assign each source the lowest one it can defend.
- Sealed. Issued by the system of record itself and tamper-evident: ledger entries, settlement records, the policy library at a fixed version.
- Signed. A named, identifiable party answers for it: a verified issuer's document, a counterparty's confirmation, a verified identity result.
- Declared. Statements made by a customer or counterparty and not yet checked. The short guide to what a declared source means for AI agents covers the edge cases.
- External. Anything from outside your control that has not been verified: emails, web pages, uploaded documents, messages claiming to be from a partner.
If you are unsure between two classes, choose the lower. You can raise a class later with a recorded verification step; you cannot easily undo an action taken on an overrated fact. The mechanics of attaching the stamp are in how to stamp the sources an AI agent uses with provenance.
The source provenance register template
| Field | Guidance |
|---|---|
| Source ID | Stable reference, such as S-014 |
| Source name | What people call it |
| System of origin | Where the data physically comes from |
| Owner | Named person responsible for its accuracy |
| Provenance class | Sealed, signed, declared or external |
| Agents using it | Which agents, and for which capabilities |
| May support | What actions a fact from this source may justify on its own |
| May not support | Actions it must never justify alone |
| Upgrade path | The check that raises a fact to a higher class, if any |
| Freshness | How old a fact may be before the agent must re-read it |
| Version control | How changes to the source are versioned (sealed sources) |
| Review date | When the entry was last confirmed |
The two "support" columns are the heart of the register. They turn a label into a rule the platform can enforce. They also feed the platform guardrails register, where the absolute rules live.
A filled sample: a consumer lending team
| Source ID | Source name | Class | May support | May not support | Upgrade path | Freshness |
|---|---|---|---|---|---|---|
| S-001 | Lending policy v7 | Sealed | Explaining criteria; refusing out-of-policy requests | Exceptions to policy | None | Current version only |
| S-002 | Loan ledger | Sealed | Quoting balances and arrears; drafting statements | Writing off a balance | None | Read at time of use |
| S-003 | Applicant's stated income | Declared | Pre-filling the application; flagging for evidence | Affordability decision | Matched to bank statement data with consent | Session only |
| S-004 | Uploaded payslip | External | Prompting the agent to request verification | Any credit decision | Verified against employer or bank data | 30 days |
| S-005 | Email from a broker | External | Opening a case | Changing application details or payee | Confirmed through the broker's registered channel | Session only |
Each row also carries an owner, the agents that use it and a review date in the full register.
Look at S-004. An uploaded payslip feels like evidence, which is exactly why it needs to be written down as external until checked. A forged document reads the same as a real one.
How often should the register be reviewed?
Review an entry whenever its source changes system, owner or format, and confirm the whole register at least every quarter. Any new agent brief should be checked against it before certification: if the brief cites a source that is not in the register, the source is added and classed first.
Questions people ask
Can one source carry more than one class?
Yes, at field level. A customer record may hold a sealed account number and a declared phone number. Register the fields separately where the class differs, because the agent needs to know which part of the record it can rely on.
Who should own the provenance register?
Usually data governance or the risk function, with each source owned by the person accountable for that data. The register owner keeps it complete; the source owners keep it accurate.
Does a higher class mean the fact is true?
No. It means you know where it came from and who answers for it. A sealed ledger entry can still be wrong, but the error is traceable and someone owns the correction.