Skip to main content
Quint on Kubernetes is early access. The Quint images for Kubernetes (quint-sidecar, quint-qhelper and quint-node-installer), the Helm charts and the admission webhook are not available for download. Your Quint contact gives you each of them, with the image digests for your release, so talk to your Quint contact before you plan an install. This does not apply to the agent-base image for Docker.
Quint works with AI agents that run in containers. With Docker, your agent runs in one container built from Quint’s agent-base image, and Quint runs inside the same container: see Run an agent in a container with Docker. The same image also runs as a Kubernetes pod with one container: see On Kubernetes. The rest of this page is about the two setups that run Quint in its own containers. On Kubernetes, Quint can run in its own containers inside the same pod as your agent. Your agent image runs unchanged. Quint locks the pod’s outbound traffic to its own proxy, so every connection the agent makes passes through Quint and is checked against the workload’s policy.

​
What it gives you

  • The agent reaches the internet only through Quint. Its proxy settings point at Quint’s proxy on 127.0.0.1:9090, and any traffic that goes anywhere else is dropped.
  • The agent can’t reach or tamper with Quint. Quint’s containers run as a separate user, the agent sees Quint’s files read-only, and the admission webhook refuses kubectl exec and kubectl attach into Quint’s containers.
  • The agent is cut off if Quint stops. Quint starts first, and the agent container starts only after Quint passes its startup check. If Quint stops or finds the setup was bypassed, the pod stays cut off from the network.
Each pod belongs to a workload you set up on the Workloads page, and each container start is a run there.

​
The Kubernetes setups

The Standard and Restricted setups need the Quint admission webhook, which checks every pod in a governed namespace before Kubernetes creates it. The charts, the Quint images and the webhook all come from your Quint contact.

​
Requirements

These apply to the Standard and Restricted setups. For a pod built from agent-base, see On Kubernetes.
  • Kubernetes 1.33 or newer.
  • containerd 2.0 or newer on every node that runs governed pods.
  • Linux nodes with nftables and cgroup v2. Quint pods always carry kubernetes.io/os: linux.
  • An agent image that runs as a non-root user. You give its user ID as agentUID, and it can’t be 0 or 10001 (Quint’s own user). An image whose entrypoint needs root does not run unchanged.

​
Networking for the restricted setup

The node installer chains Quint’s network plugin after your cluster’s own network plugin. The restricted setup works with these:

​
Network policies

The Quint sidecar must reach the Quint API, https://api.quintai.dev unless you set quint.apiURL, and Quint’s ingest address, which you can change with quint.ingestURL. If a Kubernetes NetworkPolicy blocks the sidecar from reaching them, the sidecar can’t enrol, the agent container never starts, and every protected pod in that namespace is cut off. Add an egress rule that lets the Quint sidecar reach the Quint API. The sidecar also needs the cluster DNS service. If you turn on record delivery, it needs the admission webhook’s Service address too. See Record delivery.

​
Status recorded for runs

Quint records a status on each run. The Workloads page does not show it. To learn a run’s status, ask your Quint contact. A run is never recorded as contained without the webhook’s record. To get records, the webhook needs the API server’s client certificate and record delivery turned on, and Quint must have registered your webhook’s key. Until all three are in place, every run is unverified. See The Quint admission webhook.

​
Next