Data Minimization

This page is the customer-facing answer to: does Keel see our prompts?

Keel’s runtime is a governance and accounting layer. To make decisions and persist audit evidence, Keel records metadata about every governed request — but it does not persist raw prompt or completion text. Procurement and security reviewers asking what Keel sees should read this page first; the technical handling around what Keel does persist is in Data Handling.

What Keel does not persist

Keel’s runtime does not store:

Raw prompt text. No table in the runtime database carries a prompt_text, request_body, or equivalent column for inbound message content.
Raw completion text. No table carries a completion_text or response_body column for upstream response content.
Tool-call and tool-result payloads in raw form. Tool-call structures are evaluated by the policy engine and the prompt firewall, but their contents are not persisted on the runtime governance tables.
Multimodal payload bytes. Image, audio, or other binary payloads are dispatched to providers but not retained at rest.
Provider response bodies in raw form. Usage figures and provider response identifiers are persisted; the response payload itself is not.

Prompt-analytics aggregates carry distributional information (token-count buckets, cost distributions) without retaining underlying prompt text.

What Keel does persist

Per request, Keel records:

Field class	Examples
Token counts	`prompt_tokens`, `completion_tokens`, `total_tokens`
Provider and model	`provider`, `model` identifiers
Cost	`cost_usd_micros` (microdollar accounting)
Identifiers	provider response id, Keel-internal proxy and request ids, permit id
Timestamps	request, dispatch, completion times
Permit and governance metadata	decision, reason code, matched policy id, constraints applied
Budget accounting entries	reservation, spend, envelope state at decision time

These records are the substrate that powers permits, decision traces, the governance event chain, signed exports, and timeline replay.

Granularity

Keel records governance and accounting state at three granularities:

Per-permit. One record per governance decision. Carries the decision outcome, reason code, matched policy, and the budget snapshot at decision time.
Per-execution. One record per dispatched provider call. Carries the provider response identifier, observed token counts, observed cost, and timing.
Aggregate prompt analytics. Token-count distributions and similar aggregates that summarize traffic shape without retaining underlying content.

The granularity is intentional. Per-permit and per-execution records are the audit substrate; aggregates exist for capacity planning and cost forecasting.

Redaction in operational logs

Keel’s structured logger redacts well-known sensitive keys before output:

authorization
api_key
token
secret
password

The logger additionally strips known secret-value patterns (Keel API key prefixes, OpenAI-style key prefixes, common bearer-token shapes) regardless of which key carries them. Operational logs are kept narrower than the runtime database; they exist for diagnostic purposes and are not the audit record.

Implication for PII

Because Keel does not persist raw prompt or completion content, personally identifiable information contained in prompt bodies is not retained at rest by Keel.

PII present in request headers or path parameters is subject to the structured-logger redaction patterns above. Headers that match the redaction key list are stripped from log output; arbitrary header content outside the documented headers is not specifically redacted.

If a workflow requires PII detection or redaction inside prompt content, that detection happens upstream of Keel — in your application or in a dedicated PII redaction service — before the request reaches Keel’s runtime. Keel does not currently offer prompt-body PII detection or redaction as a runtime feature.

For retained governance metadata, Keel uses three chain-aware mitigation layers:

Audit-PII field-level redaction. Supported PII columns on governance events can be redacted for a target subject while preserving audit continuity.
Per-subject payload encryption and key-destruction erasure. Supported event payloads are encrypted under per-subject keys; destroying the key renders those encrypted payloads unreadable.
Identifier commitments on chain rows. New chain rows store subject and resource identifiers as commitments, with raw values held only in the encrypted payload where payload erasure can reach them.

This is not full Article 17 erasure. Cross-surface erasure and legacy-event backfill remain outside the current shipped scope. See Data Handling for the exact boundary.

What this surface does and does not claim

“Keel does not persist raw prompt or completion text” is a statement about Keel’s runtime database. It does not extend to provider-side persistence: the upstream provider may log or retain content according to its own policies.
Prompt-firewall rule matches record metadata (rule id, matched category, field path) on a deny outcome. A firewall block is itself evidence; the metadata describing why the block fired is part of that evidence. See Prompt Firewall.
Operational logs are diagnostic. The runtime database is the evidentiary surface; logs should not be relied on as the audit record.
This page describes the runtime today. It does not describe a future content-logging tier or an opt-in prompt-archival mode. If you need either, ask through procurement.

Data Handling — encryption, RLS, audit-PII redaction, payload erasure, and identifier commitments
Security — broader public security boundary
Threat Model — conservative public-boundary view
Prompt Firewall — what gets inspected and what gets recorded on a block
Permits — the canonical decision record