Proving which version of an agent took an action
Knowing that "the agent did something" is incomplete if you cannot show which version of the agent did it. Configuration provenance is the practice of fingerprinting the material configuration at action time and storing that fingerprint with each event, so a reader can later ask: was this the January playbook or the March playbook? Were refunds in the tool allowlist that day? Without provenance, contradictory behaviours can hide under one agent name.
What belongs in a fingerprint
A useful fingerprint captures anything that could change behaviour if edited silently. Typical components include:
- Model or runtime identifier
- Tool allowlist, or a hash of it
- Playbook, policy, or workflow version
- Decision-rights or authority rules version
- Deployment identifiers where available: git commit SHA, container image digest, workflow version, MCP server version
Secrets, credentials, and raw prompts do not belong in the chain. Hash prompts client-side and send the digest. For environment variables that look like secrets, record the variable name and whether it was present or absent, never the value.
Proofroom assigns no semantic meaning to component names. Senders define the map; the platform canonicalises and hashes it.
When the fingerprint must change
Any change that could alter behaviour should produce a new fingerprint before further material actions are recorded. Silent edits destroy provenance: two receipts under the same agent name might then reflect incompatible configurations with no signal in the trail.
Material configuration changes should emit an explicit configuration-changed style event with old and new fingerprints, so the transition is visible rather than implied.
Provenance levels (how the fingerprint was supplied)
Proofroom renders how the fingerprint was provided, separate from evidence levels on individual actions:
| Level | Meaning |
|---|---|
not_declared |
Nothing sent. Honest default. No coverage points for configuration. |
self_declared |
Sender supplied a version string or opaque hash without structured components. |
computed |
Sender supplied structured components; Proofroom computed the canonical hash from them. |
externally_anchored |
At least one component is an external identifier that can be checked against its source system (for example a git commit SHA, container image digest, or deployment ID). |
A fingerprint always records what was declared at capture time. A self-declared fingerprint does not, by itself, show that the declared configuration is what actually ran. Externally anchored identifiers, when checked against their source, approach stronger linkage between record and reality.
How the fingerprint is computed
Components form a flat map of sender-defined names to short values or hashes. Proofroom sorts keys lexicographically, JSON-serialises the map, and SHA-256 digests the result. That digest is the fingerprint. On each run, the platform compares it with the last recorded fingerprint for the use case. Any difference emits a configuration_changed Action Receipt with both fingerprints.
Per-event records carry the fingerprint active at that moment, so a single receipt can be checked offline without the full database.
How readers use provenance
Given an Action Receipt or log line, a reader should be able to answer:
- Which playbook version was in force?
- Which model and tool set were declared?
- Did configuration change between two related actions?
Pair fingerprints with integrity of the event store. Provenance shows what was asserted; tamper-evident linking shows the assertion was not altered after write. Neither substitutes for the other.
Limits
Configuration provenance does not prove the hosting environment was untampered. It does not rule out undocumented side channels, manual overrides, or tools invoked outside the declared allowlist. It binds the record to a declared configuration snapshot, not to a full formal proof of runtime state.
For governance questions about who accepted a specific action, see evidence levels. For questions about unlogged activity, see absence of evidence.
How Proofroom approaches this
Proofroom records configuration as opaque fingerprints supplied by senders. The platform does not need to understand your stack's internals: you send component names and values, or a precomputed hash, and change detection is sealed in the hash chain.
Public proof rooms show fingerprint digests and component names at Tier 1 visibility. Full component values are available at reviewer tier. Secrets never enter the chain.
Coverage scoring awards up to five points for configuration provenance: zero for not_declared, two for self_declared, four for computed, five for externally_anchored. The score describes structural completeness, not runtime fidelity.
Proofroom's own internal agents send structured components including commit_sha, playbook, decision_rights, runtime_config, and integrations, and therefore render at externally_anchored. That demonstrates the generic model; it is not a special case in the product.
Typical stacks:
| Stack | Typical components |
|---|---|
| LangGraph / CrewAI / custom | system_prompt (hash), model, tools |
| Zapier / n8n | workflow_id, workflow_version |
| Containerised | image_digest |
| MCP servers | mcp_server_version |
| Git-deployed | commit_sha |
Send configuration components with evidence events via HTTP or MCP. See MCP integration for tool reference.