Signed Exports

Signed exports are a Business+ feature. When your deployment has a signing key configured, every compliance export you request carries an Ed25519 manifest alongside the export payload.

Requesting a signed export

Use the compliance export surface:


POST /v1/compliance/exports
GET  /v1/compliance/exports
GET  /v1/compliance/exports/{id}

All three routes are GA. When the deployment has a signing key configured, exports include a manifest file automatically — no extra parameter is needed. (Operator setup details are part of the deployment guide rather than this public page.)

See Route Guarantees for the full trust properties of the compliance surface.

Export types

The export_type field on the request determines the bundle contents. All export types are available on Business plans and above when a signing key is configured.

`export_type`	Bundle contents
`governance_events`	Governance event rows with their chain integrity metadata. Supports jsonl, json, and csv formats.
`usage`	Usage log rows.
`permits`	Permit rows.
`full_audit`	Permits with linked evidence, usage records, and replay summaries.
`soc2_evidence`	Sectioned jsonl bundle: summary, active_policy, policy_change, permit_sample, and governance_event records scoped to the requested window.
`hipaa_audit`	Sectioned jsonl bundle including permits, governed_requests, usage_ledgers, governance_decision_snapshots, permit_attestations, and execution lifecycle records.
`vanta_evidence`	Decision-centric JSON bundle for external compliance tooling ingestion. Must use `format: "json"`.
`financial_reconciliation`	Usage and billing reconciliation rows over the requested window. See Reconciliation for the pillar this export packages.
`access_review`	Signed zip of CSVs covering users, organization members, team members, API keys, provider keys, and approver groups. Raw key material and key hashes are never included.
`incident_evidence`	Signed zip with `governance_events.jsonl` (chain metadata intact), `permits.jsonl`, `admin_actions.jsonl`, `bracket_checkpoints.json` (the last externally-anchored checkpoint before the incident window and the first after it), and `incident_metadata.json`. The bracket pair provides forward and backward tamper-evidence for the incident window.

Every export type uses the same Ed25519 manifest and verifier flow. Per-bundle structural differences (sectioned jsonl, signed zip of CSVs, etc.) do not change the verification model.

Manifest shape

Every signed export carries a manifest alongside the export payload:


{
  "export_id": "uuid",
  "project_id": "uuid",
  "export_type": "soc2_evidence",
  "format": "jsonl",
  "compressed": true,
  "record_count": 1547,
  "content_hash": "sha256:...",
  "signature": "ed25519:...",
  "public_key": "ed25519:...",
  "signed_at": "2026-04-14T00:00:00Z",
  "keel_version": "1.x",
  "chain_integrity": {
    "verified_at": "2026-04-14T00:00:00Z",
    "chain_length": 4521,
    "last_verified_hash": "sha256:..."
  }
}

Field	Meaning
`content_hash`	SHA-256 of the compressed export payload, hex-encoded with `sha256:` prefix
`signature`	Ed25519 signature over the content hash, base64-encoded with `ed25519:` prefix
`public_key`	The Ed25519 public key used to sign this export, included for independent verification
`chain_integrity.chain_length`	Length of the project’s verified governance event chain at export time
`chain_integrity.last_verified_hash`	Hash of the last verified record in the chain at export time

Verifying an export independently

Exports are designed to be verified without calling back to Keel. Each manifest carries the public key used to sign the export, so you can verify locally against only the export file and its manifest.

A verifier must perform four steps:

Recompute the SHA-256 of the compressed export payload.
Compare the computed hash against content_hash in the manifest.
Verify the Ed25519 signature over the content hash using the public_key from the manifest.
Treat the chain_integrity snapshot as an informational summary, not as per-record attestation.

If any of the first three steps fails, treat the export as tampered.

Any Ed25519 library in your language of choice is sufficient — the manifest contains everything a verifier needs.

For CISO review, request an export with chain entries and run the standalone verifier with --walk-events and --verify-closure. See Independent Verification Overview and Running Keel Verify.

Key rotation

Operators can rotate the active signing key without re-signing historical exports. Existing exports remain verifiable against the public key recorded in their own manifest — each manifest is self-contained and does not depend on the currently active signing key. The operator-side rotation procedure is part of the deployment guide.

What signed exports prove (and don’t prove)

They prove: The export payload has not been modified since it left Keel. Any modification to the compressed export file invalidates the Ed25519 signature.

They do not prove:

That every record that should be in the export is present. The manifest attests the content it received, not that the export is complete.
That the chain integrity snapshot covers every event ever written for the project. Chain length is a snapshot of the verified chain at export time.
Any per-record inclusion proof. See Trust & Integrity for the current limits of the integrity stack.

Independent Verification Overview — what a CISO can prove independently
Running Keel Verify — step-by-step verifier workflow for signed exports
Trust & Integrity — the full four-layer integrity stack
Route Guarantees — trust properties per route
Configuration Reference — operator configuration categories for deployed Keel runtimes