Skip to main content
Panopticore
Evidence

Evidence your auditor, your insurer, and your regulator can verify.

The Evidence Binder is a cryptographically signed, self-contained record of what an agent did, which policies governed it, and whether those policies were enforced. Any third party can verify it offline, without vendor access.

Anatomy

What's inside an Evidence Binder.

Evidence Binder
bnd_8f3a7c... | 2026-04-15T14:32:07Z
Verified

Hover or tap a section to see sample content

Verification

Verify a Binder offline.

binderverify, Panopticore's verification CLI, checks a Binder without contacting any service.

binderverify
$ binderverify --binder binder.json \
    --evidence-signature binder.evidence.dsse --pdf binder.pdf

binder:            binder.json
binder_json_hash:  4e1c09b7d2...
merkle_root:       9f8e7d6c5b...
ledger_root:       3a71c2e8d4...
policy_checksum:   a1b2c3d4e5...
pdf_hash:          77d0f1a9c6...
key_id:            binder-key-v1
signing_time:      2026-04-15T14:32:09Z

It rebuilds the ledger hash chain and Merkle root from the Binder's entries, re-hashes binder.json and the PDF, and checks the ECDSA P-256 signature against the embedded or supplied public key. Any mismatch fails verification.

Chain of custody

How the evidence stays trustworthy.

Event 1 a3f8...
hash(event)
Event 2 7b2e...
hash(prev + event)
Event 3 9f8e...
hash(prev + event)
Root merkle
Binder

Each event links to the previous via cryptographic hash. Break any link and verification fails.

Merkle-linked ledger

Every governance event is recorded in the hash-linked ledger shown above. Sigstore's Rekor transparency log and Certificate Transparency rely on the same Merkle-tree integrity pattern.

Customer-managed keys

All signatures use ECDSA P-256 keys that you control. Panopticore signs with your keys, so the trust root is yours.

Offline verification

binderverify checks a Binder with the signer's public key, with no network connection or vendor account. It stays verifiable through vendor outages, contract termination, and organizational change.

Key rotation

Evidence Binders carry the verification artifacts needed to validate them against the key that was active at signing time. Binders produced before a rotation remain verifiable after the rotation.

Audience

Who uses Evidence Binders.

Internal auditors

Check agent actions against stated policy using evidence the audited system did not produce.

Incident responders

Precise reconstruction of agent behavior during an incident. What was attempted, what was blocked, and the exact policy state at the time.

Legal teams

Tamper-evident, signed records suitable for legal proceedings. The Binder is a self-contained artifact, not a screenshot of a dashboard.

Insurance carriers

The Evidence Binder provides the controls and evidence insurers are increasingly requiring as agentic AI systems take production actions.

Regulators

Verifiable evidence of which governance was in effect, in a form suited to regulatory examination.

External auditors

Verify Binders with binderverify and the signer's public key, without vendor access.

Evidence FAQ

How is an Evidence Binder different from logs?
Logs are operational records produced by the system being observed. They can be modified, deleted, or selectively omitted. An Evidence Binder is a cryptographically signed, self-contained artifact produced by an independent governance layer in a separate trust boundary. It carries its own verification material.
What does tamper-evident mean precisely?
Every entry in the governance ledger is linked to the previous entry through cryptographic hashes. If any entry is modified after recording, the hash chain breaks and verification fails. The Binder carries a Merkle root that can be checked against the ledger, so any tampering is detected.
Can a Binder be subpoenaed?
Yes. Like any other business record, a Binder can be produced in response to legal process, and its signatures prove it has not been altered.
What's included in a Binder by default?
Identity chain, action inventory, policy decisions, approvals, and verification artifacts. Payload data (request/response bodies) is not included by default.
Can payloads be included?
Yes. Policy decides which workflows include payload data and which exclude it.

See the evidence for yourself.

Request early access and we'll walk through a real Evidence Binder with your team.