At 16:18, Claude Code reported that it had enabled a feature flag for one tenant, verified the change, and closed the task.

The transcript looked tidy:

16:18:02  requested flag update
16:18:03  tool returned success
16:18:05  read-back confirmed enabled
16:18:07  task complete

During the incident review, an engineer asked which delegated role had approved the change. The transcript did not say. The tool response carried no policy version. Its read-back came from the same cache used by the writer. A later rollback note said restored, but nothing recorded the final value in the system of record.

The team had a story of the run. It did not have proof of the effect.

All identifiers and records in this article are fictional examples.

Independent evidence packet for a Claude Code agent effect

Split the transcript into claims

A transcript blends several claims into one narrative. Pull them apart before deciding that a production action is safe:

CLAIM 1  The operation had a stable identity.
CLAIM 2  The principal had authority at execution time.
CLAIM 3  The intended effect reached durable state.
CLAIM 4  An independent read observed the expected result.
CLAIM 5  Rollback or cleanup left no unresolved state.

Each claim needs evidence from the component that can know it. Claude Code can report what it requested. It cannot certify the gateway’s permission decision or the database’s durable state by repeating a tool response.

This is the same reason parallel writes need a stable operation identity. Identity tells us which intended effect we are discussing. It does not tell us whether that effect was allowed or whether it committed.

Get authority evidence from the enforcement point

The authority record should come from the gateway that applies policy, not from the assistant transcript.

authority_receipt:
  principal_id: agent-example-14
  delegated_role: release-operator
  tenant_id: tenant-example-green
  operation_id: op-example-904
  effect_hash: sha256:example-effect
  policy_version: policy-example-52
  approval_id: approval-example-27
  checked_at: 2026-09-09T16:18:02Z
  decision: allow
  valid_until: 2026-09-09T16:20:00Z

This binds the principal, tenant, operation, effect, policy, and approval to one decision. A generic permission: allowed field leaves room for a retry or altered payload to inherit authority it never received.

Time belongs in the receipt because permission can disappear while work waits. The previous article showed how an approved MCP write can run after its permission expires. The worker must evaluate authority close to the effect, using the current clock and policy state.

For teams designing the wider control model, Securing Enterprise AI Agents covers the identity, policy, approval, and audit controls around that enforcement decision.

Prove the committed effect separately

A successful tool response can mean accepted, queued, committed, or handed to another service. The effect receipt should say which one occurred.

effect_receipt:
  operation_id: op-example-904
  intended_effect_hash: sha256:example-effect
  system_of_record: feature-store-example
  resource_id: flag-example-31
  previous_version: 118
  committed_version: 119
  committed_value_hash: sha256:example-value
  committed_at: 2026-09-09T16:18:04Z
  durability: committed

This receipt does not replace the authority record. A durable change can still be unauthorized. The review packet needs both.

The distinction between acceptance and commitment deserves an explicit protocol. A recent example shows why a success receipt issued before durability is unsafe. If the system cannot prove a committed version, the effect remains unresolved rather than successful.

Verify through an independent read path

Reading through the writer’s cache can make a failed or partial operation look complete. Verification should use an authoritative read path, or another source with known consistency semantics.

observation_receipt:
  operation_id: op-example-904
  observed_by: verifier-example-03
  read_path: feature-store-primary
  observed_version: 119
  observed_value_hash: sha256:example-value
  observed_at: 2026-09-09T16:18:06Z
  matches_intended_effect: true

Keep the verifier separate from the write adapter when the consequence justifies it. If both paths share the same cache, credentials, and code, the second read may only repeat the first component’s mistake.

Eventually consistent systems need a deadline and a named intermediate state. Not visible yet is neither success nor failure. Record when the authoritative value must appear, then stop automatic retries until the system knows whether the original write committed.

State what the trace could not see

Replay is useful, but only for events the trace captured. A deterministic replay of an incomplete trace remains incomplete.

trace_coverage:
  prompt_captured: true
  tool_request_captured: true
  gateway_decision_captured: true
  downstream_commit_captured: true
  authoritative_read_captured: true
  network_egress_captured: false
  secrets_redacted: true
  omitted_fields:
    - raw_access_token
  unresolved_blind_spots:
    - side effects outside registered MCP gateways

A coverage record prevents replayable from becoming a vague quality label. It names the evidence available to the reviewer and the paths that remain outside observation.

This also changes how you handle redaction. Removing a secret can be necessary, but the trace should preserve the fact that a field existed, its classification, and why it was omitted. Otherwise a reviewer cannot distinguish safe redaction from missing telemetry.

Give rollback its own evidence

A rollback request is another external effect. It needs identity, authority, commit, observation, and cleanup evidence of its own.

cleanup_receipt:
  rollback_operation_id: op-example-905
  reverses_operation_id: op-example-904
  restored_version: 120
  restored_value_hash: sha256:example-original
  independently_observed: true
  unresolved_effects: []
  completed_at: 2026-09-09T16:24:11Z

Do not close an incident because Claude Code said it restored the flag. Close it when the system of record and the independent observer agree, and when the packet lists no unresolved effects.

This is where queued retries often cause trouble. A value can be restored while an old write remains ready to execute again. The cleanup receipt should cover delayed work, temporary credentials, locks, files, and messages created by the original run.

Assemble references, not a polished story

The final packet should reference immutable records instead of copying their claims into prose.

agent_effect_evidence_packet:
  packet_version: "1.0"
  run_id: run-example-62
  operation_id: op-example-904
  transcript_ref: trace-example-62
  authority_receipt_ref: auth-example-27
  effect_receipt_ref: effect-example-119
  observation_receipt_ref: observe-example-119
  cleanup_receipt_ref: cleanup-example-120
  trace_coverage_ref: coverage-example-62
  evidence_status: complete
  unresolved_effects: []
  reviewer_decision: accepted

Hash or sign the packet and its referenced records. Use a known clock source. A reviewer should be able to detect a missing or replaced receipt without trusting the agent that assembled the packet.

If your team owns both the engineering runtime and the authority model around it, the Enterprise AI Agents in Production bundle connects the implementation path with the security evidence.

Turn the incident into eval fixtures

A good eval fails when one claim lacks independent evidence. Start with the cases that would have exposed this incident:

  1. The transcript says success, but the authority receipt is missing.
  2. The receipt allows one tenant while the effect lands in another.
  3. The tool returns success without a durable version.
  4. The read-back uses a stale cache.
  5. The trace omits a downstream call.
  6. Rollback restores the value but leaves a queued retry alive.
  7. The packet references a receipt whose hash no longer matches.
  8. Replay reproduces the transcript but not the original policy version.

Assert on external state and receipt integrity. Matching the assistant’s final message only tests whether it can tell the expected story.

My acceptance rule is deliberately blunt: treat the transcript as one witness. Require independent records for identity, authority, durable effect, observation, and cleanup before accepting the run.

Claude Code: Building Production Agents That Actually Scale shows how to bound MCP tools and turn agent runs into reviewable engineering evidence for teams moving beyond demos.