Independent Verification Overview

Export it. Run our verifier. Detect tampering across the full permit lifecycle without requiring access to Keel’s internal systems.

This playbook is for security and compliance reviewers who want to validate Keel’s audit evidence before procurement, during an incident, or during a periodic audit. You do not need Keel-internal access. You need the export artifacts, the public key manifest, and the standalone verifier.

What independent verification proves

Independent verification proves that the artifact you hold is internally consistent under the cryptographic evidence Keel published with it.

For a signed export, you verify:

• the export bundle’s SHA-256 digest matches the digest recorded in the export manifest;
• the export manifest’s Ed25519 signature validates under the expected export-signing key;
• bundled governance chain entries recompute to their recorded hashes when you run --walk-events;
• adjacent bundled chain entries point to each other in sequence order;
• permit closure records carry valid Ed25519 signatures when you run --verify-closure;
• closure dispatch request digests match the Phase A request body bytes binding when the export carries closure v2 evidence;
• closure records agree with provider-response and client-delivery digest evidence inside the bundled chain entries.

This is stronger than trusting a dashboard status. You are checking the export locally, with published verification material.

What independent verification does NOT prove

The verifier proves exported evidence has not been altered after signing. Like any signing system, the trust boundary includes the signer at signing-time. Defending against privileged signing-time manipulation requires a higher-assurance signing architecture beyond the scope of this verifier.

The verifier detects modification after signing, broken chain continuity inside the exported window, invalid closure signatures, and digest disagreement among the records included in your bundle. It does not prove that a compromised writer could not have signed false evidence before the export was created.

That is the writer-at-signing-time trust boundary. If your threat model requires protection from a compromised writer at the moment evidence is produced, treat that as a separate TEE-backed or HSM-backed attestation requirement. The current verifier does not make that claim.

The verifier also does not prove:

• that the export includes every record that should exist;
• that a record’s business decision was correct;
• that the provider behaved correctly;
• that Keel meets a particular regulatory control by itself;
• that your own downstream handling of the export preserved chain of custody.

Your audit conclusion should say exactly what was verified: artifact integrity, chain walk consistency, and closure evidence consistency for the supplied bundle.

When to run the verifier

Run the verifier during security review.

Ask Keel or your Keel admin for a signed export that includes chain entries. Run verification yourself before relying on any claim about tamper evidence.

Run the verifier during incident response.

If you are investigating a disputed permit, a provider response, or a suspected audit-integrity issue, request an incident-scoped export and verify it before analysis. Preserve the original files and command output.

Run the verifier during periodic compliance audit.

For SOC 2, HIPAA Security Rule, ISO 42001, NIST CSF, or internal AI-governance review, run the verifier against a time-boxed sample export. Keep the verifier version, key manifest, command, and output in your audit file.

What you’ll need

You need three artifacts:

You also need one verifier:

• the keel-verify CLI binary or pip-installable script; or
• a clone of the published verifier repository if your review process requires inspecting or pinning the verifier distribution.

For the exact command sequence, see Running Keel Verify. For every tamper-detection code emitted by the current verifier, see Tampering Detection Matrix.