Threat Model

This page is intentionally conservative. If a protection is not documented here or on a public route page, do not assume it is part of the public contract.

Current public security boundaries

• runtime callers authenticate with project API keys
• on Keel-managed execution routes, governance runs before provider dispatch
• provider keys stay server-side for Keel-managed execution routes
• Keel applies application-layer outbound controls to the destinations it directly executes
• Prompt Firewall V1 coverage is route-dependent and payload-dependent
• dashboard, admin, and other operator surfaces are not the same as the public runtime boundary

What this means today

• provider and authentication-related outbound paths Keel controls are limited to HTTPS destinations
• approved outbound destinations are host-restricted and validated before use, with reserved and non-public address space out of scope
• redirects are not followed on the validated outbound paths documented publicly
• blocked outbound attempts emit structured security events

Those controls reduce SSRF and unsafe-egress risk for the destinations Keel executes directly. They do not replace network-layer egress controls.

Important exclusions

• permit-first provider calls executed by your application are outside Keel’s outbound boundary
• Prompt Firewall coverage is not universal across every provider, route, or payload field
• remote asset URLs may later be fetched by the upstream provider rather than by a Keel-controlled fetcher

Beta-period threat boundaries

The following are known gaps in the current beta that do not yet have mitigations:

• Prompt Firewall payload-size boundary. Large base64-encoded payloads may exceed the current inspection pipeline’s size threshold. Content beyond that threshold passes through governance and usage accounting but is not inspected by the firewall’s text-level rules.
• Provider health signal scope. Provider health signals are currently global, not tenant-scoped. A small number of failed requests from one project can influence health-based routing decisions for other projects. This does not expose data across tenants.
• Remote asset TOCTOU. When a request references a remote asset by URL, Keel may validate the URL at request time, but the upstream provider fetches the asset independently. The content at that URL could change between Keel’s validation and the provider’s fetch.

These are documented so security-conscious teams can assess risk before rollout. Keel tracks these as deferred findings with planned mitigations.

Use these pages for rollout decisions

• Architecture
• API Reference
• Security
• Known Limits