Skip to Content
Egress-Controlled Deployments

Egress-Controlled Deployments

An egress-controlled deployment pairs Keel’s hosted execution with customer-owned network controls so that your workloads can reach AI providers only through Keel. It is for teams that need a defensible story that workloads cannot bypass Keel to reach provider APIs directly.

Keel runs only as a hosted service at api.keelapi.com; Keel execution does not run inside your network. This is a deployment architecture for your side of the connection, not a runtime feature toggle. The application-layer controls Keel provides — request-bound dispatch verification, code-level provider endpoint allowlisting, outbound binding trace metadata, and the dispatch.egress_bound governance event — are properties of Keel’s hosted execution. The network-layer controls that block direct provider egress are operated by you (an egress proxy, a cloud firewall with hostname rules, Kubernetes egress policy with an FQDN-capable layer, or equivalent). Neither layer alone is sufficient; the pattern is the combination.

For the broader security boundary, see Security.

When to use this pattern

Use an egress-controlled deployment when any of the following apply:

  • You need a defensible story that workloads cannot bypass Keel to reach provider APIs directly.
  • You are subject to auditor scrutiny on AI-spend or data-egress controls (SOC 2 CC6, ISO 27001 A.13, HIPAA, FedRAMP-aligned).
  • You run multi-tenant or multi-team workloads where a single misconfigured service account could leak spend or data via direct provider calls.
  • Your threat model includes insider-adjacent risk: developers with legitimate cluster access who could otherwise call providers directly.

This pattern uses Keel-owned managed execution: authorization is evaluated before downstream dispatch. Permit-first callers own downstream enforcement and dispatch; a standalone decision call does not provide the hosted dispatcher controls described here. Customer network controls constrain bypass outside the managed boundary.

Architecture

┌──────────────────────────────────────────┐
│ Your network                             │
│                                          │
│   [workloads] ──egress allowed──▶ api.keelapi.com ──▶ [Keel hosted execution]
│       │                                  │                     │
│       └──egress DENIED──▶ provider APIs  │                     ▼
└──────────────────────────────────────────┘     [provider endpoint allowlisting]
                                                              │
                                                              ▼
                                                     provider APIs

Two independent layers combine:

  1. Network layer (customer-owned). Your egress proxy, firewall, or FQDN policy denies workload egress to provider hostnames and allows it to api.keelapi.com.
  2. Application layer (Keel-operated). Keel’s hosted dispatcher performs signed request-bound verification, enforces provider endpoint allowlisting at the code level, and emits outbound binding trace metadata plus a dispatch.egress_bound governance event for each managed provider dispatch.

The customer network layer constrains the bypass path. Keel records the request-bound admission and authorization decision. An admission record alone does not prove provider receipt, execution, or external state change; inspect the route-specific response, closure and independent downstream evidence for those claims.

Threat model

In scope:

  • Direct-provider bypass. A workload attempts to call api.openai.com (or equivalent) directly, skipping Keel.
  • Credential misuse via bypass. A leaked or shared provider API key is used from inside the customer network.
  • Dispatch tampering. An attacker with code-path access attempts to modify request content after permit issuance.
  • Silent endpoint substitution. An attacker attempts to redirect Keel dispatch to an unapproved provider endpoint.

Out of scope (handled by other controls or explicitly not covered here):

  • Compromise of customer provider API keys outside the network boundary.
  • Compromise of the Keel control plane itself — addressed by Keel’s own trust stack: hash-chained governance records, signed exports, and externally anchored checkpoints with TSA receipts. See Verifying Keel Evidence.
  • Customer-hosted runtimes where dispatch happens outside Keel execution (see § Caveats below).
  • Provider-side verification of Keel permits — providers do not verify Keel permits; outbound binding headers are traceability metadata only.

What this protects against

