Logs tell you what happened.
Keel decides what happens.
Most systems observe AI usage after the fact. Keel evaluates every request before it leaves your boundary — enforcing policy, controlling spend, and producing audit-ready evidence in the same step.
What You Can Rely On
Decisions before execution
Requests are evaluated before provider calls leave the boundary on managed routes.
Verifiable audit evidence
Every decision is recorded and can be independently verified without contacting Keel.
No raw data in audit records
Prompt and completion content are not stored in the audit substrate.
Tamper-evident history
Evidence is structured so changes are detectable on review.
Clear scope, no overclaims
What Keel enforces, observes, and leaves to your system is explicitly defined.
Permits: The Audit Record
Every governed request produces a permit — a decision record capturing:
- what was requested
- what decision was made
- why the decision was made
- what policy applied
- what constraints were enforced
- what budget state existed at that moment
Permits exist whether or not a request is executed. This creates a consistent audit trail that does not depend on logs or reconstruction.
See how permits workEvidence You Can Verify
Keel is designed so auditors don't have to "trust the platform."
Signed exports
Evidence can be verified using standard tools, without calling Keel.
External checkpoints
Evidence can be anchored outside the system for independent review.
RFC 3161 timestamp receipts
External timestamp witnesses by tier, with replayable imprint verification and OpenSSL-backed authenticity validation when a trust bundle is configured.
RFC 8785 canonical encoding
Signed evidence (binding v6) conforms to JSON Canonicalization Scheme and can bind nested and rail evidence into the verified record. Any RFC 8785 implementation in any language can independently verify Keel-issued signatures from first principles — no Keel-specific code required in the verification chain.
Published verification procedure
A clear process exists for reconciling evidence end-to-end.
No Raw Data in the Audit Layer
Keel separates control from content.
Not stored
- raw prompts
- raw completions
- tool payloads
- multimodal data
Stored
- decision metadata
- token usage and cost
- model and provider identifiers
- timestamps and policy references
This default reduces indirect data residency exposure for sensitive workloads and simplifies data-handling reviews.
Subject Erasure, Honestly Scoped
Keel supports controller-instructed erasure of personal data within Keel-controlled data stores through four mechanisms: audit-PII field redaction, per-subject payload erasure via cryptographic key destruction, identifier commitments on new chain rows, and plan-window retention cleanup.
These mechanisms preserve the tamper-evident audit chain while shrinking the recoverable personal-data surface. They are not full GDPR Article 17 erasure across every system, and Keel does not represent them as such. Out-of-scope locations — including legacy chain format records, data already delivered to recipients, and personal data outside Keel-controlled systems — are explicitly enumerated in the security and DPA artifacts.
View full erasure scopeBuilt for Real Security Reviews
Keel is designed to align with how enterprise buyers evaluate systems.
Access controls
Scoped credentials, secure storage, redaction of sensitive keys in operational logs.
Monitoring
Full decision and execution traceability across every governed request.
Change traceability
Preserved decision context and versioning with deprecation commitments on stable contracts.
Audit readiness
Evidence export designed for independent verification, without calling Keel.
Keel does not claim attestations it has not completed. Detailed documentation and review materials are available during security evaluation.
Deployment Alignment
A few decisions are aligned during onboarding — handled through standard vendor review, not hidden in product behavior.
Managed execution vs. decision-only
On managed execution routes, decisions are enforced and Keel issues the provider call. Decision-only mode is advisory by design and appropriate for caller-controlled execution.
Layered content controls
Built-in content inspection focuses on well-defined risk patterns. Workloads requiring open-ended semantic content evaluation are appropriate for layered deployments.
Tenant isolation alignment
Customers with strict isolation requirements can review the deployment model with Keel during onboarding.
Availability topology
Customers with regional residency or active-active availability requirements can align on deployment topology before signature.
Attestation alignment
Buyers whose procurement processes reference a specific attestation can align on the current attestation roadmap during vendor review.