Governance evidence is the recorded account of what an agent declared, what it attempted, which policy applied and what the evaluation concluded, including what could not be determined. Its value lies in gaps and unknowns being recorded explicitly rather than left out.
When an AI agent finishes a task, it usually says what it did. That summary is evidence of what the agent reported. It is not independent evidence that every operation occurred, or that each one produced the effect reported. It is written by the same model that did the work, after the fact, and it can omit a step without any intent to mislead. Independent evidence is something a person other than the agent can examine later, produced as the work happened, by something other than the agent's own account of itself.
The idea is a familiar one. Financial systems keep ledgers rather than relying on a clerk's recollection, and change management keeps the request alongside the change. Governance evidence applies the same habit to a system that chooses its own operations at run time.
A connected account
A list of tool calls is a record of activity. It becomes evidence about governance when each action can be read against the things that give it meaning. Five elements do that work, and each answers a different question.
| Element | The question it answers |
|---|---|
| Agent registration | Which agent identifier was this, and who is its claimed owner? |
| Declared intent and scope | What was it working toward, and which systems did that authorize? |
| Attempted agent actions | What did it try to do, in what order? |
| Policy identity | Which policy applied, and how was it selected? |
| Evaluation findings | What did the comparison conclude, at the moment of each action? |
What connects them is position. Every event belongs to a session, carries a sequence number, and names the event before it. A finding can therefore be traced to the action it concerns, the declaration in force at the time, and the policy that produced it.
What the record contains in Sentience Governor 0.3.2
The following is abridged from a record generated with the released 0.3.2 Claude Code integration, using representative Claude Code hook payloads and a governance profile bound to the agent through a resolution file. No command was executed. The events are genuine Governor output, and the payloads behind them were representative: the events that follow each call were produced from representative post-call payloads, so they show what Governor records when a result returns and say nothing about the outcome of any real command. Identifiers, timestamps and default policy rule identifiers are omitted.
The session continues the coding agent run used in the declared intent entry, and adds one compound shell command at the end.
| Sequence | Event | What it records | Findings |
|---|---|---|---|
| 1 | Agent registered | The agent's identifier, its claimed owner, and how its policy was selected | None |
| 2 | Intent declared | No objective available at session start | Intent missing |
| 3 | Scope asserted | Attempt: shell, shell/process | Unexpected operation, scope mismatch, default intent rule |
| 4, 5 | Context snapshot | Data entered the agent's context, 11 tokens each | Context unclassified, default classification rule |
| 6 | Intent declared | Objective and scope, declared by the agent | None |
| 7 | Scope asserted | Attempt: edit, filesystem | None |
| 8, 10 | Context snapshot | Data entered the context, 16 and 4 tokens | Context unclassified, default classification rule |
| 9 | Memory write attempt | A write to a persistence target, 16 tokens | Write candidate, write unclassified, default memory-write rule |
| 11 | Scope asserted | Attempt: shell, shell/filesystem, classified as a destructive delete | High-consequence operation |
| 12, 13 | Context snapshot | Data entered the context, 8 and 7 tokens | Context unclassified, default classification rule |
| 14 | Scope asserted | Attempt: shell, target shell, classification incomplete | High-consequence operation |
| 15 | Context snapshot | Data entered the context, 12 tokens | Context unclassified, default classification rule |
Findings are given in words. Where a default policy rule was reported alongside an advisory flag, the table names the rule descriptively and omits its identifier.
The first event shows how the record ties the session to a policy:
{
"event_type": "AGENT_REGISTERED",
"event_sequence_number": 1,
"previous_event_id": null,
"pass_through": true,
"profile_fingerprint": "a99fbe0cdb5a",
"payload": {
"agent_id": "claude-code-evidence",
"owner_claim": "dev",
"profile_loaded": true,
"profile_resolution": "bound",
"profile_binding": "claude-code-*"
}
}Every event has the same envelope: an identifier, the event type, the session, a sequence number, the identifier of the previous event, the agent, a timestamp, the payload, the advisory flags and policy violations found, a pass-through marker, and the fingerprint of the governing profile. The fingerprint was identical on all fifteen events. Every event in this record, and every event the released product writes, is marked as passed through: findings are recorded and the call proceeds.
What the record leaves out matters as much. It holds no prompts and no completions. For a shell command it holds the executable name and subcommand of each segment, such as rm or git and status, and not the arguments. For the file edit it holds the target system and not the path or the text. For a tool result it holds the size in tokens and where the data came from, and not the output. The one piece of free text it stores as written is the declared objective.
Attempted, returned, confirmed
Three different things can be true of an operation, and the record speaks to two of them.
| What is established | How the record shows it | What it does not show |
|---|---|---|
| An operation was attempted | A scope event, written before the call, stating the tool, operation type and target | That it ran |
| A result returned to the agent | A context event after the call, with size and provenance | What the result said, or whether it was accurate |
| An effect occurred on the target system | Not recorded | Whether the file was deleted, the row changed, the resource removed |
This is the distinction drawn in the execution boundary entry, seen from the side of the evidence. Confirmation of an effect has to come from the system that was acted on: the filesystem, version control history, a database, a cloud provider's own audit log. Governance evidence and those sources answer different questions and are strongest read together.
Recording what is not known
An account that contains only confident statements is easy to write and hard to trust. Several parts of the record exist to say that something is missing or undetermined.
Missing intent. A session with no objective is not silent about it. The record opens with an intent event whose source is none, flagged as missing, and the actions that follow are evaluated on that basis.
Unknown and incomplete classification. The last action in the example was git status && ./scripts/release.sh. The classifier could read the first segment and not the second, and recorded exactly that:
{
"complete": false,
"destructive": null,
"segments": [
{ "executable": "git", "subcommand": "status",
"effects": [ { "domain": "version_control", "action": "read", "destructive": false } ] },
{ "executable": "./scripts/release.sh",
"effects": [ { "domain": "unknown", "action": "unknown", "destructive": null } ] }
]
}The known effect is kept, the unknown one is named as unknown, and the classification as a whole is marked incomplete. Because the operator's profile in this example treats an unknown effect as high-consequence, the action was flagged for that reason.
Unclassified data. Every context event in the example carries a finding that the data entering the agent's context was unclassified. No classification was supplied, and the record says so instead of assuming the data was harmless.
Governance errors. Capture can fail. Sentience Governor defines an event type for this, covering a capture failure, an unavailable record, a schema violation and a timeout, each with a severity, the stage at which capture degraded, and a statement that the agent continued. Where it can, the error is written to the record. Some failures cannot be: an event that fails validation is reported on the process's error stream and not written, and a record that cannot be written to cannot hold the news of its own failure.
What evidence is for
Investigation. When something goes wrong, the record gives a sequence to reason from: what was declared, what was attempted and in what order, which attempts returned, and what the evaluation said at each step. It narrows the questions that remain for other sources.
Accountability. The fingerprint identifies the profile that was in force, since the same profile content always produces the same fingerprint, and the registration event records how that profile was selected. A fingerprint identifies a policy. It does not independently establish that the record carrying it is intact. The agent identifier and owner in the registration event are likewise recorded as claimed, not verified. The source recorded with a declaration shows whether an integrator or the agent itself stated the objective.
Review. The record is a local file that Sentience Governor's command line tools read: a session can be opened, analyzed for undeclared intent and policy findings, and summarized in one report. An opt-in MCP server exposes the same information to the agent's operator inside the agent's own interface.
Evidence, observability and audit trails
These three are neighbors, and a mature deployment is likely to want all of them.
Agent observability records execution in depth: spans, inputs and outputs, latency, errors, token usage. It is the right tool for understanding how a run unfolded and why it was slow or wrong, and standards such as OpenTelemetry's conventions for generative AI are making that data portable. An observability system can also be instrumented to carry objectives and policy decisions.
An AI audit trail is an organization's durable record of what its AI systems did, kept for later review and attribution. Its value rests on coverage, integrity and provenance, which usually come from where and how it is stored.
Governance evidence is narrower than either. It is organized around a declared reference and an evaluation against it, and it deliberately holds little content. That makes it lighter to keep and easier to share, and it means it cannot replace a trace when the question is what a tool actually returned. The three fit together: governance events can be forwarded to an observability platform or an audit store, and Sentience Governor provides an optional, operator-configured sink for that purpose. Nothing is sent anywhere unless the operator sets it up.
Where the concept stops
Governance evidence supports conclusions. It does not supply them, and four limits should be stated with it.
- It is not tamper-proof. In Sentience Governor the record is a local file, appended to by the integration. Events are linked by identifier and sequence number, which helps reveal an accidental gap. There is no signature or hash chain, and anyone able to write to the file can alter it. Protecting it is the operator's responsibility, through file permissions or by forwarding events to a store with its own integrity controls.
- It covers only what is instrumented. An operation that does not pass through an integration point leaves no event, and the absence of an event is not evidence that nothing happened.
- It does not prove effects. It establishes attempts and returns, not outcomes on the target system.
- It does not judge relevance. The released evaluation compares structured facts with a declared scope and policy. An action inside the scope that does not serve the objective may produce no finding.
Stated with those limits, the record is still worth having. It turns "what did the agent do, and under which rules?" from a question answered by the agent's own summary into one answered by an account written at the time, with its uncertainties left in.