When both layers are correctly configured, the deployment materially reduces:

  • Workloads reaching provider APIs without going through Keel.
  • Undocumented or unapproved provider endpoints being dialed from execution.
  • Request content drifting between permit issuance and dispatch — detected by signed request-bound verification.
  • Unrecorded authorized fallback changes — where supported, a fallback target must be authorized by the signed routing metadata before any rebind, and permit.binding_rebound_on_fallback records that transition. An exact reviewed request cannot be re-signed or rebound; review does not grant authority to substitute a target.

What this does not protect against

Stated plainly: if your network allows direct outbound calls to provider endpoints, Keel cannot prevent those calls. This deployment pattern assumes you restrict that path.

  • Keel does not automatically provide network-layer egress enforcement. Direct provider egress is blocked by customer network policy, not by Keel.
  • Provider endpoint allowlisting is code-level hardening inside the dispatcher, not a network egress control. A workload that bypasses Keel entirely is not subject to it.
  • Outbound binding trace headers are traceability metadata. Providers do not consume, verify, or enforce them.
  • A decision primitive does not itself dispatch or stop an external caller. Advanced external-enforcement integrations are available by request and require another trusted enforcement boundary. See § Caveats below.
  • Compromise of the customer provider API key outside the execution boundary is not mitigated by this pattern.
  • Keel cannot attest to execution integrity in customer-hosted runtimes under this pattern.

Network controls on your side

Keel does not supply network policy for your environment. The controls you need are:

  • Deny direct provider egress from workloads. Block workload connections to provider hostnames (api.openai.com, api.anthropic.com, generativelanguage.googleapis.com, api.x.ai, and any others you use).
  • Allow workloads to reach Keel. Permit outbound HTTPS to api.keelapi.com.
  • Enforce by hostname. Kubernetes NetworkPolicy alone does not resolve hostnames; use an egress proxy, a Cilium FQDN policy, an Istio egress gateway, or a cloud firewall with hostname rules (AWS Network Firewall, GCP Cloud NGFW, Azure Firewall).
  • Keep flow logs. Denied connections to provider hostnames from your workloads are the network-layer evidence that bypass attempts did not reach providers.

Provider key custody

  • Store provider keys only in Keel’s encrypted provider-key storage (Dashboard → Connectors), so Keel’s hosted execution is the only holder.
  • Do not distribute provider keys to workload pods or developer workstations. Keep workload credential custody separate from network enforcement. Network restrictions do not protect an exposed key used outside that boundary.
  • Rotate provider keys on any suspicion of workload-side exposure, not just Keel-side exposure.
  • For regulated environments, prefer per-project provider keys so a single compromise is bounded.

Monitoring and audit signals

Wire the following signals into your alerting pipeline or external audit tooling. All are emitted as Keel governance events or surfaced on permits and responses:

  • dispatch.egress_bound — provider dispatch through this enforcement boundary emits this. Absence for a project that normally dispatches is itself a signal.
  • permit.binding_rebound_on_fallback — the permit binding was rebound during provider fallback. Spikes warrant review.
  • provider_endpoint_not_allowed — the dispatcher refused to dial an endpoint outside the code-level allowlist. Should be zero in steady state.
  • permit_request_hash_mismatch — request content did not match the permit’s signed binding. A non-zero rate indicates caller drift or tampering.
  • permit_signed_constraint_exceeded — dispatch would have violated a signed constraint.
  • permit_binding_key_mismatch — binding key presented at dispatch does not match the permit’s bound key.
  • permit_signature_invalid — permit signature failed verification.

Pair these application-layer signals with network-layer signals:

  • VPC or flow-log denies to provider FQDNs from workload subnets.
  • Egress proxy rejections for non-Keel sources attempting provider hostnames.
  • DNS query logs for provider domains from non-Keel pods.

Use customer network denied-connection logs to establish a blocked direct-provider attempt. An absent dispatch record alone does not prove a direct call was blocked; the event only describes calls admitted through Keel. Confirm the caller, time window and network enforcement independently.

Operational checklist

