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
Identity Chain
|Principal: agent-copilot-prod-01
|Session: ses_7f2a91c3
|Auth: mTLS (URI SAN verified)
|Token: DSSE v1, signed 14:32:07Z
Action Inventory
|GET /api/users/export → BLOCKED
|POST /api/reports/summary → ALLOWED
|PUT /api/config/update → APPROVED
Policy Decisions
|Policy: prod-data-egress v2.4.1
|Rule: deny outbound PII export
|Bundle: sha256:a1b2c3d4e5...
Approvals
|Scope: config/update (single-use)
|Token: signed, valid at exec time
Verification Artifacts
|Signature: ECDSA P-256 (valid)
|Merkle root: 9f8e7d6c5b...
|Ledger link: block #48,291

Hover each section to see sample content

Verification

Verify it yourself.

The Evidence Binder is designed to be verified by anyone, anywhere, without vendor access.

binderverify
$ binderverify --input binder.pdf --pubkey key.pem

 signature valid (ECDSA P-256)
 merkle root matches ledger
 policy bundle checksum matches
 approval token signature valid
 timestamp within session window

Binder ID:    bnd_8f3a7c...
Session:      2026-04-15T14:32:07Z — 2026-04-15T14:32:09Z
Principal:    agent-copilot-prod-01
Actions:      3 attempted, 2 executed, 1 blocked
Policy:       v2.4.1 (sha256:a1b2c3...)
Verdict:      VERIFIED

No dashboard login. No API call. No vendor dependency. The Binder carries everything needed to prove its own integrity.

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 a tamper-evident ledger. Each entry is linked to the previous one through cryptographic hashes, forming a chain. If any entry is modified after the fact, the chain breaks and verification fails. This is the same integrity pattern used in supply chain security frameworks like SLSA and in-toto.

Customer-managed keys

All signatures use ECDSA P-256 keys that you control. Panopticore signs with your keys, not vendor-owned material. You control the trust root.

Offline verification

A Binder can be verified with the public key and the binderverify tool. No network connection. No API call. No vendor account. The evidence survives 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

Independent verification of agent actions against stated policy. No reliance on the system being audited to produce its own evidence.

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

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

Regulators

Standardized, verifiable evidence of governance in effect. Independent of vendor claims. Suitable for regulatory examination.

External auditors

Third-party verification without vendor access. The public key and binderverify tool are all that's needed.

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. Logs tell you what the system reported. A Binder proves what actually happened.
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. Tamper-evident does not mean tamper-proof (nothing is), but it means tampering is detectable.
What happens when signing keys rotate?
Binders carry the verification artifacts needed to validate them against the key that was active at signing time. A Binder produced under key A remains verifiable after key B is installed. Key rotation does not invalidate historical evidence.
Can a Binder be subpoenaed?
An Evidence Binder is a document. It can be produced in response to legal process like any other business record. Its cryptographic signatures provide authenticity guarantees that strengthen its evidentiary value.
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. Payload capture is configurable and policy-driven.
Can payloads be included?
Yes. Payload capture is policy-driven. You can configure which workflows include payload data and which exclude it. This lets you balance compliance evidence requirements against privacy constraints.

See the evidence for yourself.

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