Preparing agent audit evidence for SOC 2

Autonomous agents used to be the paragraph companies buried in their system description and hoped the auditor skimmed. It doesn't have to go that way. Agents governed by govern.sh produce evidence that is stronger than what most human processes generate — complete, signed, and independently verifiable. This guide maps that evidence to the SOC 2 controls where auditors look for it, and walks through assembling an export package your auditor can check themselves.

Map agents into your control language

Auditors evaluate controls, not features, so the first task is translation. Present each agent as a non-human identity in your access-control narrative, with its passport as the identity record and its policy as the documented access grant. The mapping below covers the Trust Services Criteria that agent activity most commonly touches.

• CC6.1 (logical access): each agent holds a unique Ed25519 identity; no shared credentials. Evidence: passport registry export listing every agent, owner, key fingerprint, and status.
• CC6.2–6.3 (provisioning and revocation): passport mint and revoke events are themselves receipted. Evidence: lifecycle receipts showing who created each agent and when access was removed.
• CC7.2 (monitoring for anomalies): budget runway alerts and health scores demonstrate ongoing monitoring of non-human activity. Evidence: alert configuration plus fired-alert history for the audit period.
• CC8.1 (change management): policies are versioned, and every receipt cites the version that judged it. Evidence: policy version history with diffs and reviewer identity.
• PI1 / availability, where in scope: enforcement uptime and decision latency reports from the status page.

Establish the period-of-record export

For a Type II report you need evidence spanning the whole review period, not a point-in-time screenshot. Export the receipt chain for the period once, early in fieldwork, and hand your auditor the same bundle you keep — the signatures make 'same' provable. Exports are line-delimited JSON plus the public keys needed to verify them, and they remain verifiable outside govern.sh entirely.

# Export the full chain for the review period
$ govern receipts export \
    --from 2025-11-01 --to 2026-04-30 \
    --out soc2-fy26-receipts.jsonl \
    --include-keys workspace-keys.json

Exported 4,812,930 receipts (2.1 GB), chain head sha256:44e1a9...
Anchor references: 574 transparency-log entries included.

Let the auditor verify, not trust

This is the step that changes the meeting. Instead of asserting your logs are complete, give the auditor the open-source verifier and let them establish it themselves: the tool recomputes every hash link, validates every signature, confirms sequence continuity (so deletions are impossible to hide), and matches chain heads against the external transparency log. It runs offline. Completeness and integrity of the population — normally the hardest thing to demonstrate for automated activity — becomes a ten-minute check the auditor performs on their own machine.

$ govern verify --bundle soc2-fy26-receipts.jsonl --keys workspace-keys.json
  hash chain      OK (0 breaks)
  signatures      OK (4,812,930 valid)
  sequence        OK (contiguous, no gaps)
  anchors         OK (574 of 574 match transparency log)
VERIFIED — population is complete and untampered for the stated period.

Pre-build the walkthrough samples

Fieldwork always includes sampling: the auditor picks transactions and asks you to trace them. Prepare three sample narratives in advance, each a chain of receipts telling one story end to end. A routine allowed action (policy evaluated, allowed, executed, receipted). A held action (policy triggered hold, named human approved in Slack, approval receipt chained to execution receipt). And a denial (out-of-scope call refused before execution). The denial sample is quietly the most persuasive — it's direct evidence the control operates, not just that it exists.

Close the recurring gaps early

• Orphaned agents: run the access review before the auditor asks. Any passport whose owner has left or whose last action predates the period should be revoked, with the revocation receipt as evidence of the review operating.
• Approval-rate red flags: a rule with a 100% approval rate over thousands of holds will draw a question about rubber-stamping. Tune thresholds before fieldwork, and bring the tuning history — it demonstrates the control improving.
• Retention alignment: confirm your audit retention setting covers the full review period plus the report issuance window. Type II periods have been sunk by 90-day retention defaults.
• Subservice clarity: decide with your auditor whether govern.sh is a subservice organization in your system description, and reference our SOC 2 report (available under NDA) using the inclusive or carve-out method accordingly.

Teams that follow this playbook consistently report the same outcome: the agent section of the audit gets shorter every year, because it's the part where evidence arrives complete and checks itself. Governance you can hand to a skeptic is the difference between agents being your audit's asterisk and being its exhibit A.