Security
Keel is infrastructure. Security is not a feature — it is a design constraint applied to every layer.
Encryption at rest and in transit
Customer traffic is served over HTTPS. Stored objects use server-side encryption, and provider keys use application-layer encryption.
Minimal data exposure by default
Permit-first mode operates on metadata only — user identifiers, action types, and estimated token counts. Execution routes receive prompt content for dispatch and optional firewall inspection.
Tenant-isolated service architecture
Project-scoped data is protected by database-enforced tenant isolation and server-side credential resolution.
Durable audit logging
Every permit decision and governed execution is recorded with full lifecycle context. Governance events participate in a tamper-evident per-project chain. Logs are exportable for compliance or debugging.
Data visibility by integration mode
Permit-first mode
Keel receives metadata only: user identifier, action type, estimated token count, and model name. No prompt content, conversation history, or AI outputs.
Execution and proxy routes
These routes receive prompt content for dispatch to the upstream provider. On supported routes, the prompt firewall inspects content before dispatch. Firewall coverage is route-dependent and payload-dependent — it is not applied universally across all integration modes.
Provider credentials
Provider API keys are resolved server-side per project. They are not stored on the execution context, included in governance events, or exposed in logs.
External timestamping
Independent witness for integrity checkpoints
Keel uses RFC 3161 timestamp authorities as external timestamp witnesses for integrity checkpoints. Starter receives a FreeTSA-backed receipt; Production attempts dual independent public CA-operated witnesses through DigiCert and GlobalSign; Enterprise adds eligibility for a customer-selected TSA.
The verifier proves exported evidence has not been altered after signing. Like any signing system, the trust boundary includes the signer at signing-time. Defending against privileged signing-time manipulation requires a higher-assurance signing architecture beyond the scope of this verifier.
Verification and boundaries
Keel verifies the RFC 3161 message imprint against the checkpoint hash. When a TSA CA bundle is configured, OpenSSL-backed authenticity validation also checks the CMS signature, configured trust-store chain, and timestamp-signing purpose. Keel does not claim OCSP/CRL historical revocation, archival/LTV validation, or legal/court-grade guarantees.
Data subject erasure scope
Keel supports four mechanisms for reducing or removing personal data within Keel-controlled data stores under controller instruction. These mechanisms preserve the tamper-evident audit chain while shrinking the recoverable personal-data surface. They are not full Article 17 erasure across every system.
1. Audit-PII field-level redaction (Phase 1)
Selected PII columns on governance event rows (actor email, IP address, user agent) can be NULLed for a target subject without deleting the chain row. The redaction is recorded as a chain-anchored event whose payload carries a one-way subject commitment, never the raw identifier.
2. Per-subject payload erasure via key destruction (Phase 2)
Event payloads written under chain format version 2 or 3 are encrypted with a per-(organization, subject) wrapping key. Destroying that key renders all encrypted payloads for that subject cryptographically unreadable while leaving the chain row and its payload hash intact.
3. Identifier commitments on chain rows (Phase 3 / 3.1)
New chain rows store actor and resource identifiers as one-way HMAC commitments rather than raw values. Raw identifiers for these events live only inside the encrypted payload addressed by Mechanism 2. Format version 3 is the production default since 2026-05.
4. Retention cleanup
Plan-window retention cleanup runs on a bounded subset of governance data. Operational cleanup is separate from a subject-erasure workflow and applies regardless of subject status.
What is not in scope
Keel does not, and does not represent the mechanisms above as, providing full Article 17 erasure or equivalent rights across every system. The following are explicitly out of scope:
- personal data outside Keel-controlled systems;
- historical hash-chain commitments, which are non-personal by design;
- data already delivered to recipients, including webhook subscribers and customer-instructed export consumers;
- legacy chain format version 1 and 2 records that pre-date Phase 3 identifier commitments;
- personal data retained under a documented lawful basis, including EU AI Act Article 26(6) retention for high-risk AI system logs (minimum six months, subject to applicable Union or national law on the protection of personal data) and analogous obligations under HIPAA, SOC 2 evidence retention, SOX, FINRA, and similar regimes;
- backup and replication copies until routine deletion cycles complete; restored data is replayed against the active erasure suppression list before becoming production-active.
Customers should evaluate whether Keel's in-scope coverage suffices for their data map and retention obligations. The Data Processing Agreement reflects this scope. For technical mechanics, see the data handling reference.
Operational security
Access control
Project API keys are the runtime caller credential. Role-based access control governs team accounts. Keys can be scoped to specific projects and actions.
Replay and staleness protection
Execution routes support opt-in replay protection via X-Keel-Timestamp and X-Keel-Nonce headers. When enabled, requests outside a 5-minute window are rejected and nonces are tracked per API key for 24 hours. Recommended for production deployments. When not enabled, replay protection depends on idempotency keys.
Outbound request policy
Provider and JWKS egress uses HTTPS only, restricted to approved hosts, validated through DNS resolution checks that reject private and reserved address space. Redirects are disabled.
Infrastructure isolation
Network-segmented infrastructure with regular vulnerability scanning, patching, and DDoS protection.
Incident response
Continuous monitoring and alerting. Documented incident response procedures. Security incidents communicated within 72 hours.
Report a vulnerability
We practice responsible disclosure. If you discover a security issue, contact our security team directly.