Data Handling

This page describes how Keel handles customer data: where it lives, how it is isolated, how it is encrypted, and how scoped data-subject workflows are mechanically supported. The page covers technical mechanics that are stable today. Operational policies that depend on customer-specific commitments are listed at the end of the page.

For data minimization (what Keel does and does not log about prompts), see Data Minimization. For the broader security boundary, see Security.

Tenant isolation

Keel’s primary runtime isolation boundary is the project. Public runtime routes authenticate into a project; permits, governed requests, executions, usage rows, governance events, async jobs, and provider credentials are all scoped to the authenticating project.

Project isolation is enforced at the database layer in addition to the application layer. Project-scoped tables carry isolation policies that bind reads and writes to the authenticating project’s identifier; cross-tenant access is rejected at the database boundary, not only above it.

The isolation posture is conservative by design: a service-layer error that would otherwise widen a query is caught and rejected before any cross-tenant row is returned. Deployment-specific isolation coverage is reviewed with customers during onboarding.

Transport security

All customer traffic is HTTPS. TLS is terminated at Keel’s edge, and inter-service traffic between the edge and Keel’s runtime is constrained to the host network. Public runtime routes refuse plain HTTP. The request-freshness contract additionally requires X-Keel-Timestamp and X-Keel-Nonce headers in non-development deployments — see Request Freshness.

Encryption at rest

Keel’s encryption-at-rest model is categorical: each class of stored material has a documented encryption posture.

Provider-key encryption supports key rotation without re-encrypting all material in lockstep. Volume-level encryption posture and key-management procedures are shared under standard security review.

Governance event chain

Every governance event Keel writes participates in a per-project tamper-evident chain. Insertion, deletion, or modification of a recorded event breaks the chain at the affected position and is detectable on later integrity review.

The chain is the primary tamper-evidence mechanism. On Business plans and above, signed compliance exports embed a manifest summarizing chain state at export time, and externally anchored checkpoints publish per-project chain state to storage outside the runtime on a regular cadence. On Enterprise, an independent RFC 3161 timestamp authority witnesses each checkpoint.

For the verifier flow that confirms these artifacts cryptographically, see Verifying Keel Evidence.

Secrets management

Keel manages runtime configuration secrets — database credentials, signing keys, object-storage credentials, and TSA configuration — through the operator’s deployment platform secrets manager. Secrets are not committed to the repository, and the structured logger redacts well-known secret keys (authorization, api_key, token, secret, password) and known secret-value patterns from log output.

For self-hosted deployments, the secrets surface is the operator’s own secrets manager. The cold-start fallback path for historical signing keys is described in Verifying Keel Evidence § Migration note for self-hosted operators.

Data-subject mechanics

Keel supports controller-instructed data-subject workflows through scoped audit-PII redaction and payload erasure within Keel-controlled data. These mechanisms preserve the audit chain while reducing retained personal-data exposure. They are not full subject erasure across every system, and they are not Article 17 erasure.

Keel distinguishes four mechanisms that must not be collapsed into a single “delete data” claim:

1. Audit-PII field-level redaction. Keel can NULL selected PII columns (actor_email, ip_address, user_agent) on governance_events for a target subject without deleting the row. The redaction is recorded as a chain-anchored audit.pii_redacted event whose payload carries a subject commitment, not the raw identifier.
2. Per-subject payload encryption and key-destruction erasure. Format-2 and format-3 event payloads are encrypted under per-(org, subject) keys. Destroying the subject key renders those encrypted payloads unreadable while preserving the chain row and its payload_hash.
3. Identifier commitments on chain rows. New format-3 chain rows store subject and resource identifiers as commitments. Raw values live only in encrypted payloads where the payload-erasure mechanism can reach them.
4. Retention cleanup. Keel runs plan-window retention cleanup for a bounded, high-volume subset of governance data. That operational cleanup is separate from a subject-erasure workflow.

For controller-instructed request paths and the per-tier delivery model (Business managed-service vs Enterprise self-serve), see Plans & Entitlements.

What Keel does and does not do with personal data

What Keel does:

• redacts audit-PII fields in supported governance records;
• encrypts event payloads under per-subject keys;
• stores subject and resource identifiers as commitments on new audit-chain rows;
• destroys per-subject keys to render supported encrypted payload data unreadable on request.

What Keel does not do:

• provide full subject erasure across all systems;
• modify or remove historical chain commitments;
• erase data already delivered to recipients, including webhooks, exports, or checkpoints;
• erase legacy format-1 or format-2 events outside the current erasure scope;
• erase data outside Keel-controlled stores.

Keel’s data handling supports controller workflows for audit-PII redaction and payload erasure within Keel-controlled data. Full legal compliance under GDPR, CCPA, or other applicable frameworks depends on the controller’s broader handling of subject data outside Keel.

Operational policies and security review

The technical handling described above is stable today and documented because it is. Operational program documentation — personnel access governance, vendor and subprocessor management, deletion service levels, training cadence, incident-response procedures, and similar program-level commitments — is shared under standard security review rather than published.

If you are evaluating Keel for procurement, request the current security questionnaire and program documentation through security@keelapi.com or your point of contact at Keel.

What this surface does and does not claim

• The technical mechanics described here — database-enforced tenant isolation, encryption-at-rest categories, the tamper-evident chain, audit-PII redaction, payload erasure, and identifier commitments — are part of the runtime today and are documented because they are stable.
• Data-subject mechanics describe controller-instructed audit-PII redaction and payload erasure within Keel-controlled data, not full Article 17 erasure. Per-tier delivery is described in Plans & Entitlements.
• Operational program documentation is shared under standard security review.

For the encryption-scope model, the integrity proof model, and the rest of the public scope boundaries, see Scope and Limits.

Related pages

• Security — broader public security boundary
• Data Minimization — what Keel does and does not log about prompts
• Threat Model — conservative public-boundary view
• Verifying Keel Evidence — independent verification of signed exports and checkpoints
• Signed Exports — request and structure of signed exports
• Plans & Entitlements — per-tier delivery model