Before declaring a deployment egress-controlled:

  • Workloads have default-deny egress, with api.keelapi.com the only permitted AI destination.
  • Hostname-level enforcement denies the provider API hostnames from workloads (egress proxy or cloud firewall).
  • No provider API keys are deployed to workload pods or developer environments.
  • Provider keys are scoped per project where feasible.
  • dispatch.egress_bound presence is monitored per project.
  • provider_endpoint_not_allowed, permit_request_hash_mismatch, permit_signed_constraint_exceeded, permit_binding_key_mismatch, permit_signature_invalid, and permit.binding_rebound_on_fallback are alerted on.
  • Flow logs from workload networks are retained and reviewed.
  • A runbook exists for investigating a denied-egress event from workloads.
  • Workloads that require this egress-controlled architecture dispatch through the approved Keel enforcement boundary; a standalone decision call is not a substitute.

Caveats

Permit-first enforcement outside Keel

A Permit-first integration obtains a decision from Keel while the application or another trusted boundary owns enforcement and dispatch. The decision primitive does not itself dispatch. For an externally dispatched call:

  • Keel’s signed request-bound dispatch verification does not run inside Keel.
  • Keel’s code-level provider endpoint allowlist does not apply.
  • Keel does not emit outbound binding trace metadata for that external call.
  • The external boundary must enforce the decision and constraints before dispatch; a decision record alone does not stop a caller that ignores it.

This is outside the managed-dispatch architecture described here unless the separate enforcement and customer network controls are established and verified. See Permits for the decision contract; the application must enforce it before its own call.

Customer-hosted runtimes

Customer-hosted runtimes — where dispatch happens in customer-operated infrastructure rather than Keel execution — are not covered by this pattern. Specifically:

  • Keel cannot attest to the integrity of a runtime it does not operate.
  • Signed request-bound verification, code-level provider endpoint allowlisting, and dispatch.egress_bound emission are properties of Keel execution. A customer-hosted runtime would need to implement its own equivalent, including a separate attestation and verifier design, before any egress-controlled claim applies to it.
  • Customer-hosted deployments should be described as governed (permits, policy decisions, governance records) but not as egress-controlled under this pattern.

Allowed claim language

The following claims are accurate for a correctly configured egress-controlled deployment:

  • “Provider traffic from our workloads is forced through Keel’s hosted execution by our network policy.”
  • “Keel execution performs signed request-bound dispatch verification before calling providers.”
  • “Provider dispatch is constrained by code-level provider endpoint allowlisting.”
  • “Provider dispatch through this Keel enforcement boundary emits outbound binding trace metadata and a dispatch.egress_bound governance event.”
  • “Direct-to-provider bypass from workloads is blocked at the network layer and detectable at the governance layer.”

Forbidden claim language

Do not use these claims; they are false or misleading:

  • “Tamper-proof.”
  • “Unbypassable.”
  • “Guaranteed enforcement.”
  • “Providers verify Keel permits.” — they do not.
  • “Keel blocks all direct provider egress by itself.” — it does not; customer network policy does.
  • “Provider endpoint allowlisting prevents bypass.” — it is code-level hardening, not network egress control.
  • “Outbound binding headers are verified by providers.” — they are traceability metadata.

What this surface does and does not claim

  • This is a deployment architecture, not a runtime feature toggle. The application-layer controls Keel provides (Keel dispatch verification, code-level allowlisting, governance events) are present in Keel execution; the network-layer controls are operated by the customer.
  • The network controls are yours to operate; Keel’s side is the same hosted execution on every plan. Keel does not run execution inside customer networks, and self-hosted or customer-cloud deployments are not offered.
  • Keel does not expose a server-side toggle that flips a deployment to “egress-controlled.” The properties are achieved through configuration and architecture, not through a feature flag.
  • The forbidden-claim language section is normative for customer-facing materials. Marketing language describing a Keel deployment as “egress-controlled” should match the allowed-claim language above.
Last updated on Edit this page on GitHub 
Prompt FirewallTrust & Integrity