No inbound ports

The meeting that kills an analytics platform is rarely about analytics. It is the network review: who opens a port, who holds the database credential, what can reach into the estate from outside. A platform can win every demo and still spend two quarters stuck on those three questions.

The KEZEL agent’s answer to the first one is structural: it initiates every connection itself and pulls its instructions from the control plane. Nothing pushes into your network, nothing listens on it, and there is no inbound port to open, because nothing ever arrives uninvited.

What travels on that connection is narrow. One thing crosses, inbound to the agent once it asks: an encrypted instruction, built from schema metadata and intent, carried over TLS 1.3 with AES-256 payloads and vault-held keys. The credential to your databases never makes the trip at all. It stays inside your boundary with the agent, and the control plane is built to work without raw-row access.

For the reviewer this collapses the surface. Firewall rules stay egress-only and under your control. The agent itself deploys the way your team already ships software: a Docker or Kubernetes container, a VM, or a system service, on-premises or in your cloud, operated by you.

Where the claim stops

Restricted and air-gapped network patterns are a design target, not a shipped configuration, and that distinction belongs in the open. A diligence meeting will find it anyway; we would rather draw the line ourselves. What ships today is outbound-only operation under your firewall rules.

Egress-only is also not zero-review. Your security team still reads the policy file, inspects the agent, and approves its egress destination. The claim is narrower and more useful: the review is bounded. One agent, one policy file, one connection direction, with the due-diligence answers written down in the order the call asks for them.