Your agent run needs an audit receipt, not a longer prompt

A longer prompt does not fix thin evidence. A small receipt makes the run say what it checked, what it skipped, and where the audit is incomplete.

Most agent workflow failures do not look dramatic.

They look like this:

• the agent says the PR is fine but never checked the risky file
• the tool-call log exists but does not prove the hook fired for subagents
• the audit log is hash-chained but the payload was redacted or truncated
• the final answer says "done" but the run skipped the one check you cared about

The missing piece is usually a small receipt at the end of the run.

What I mean by receipt

Not a certificate. Not a full audit system. Just a structured end-of-run claim:

subject: what was checked
scope: what was in and out
checks_run: what the agent actually did
checks_skipped: what it did not do
evidence: files, commands, logs, or rows inspected
coverage_gap: why evidence may be incomplete
verdict: pass | fail | incomplete

The important word is incomplete.

Without it, a clean-looking result can hide thin evidence.

Example: tool-call audit logs

Say an MCP host stores every tool invocation. It is tempting to treat the existence of an audit row as proof. But there are at least three different claims hiding inside that row:

outcome: ok | rejected | error
redaction_state: full | sanitized | truncated | omitted
audit_coverage: complete | partial | unobservable

Those are not the same thing.

A failed tool call can still be audit-complete. A successful tool call can be audit-incomplete if the arguments were omitted, the output was truncated, or a subagent path never emitted events.

Example: passive sensitive-file traces

Passive audit tools need the same honesty. Seeing cat .env in command text is a useful risk signal, but it is not the same as proving a file was opened and fully captured.

sensitive_path_match: true | false
sensitivity_class: dotenv | ssh_key | cloud_creds | browser_profile | custom
access_operation: read | write | stat | list | unknown
redaction_state: applied | not_needed | not_available | failed
audit_coverage: complete | partial | unobservable
coverage_gap: command_text_only | stdout_truncated | path_unresolved | hook_missing_file_event

The receipt should be allowed to say "sensitive intent observed, file access not proven." That is more useful than a confident green check.

Example: hash-chained logs

Hash chains are useful. They help prove order and tamper evidence.

They do not prove that the log row contains enough evidence.

evidence_mode: full | redacted | metadata_only | unavailable
input_seen: true | false
output_seen: true | false
coverage_gap: actor_unverified | payload_redacted | output_truncated | write_failed
audit_verdict: pass | fail | incomplete

That way a row can be tamper-evident and still honestly say: "this is not enough to call the run clean."

Example: PR review agents

For PR review, the receipt can be very small:

files_reviewed:
  - src/payments/checkout.ts
  - tests/checkout.test.ts

checks_run:
  - inspected changed behavior
  - checked error paths
  - checked tests touched by the diff

not_checked:
  - production payment gateway behavior
  - browser compatibility

verdict: incomplete
reason: tests were inspected but not executed locally

This is better than a confident paragraph.

It gives a human reviewer a handle. They can decide whether the missing evidence matters.

A good receipt is boring

The receipt should not be clever. It should make it harder for the agent to overclaim.

My current rule of thumb:

• if the agent cannot name what it checked, it did not check it
• if the evidence was redacted or truncated, say so
• if the runtime cannot observe a class of events, mark the audit incomplete
• if the work is one-off, do not build a framework around it

The best receipt is usually a small text or JSON block that your team can read without learning a new tool.