Research·Audit & evidence

Agent work needs evidence, not trust.

Companies approve agents carefully and then run them on faith. The record of what an agent actually did is the product, and most environments never produce it.

The short version

  • Evidence for agent work is the verifiable record of what an agent actually did: which identity ran, which tools it called, with what arguments, under which policy version.
  • Approval happens before the work; evidence exists after it. Most review processes only cover the first half.
  • Session-keyed logs fail for agents: identity by connection breaks under shared gateways, retries and the protocol's move toward statelessness.
  • The loop that scales is: signed policy in, applied in the environment, verified evidence back.

Evidence for agent work is the verifiable record of what an agent actually did: which identity performed the work, which tools it called, with what arguments, what came back, and which policy was in force at that moment. Without it, agent adoption runs on trust and memory, and both run out exactly when you need them, after something went wrong.

Most teams have an approval story. An agent, a tool or an MCP server gets reviewed before it touches production. What almost no team has is the second half: proof of what happened once the approved thing started working.

Approval is before. Evidence is after.

A review answers "should this be allowed to run?" Evidence answers "what did it actually do?" These are different questions, and the gap between them is where agent risk lives. The agent that was approved is not the agent that runs: models change, prompts change, the supply chain underneath it changes, and the agent's own reasoning varies per task.

In assessments, the question we ask that most often goes unanswered is simple: an agent modified something in production three weeks ago; show us which agent, on whose behalf, using which tool, and under what authorization. Teams with mature logging for humans and services routinely cannot answer it for agents.

Why session logs fail for agents

The instinct is to reuse what worked for web services: log the session. For agents this breaks in three places.

Identity by connection is not identity. When several agents reach a server through one gateway or one long-lived connection, the log records a caller, singular. Attribution dies at the first shared hop.

Sessions and work are decoupling. The Model Context Protocol is moving toward stateless operation: tasks that outlive their connection, streams that resume by polling. Work that spans connections cannot be reconstructed from connection logs.

Logs are not verification. A log says what the environment claims happened. On its own it cannot say whether that matches what was authorized. For that you need something to compare against.

An audit trail becomes evidence the moment you can compare it against the policy that was supposed to be in force. Before that, it is just a diary.

What closes the loop

The comparison needs a trustworthy reference, which is why evidence and signed policy are one system, not two features. The loop has three parts.

  1. Signed policy in. What each agent environment may do is declared, versioned and signed, so the reference itself cannot drift or be tampered with silently.
  2. Applied in the environment. Enforcement happens locally and deterministically, with no model deciding what is allowed. The environment records each decision as it happens.
  3. Verified evidence back. The record returns: identity, tool, arguments, disposition, policy version. Verification is a diff between what was assigned and what was reported. Drift, over-reach and gaps show up as findings, not as incidents.

What to record from day one

Five fields per tool call cover most of what an investigation, an auditor or your own postmortem will ask for:

  1. Authenticated identity: which agent instance, not which connection.
  2. On whose behalf: the human or process that delegated the work.
  3. The call: tool, arguments, and result disposition (allowed, reviewed, blocked).
  4. The policy version in force when the decision was made.
  5. A timestamp and sequence that survive retries and deferred results.

Record these per call, not per session, and export them in a standard format your existing tooling can read; we emit SARIF for exactly that reason. The volume is smaller than teams fear: agent tool calls are numerous, but each record is a few hundred bytes of structured data, cheap to keep for years.

agent-env · evidence streamverified
1agent: ci-fixer#a41  for: g.aragon · policy v14 ok
2call: run_tests     args: ./api · allowed   ok
3call: write_file    path outside scope    reviewed
4call: push_deploy   not in policy v14 → blocked
5evidence → verified against assigned policy
Per-call evidence: identity, delegation, decision and policy version, verifiable after the fact.

The takeaway

If agents do company work, the work has to leave a record that stands on its own: per-call, identity-bearing, and verifiable against the policy that authorized it. Trust is how adoption starts. Evidence is how it survives its first incident, its first audit, and its first hard question from the board.


Oktsec Control runs this loop for approved agent environments: signed policy in, applied in the environment, verified evidence back. See Control →