Data Minimization
This page answers: does Keel see our prompts, and what does it retain?
Keel evaluates authorization and enforces the resulting decision before downstream execution or dispatch. Supported execution routes receive the content needed to evaluate and carry out the action. That can include prompts, tool arguments, attachments, and provider responses. Content handling depends on the surface and lifecycle; Keel does not make a blanket claim that prompts or completions are never stored.
Request and response content
| Surface or record | Content handling |
|---|---|
| Ordinary synchronous execution and provider proxy replay | The shared replay flow ordinarily records a request digest and metadata rather than a complete copy of the inbound request. This does not describe every request store or recovery flow. |
| Response replay and execution records | Some flows retain provider-native or normalized response content for retry replay and lifecycle readback. Normalized content can still contain completion text or tool results. Some response stores truncate oversized bodies; truncation is not PII redaction. Streaming replay can retain a finalized response rather than every stream chunk. |
| Async jobs and review, resume, or recovery flows | Supported flows retain recoverable, application-encrypted request content so Keel can execute or resume the authorized action. Encrypted content is stored content. |
| Prepared work actions | Keel retains an encrypted dispatch payload and clears it on supported terminal transitions. Expiry prevents use; it does not by itself prove physical deletion. |
| Challenged payment actions | Deferred credentials can be retained in database JSON until the action terminates or its cleanup window applies. This store is not covered by the application-encrypted request claim above. |
| Selected MCP facts | Sensitive fact openings can be encrypted separately, with commitments retained in the decision record. Other supplied facts and metadata can remain readable in retained records. |
| Signed execution-closure and MCP tool-call evidence | These records bind request and result content with hashes or digests rather than full provider bodies. A digest does not reconstruct the original content. Separate replay and recovery stores can retain that content. |
| Compliance exports | The export projection omits full runtime request and response bodies. It can still contain policy configuration, identifiers, and personal data in metadata. |
Session action-permit requests retain their submitted arguments. See Session action arguments for where they are stored and how they limit exports.
These are distinct stores, not separate standard execution models. A hash-only evidence record does not mean that content is absent from the rest of Keel.
Metadata and accounting
Keel also retains route-appropriate records such as:
| Field class | Examples |
|---|---|
| Token counts | prompt_tokens, completion_tokens, total_tokens |
| Provider and model | Provider and model identifiers |
| Cost | Microdollar accounting |
| Identifiers | Provider response id, request id, permit id |
| Timestamps | Request, dispatch, completion times |
| Authorization metadata | Decision, reason code, policy references, constraints |
| Budget accounting | Reservation, spend, envelope state |
Aggregate prompt analytics summarize token counts and cost without requiring a copy of the underlying prompt text. Metadata can itself contain personal data; it is not automatically anonymous.
Retention
Retention is store- and surface-specific. Plan-tier dashboard log windows cover a bounded subset of records; they are not a universal deadline for replay content, evidence, exports, or backups. A short-lived replay cache and a durable execution record can contain related responses with different lifetimes. Response-cache expiry affects cache lookup; it does not by itself delete a durable response copy or make an executed action eligible for redispatch.
Known terminal async requests support clearing stored request payloads. Unresolved outcomes can retain recovery content; later commitment expiry can leave payload-free replay-rejection records. Clearing content is distinct from deleting the record, its commitments, earlier exports or backup copies. Selected field/opening erasure is not a universal customer-wide deletion workflow.
See Data Handling and the Privacy Policy for retention boundaries and customer-agreement considerations.
Redaction in operational logs
Keel’s structured logger redacts sensitive field names, including authorization, api_key, token, secret, and password. It also detects specific Keel API-key and OpenAI-style key prefixes in values. These controls do not universally detect arbitrary bearer-token values or sensitive content in free-form fields.
Operational logs are diagnostic records, not the execution evidence record. Avoid placing credentials or unnecessary personal data in prompts, metadata, or support reports.
Implication for PII
Personal data in retained responses, encrypted requests, facts, or metadata can remain stored by Keel. Normalization, truncation, encryption, and hashing are different operations; none should be described as universal PII removal.
Keel does not currently offer general prompt-body PII detection or redaction as a runtime feature. If a workflow requires it, apply it before submitting content to Keel.
Controller-instructed erasure supports selected PII fields and payload fields, with integrity-linked erasure transitions. Selected MCP fact openings can be cleared while their commitments remain. This is scoped erasure, not per-subject key destruction or full erasure across every system. See Data Handling.
What this surface does and does not claim
- Prompt-firewall outcomes can record rule-match metadata; inspection coverage remains route-dependent.
- Request and response storage supports specific execution, replay, and recovery needs. It is not a claim that all requests or all responses are retained.
- Provider-side retention and copies delivered to customers or other recipients are separate from Keel-controlled stores.
Related pages
- Data Handling — encryption, isolation, retention boundaries, and scoped erasure
- Security — broader public security boundary
- Threat Model — conservative public-boundary view
- Prompt Firewall — inspection and block evidence
- Permits — the canonical decision record