When a regulator, internal auditor, or board risk committee asks "show me that this agent is governed," what you hand them matters. Screenshots of a dashboard don't survive rotation in personnel; spreadsheets don't carry cryptographic provenance; a 200-page PDF nobody can verify is worse than nothing.
The artefact the question demands is an evidence pack: a single, signed, machine-verifiable document that captures everything about a single governance episode for a single agent or fleet.
The minimum contents
A regulator-grade evidence pack should contain, at minimum:
1. Agent scope
- —Agent identifier, owner, business function, deployment environment.
- —Tools available to the agent, with current IAM scope.
- —Memory bindings (conversation, long-term, vector store identifiers).
- —Identity boundaries (which credentials the agent operates under).
- —Data access paths and the data classification of each.
- —Framework / runtime (LangGraph, AgentCore, MCP, custom).
2. Assessment summary
- —Assessment date and probe-library version.
- —Coverage statement — which OWASP ASI01–10 categories were exercised, with probe counts.
- —AIVSS score (0–100) + per-ASI sub-scores + severity band.
- —Tier classification (T1/T2/T3/T4) and the AARS factor breakdown.
3. Findings (machine-readable)
- —One entry per failing probe: id, ASI category, MITRE ATLAS technique, CSA Agentic RT category.
- —Severity, confidence, AIVSS contribution.
- —Trigger prompt (full, not truncated).
- —Target response (full).
- —Judge verdict + reasoning.
- —Reproducer — a self-contained probe that re-fires the finding against the agent.
- —Remediation guidance — concrete steps to address the finding, with the affected code/policy surface.
4. Attack transcript
Every adversarial turn the assessment fired — prompt, response, judge verdict, confidence — not just the failing ones. This is what lets a reviewer answer the question "what was tried, and what did the agent do?"
5. Runtime policy decisions
- —Cedar (or equivalent) policy text in effect during the assessment.
- —Decisions recorded — allow, deny, gate-to-human — with counts.
- —Any exceptions in effect, with approver identity and expiry.
6. Approval records
Every human-approved action during the period: who approved, what they approved, what was visible to them at the time, and the cryptographic identity proof of the approval.
7. Framework mapping appendix
The pack maps each finding and control clause-by-clause to whichever frameworks the customer operates under — EU AI Act Title III, NIST AI RMF MANAGE/MEASURE, ISO/IEC 42001 controls, plus regional regulators (MAS AIRG, APRA CPS 230 + 234, RBI FREE-AI, OJK Tata Kelola, BNM RMiT, BSP Project Sapiens).
8. Verification manifest
- —Cryptographic signature (ECDSA-P384) of the entire pack under a per-tenant KMS key.
- —RFC 3161 timestamp from at least two independent TSAs (DigiCert + GlobalSign).
- —Hash-chain anchor pointing into a daily root stored under S3 Object Lock Compliance.
- —Verifier instructions — how to verify the pack offline with the AgentGuardian Verifier CLI.
Why the format matters
PDF/A-3 with PAdES-LTA Level signatures is the right format for the human-readable artefact: archival-grade, long-term signature validity, the auditor's PDF reader can verify the signature without an internet connection. JSON sidecar is the right format for the machine-readable artefact: it lets compliance tooling diff packs across quarters and feed them into GRC systems.
Both files are signed under the same per-tenant ECDSA-P384 key. The signature is on the canonical hash of both files, so detecting tampering doesn't require parsing PDF internals.
Three properties to insist on
Verifiable without us
The recipient should be able to verify the pack with a public-key checker, an RFC 3161 verifier, and an Object Lock retention check. They should not have to call the vendor. We ship a Verifier CLI; the verification is offline.
Tamper-evident
The hash chain anchors daily into S3 Object Lock Compliance. Any modification after the fact breaks the chain. Compliance mode means even our own root keys can't delete or alter the archive.
Reproducible
Every finding ships with a self-contained probe. Anyone with access to the agent can re-fire the probe and confirm the finding (or, after remediation, confirm the fix). This is what turns "the security team said it was bad" into "here is the test that fails, and here is the same test passing after the fix."
The job ends when someone outside your team can verify what you produced. That is the bar.
Sample packs (with redacted customer data) are available on request. The verification flow takes about three minutes if you've never run it before.