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

Application-layer encryption covers the specific materials listed below. It does not establish encryption for every stored object, database record, export, checkpoint or backup.

Provider-key encryption supports key rotation without re-encrypting all material in lockstep. Request deployment-specific storage encryption and key-management evidence during security review; the cryptographic evidence verifier does not establish this infrastructure posture.

Governance event chain

Project-scoped governance events are recorded in a tamper-evident chain. Integrity review can detect insertion, deletion, or modification of recorded chain entries. Organization/global audit events have a separate chain scope. Historical unchained rows can be covered by an integrity digest; ordinary dashboard-log retention preserves those inputs too.

The chain is the primary tamper-evidence mechanism. On Production and Enterprise, signed compliance exports embed a manifest summarizing chain state at export time. Externally anchored checkpoints publish per-project chain state to storage outside the runtime; a checkpoint establishes that the events it covers existed by its publication time, not at their own time. Where timestamping is enabled, Keel requests RFC 3161 receipts from FreeTSA and DigiCert on Starter, and DigiCert and GlobalSign on Production and Enterprise. Starter checkpoint views show status only, with no receipt. Customer-selected timestamp authorities are not available on hosted Keel.

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

Session action arguments

Session action-permit requests retain the submitted arguments in voice.tool_call.requested governance events and the bound Permit’s target.arguments. Tokenized identifiers are still argument values; these records are not a hash-only projection. Bulk auditor-safe exports with chain entries refuse selected evidence containing raw action arguments that fail the privacy guard. This can prevent exporting the affected Session lifecycle. Per-Permit decision-integrity packs can remain available for signed decision claims; they do not establish the full lifecycle or a downstream effect.

Secrets management

Keel manages runtime configuration secrets — database credentials, signing keys, object-storage credentials, and timestamp-authority configuration — through the deployment platform’s secrets manager. Secrets are not committed to the repository. Structured logging applies secret-name and secret-value redaction, but customers should still avoid placing credentials in prompts, metadata, or other free-form fields.

Data-subject mechanics

Keel supports controller-instructed data-subject workflows through scoped PII and payload-field 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 three mechanisms that must not be collapsed into a single “delete data” claim:

1. Scoped PII and payload-field erasure. Keel can clear supported identity fields and redact selected subject-linked payload fields in governance and attestation records. Changes are recorded with signed, integrity-linked erasure transitions; their subject references use commitments rather than the raw identifier.
2. Selected MCP fact-opening clearing. Supported sensitive fact values and their opening material are stored encrypted, separately from their commitments. The scoped erasure flow clears these encrypted openings and records an integrity-linked transition. It does not destroy a per-subject governance-event key.
3. Retention cleanup. Keel runs plan-window cleanup for a bounded subset of records, plus lifecycle-specific payload cleanup. This is separate from subject erasure. Expiry or loss of replay access does not by itself establish physical deletion.

Governance records can still contain readable identifiers and payload fields outside these mechanisms. Keel does not currently implement a general per-subject governance-payload encryption/key-destruction flow or an identifier-only format for all new governance events.

Every plan runs on the same shared hosted service; plan tiers change limits and features, not where data is processed. See Plans & Entitlements.

What Keel does and does not do with personal data

What Keel does:

• clears supported PII and selected payload fields in governance and attestation records;
• records signed, integrity-linked erasure transitions;
• encrypts and clears selected MCP fact openings while retaining their commitments.

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 every field or record outside the supported scoped mechanisms;
• erase data outside Keel-controlled stores.

Retained commitments support integrity verification; they are not automatically anonymous in every context. Backup copies have separate retention cycles. Reapplication of erasure and revocation controls after a restore requires operational verification; an automated restoration-suppression mechanism is not established by these scoped runtime workflows.

Keel’s data handling supports controller workflows for scoped field erasure and selected fact-opening clearing 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.

Retention boundaries

Plan-tier dashboard log windows are 30 days for Starter, 180 days for Production and 365 days for Enterprise. Cleanup applies to eligible records, with lifecycle protections for active work; it is not a deadline for every request, response or evidence copy.

Response-cache expiry and prepared-action expiry are cache-access or execution limits, not physical-deletion guarantees. Encryption retains recoverable content; it is not deletion. Retained hashes, commitments and Keel-generated metadata can still be personal data in context. No universal deletion period is established for the stores outside plan-window cleanup.

Scoped field erasure and supported exports are distinct from complete customer-wide deletion or return. A complete request can require manual store and processor coordination. Customer-specific commitments depend on the applicable agreement; operational completion must be verified separately.

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. The current subprocessor list itself is public at keelapi.com/subprocessors .

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 include database-enforced tenant isolation, the listed encryption categories, the tamper-evident chain, scoped field erasure, and selected MCP fact-opening clearing.
• Data-subject mechanics are scoped to supported records and fields, 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