Security
This page summarizes the public security boundary for Keel’s documented runtime surfaces. It focuses on what callers can rely on and what Keel does not claim.
Use Threat Model for the conservative public-boundary view and API Reference for the documented public runtime routes.
Runtime boundary
Keel’s primary runtime isolation boundary is the project. Public runtime routes authenticate into a project and scope permits, executions, usage, governance events, and related audit data to that project.
Today, this is a project-scoped isolation model, not a claim of stronger cross-system isolation guarantees than the code implements.
On Keel-managed execution routes, authentication and governance run before provider dispatch.
Auth and request freshness
Public runtime access uses project API keys.
Non-dev deployments enforce request freshness validation by default on execution routes. Requests without valid timestamp and nonce headers are rejected. Deployments that explicitly disable freshness in a non-dev environment fail closed at startup.
Operator and dashboard routes use separate auth surfaces and should not be treated as equivalent to public runtime authentication.
Provider key handling
Runtime callers do not provide raw provider keys on governed public execution paths. Keel resolves project-scoped provider credentials server-side.
Provider credentials are encrypted at rest and are not part of the public request contract.
If you use the permit-first route (POST /v1/permits) and call the provider yourself, your application owns that second network hop and the provider credential used for it.
Public permit closeout is narrower than Keel-managed execution evidence. It requires verification material; Keel does not directly observe the provider call on the permit-first path. See Scope and Limits § Permit-first observation boundary.
For the broader posture — including encryption-at-rest categories, project tenant isolation, governance event chain, and data-subject mechanics — see Data Handling.
Outbound policy and egress restrictions
Keel applies outbound restrictions to the destinations it controls directly, including provider, authentication, billing, and governed webhook paths.
Public boundary:
- Keel-controlled outbound paths are constrained and validated before use
- these controls are intended to reduce SSRF and unsafe-egress exposure
- they are not a substitute for network-layer egress controls in your own environment
Enterprise customers who need provider traffic forced through Keel by pairing managed execution with customer-owned network controls should see Egress-Controlled Deployments.
Prompt Firewall scope and limits
The full Prompt Firewall surface — strengthen-only configuration model, platform baseline rule categories, per-surface coverage matrix, custom-rule authoring, and the deny-permit shape on a firewall block — is documented at Prompt Firewall. The summary below is preserved for in-context reference.
Prompt Firewall rules are enforced at the platform level. The platform baseline blocks cannot be weakened per project. Projects on the right plan tier may optionally strengthen their firewall posture by adding custom detection rules through project policy overrides. Custom rules can only add blocks — they cannot remove or weaken platform rules.
Prompt Firewall is a route-dependent inspection layer, not a universal content-security boundary. Coverage depends on the execution route and payload format. Treat the Prompt Firewall as one layer of defense within the governed execution path, not a blanket guarantee over every AI request format.
Coverage boundaries:
- Inspection has payload-size boundaries for binary content. Large base64-encoded payloads may bypass text-level inspection. This does not affect governance or usage accounting.
- Coverage varies by provider and payload field. Not every content type within a supported route is inspectable.
Data minimization
Keel does not persist raw prompt or completion text. The runtime records governance and accounting metadata — token counts, model and provider identifiers, cost in microdollars, decision metadata, and budget snapshots — without retaining underlying content. For the full posture, see Data Minimization.
Evidence and audit expectations
Keel’s audit posture relies on persisted records rather than request logs alone. Public callers should expect evidence to come from documented permit, execution, usage, job, and related readback surfaces rather than from raw transport logs.
Relevant record types include permits, execution records, usage records, governance events, async job records, and request timeline replay where those public routes are available.
Some record types carry stronger integrity guarantees than others. See Trust & Integrity for the current public integrity model and its limits.
Integrity posture
Keel’s public integrity model centers on four customer-visible ideas:
- tamper-evident governance history
- signed compliance exports
- externally anchored integrity checkpoints
- independent timestamping for the strongest trust tier
These features are not identical across all plans. See Trust & Integrity for the public feature ladder and non-claims.
Scope and boundaries
For coverage boundaries — provider parity, routing scope, permit-first observation, accounting precision, content-inspection scope, the integrity proof model, outbound asset fetching, and auth-surface separation — see Scope and Limits.
For the conservative public-boundary view, see Threat Model. Deployment-specific boundaries are reviewed during onboarding.