Run Quint with agents in containers

Run an AI agent in a container with Quint: Docker with the agent-base image, or Kubernetes with Quint in its own containers. What each gives you, requirements and run status.

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

Setup	Use it when	What runs in the pod
Standard	The namespace can use the Kubernetes privileged Pod Security level.	Your agent, the Quint sidecar, and two Quint containers that hold the network privilege (NET_ADMIN) to set and keep the pod’s network rules.
Restricted	The namespace enforces the Kubernetes restricted Pod Security level.	Your agent and the Quint sidecar only, with no added privileges. A Quint node installer, run once per cluster, sets the network rules on each node.
One container from agent-base	You build your agent image on Quint’s agent-base image, and the namespace can use the privileged Pod Security level.	One container that holds Quint and your agent. It starts as root with NET_ADMIN, and Quint starts the agent as a non-root user.

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:

Cluster network	Notes
kindnet	No extra settings.
Cilium	Only with Quint chained through Cilium’s own CNI configuration, using Cilium’s Helm value cni.configMap with cni.exclusive=true. See Cilium.
Amazon VPC CNI (EKS)	The VPC CNI rewrites its configuration each time it starts. The node installer chains Quint again at once and keeps the node closed to new pods until the chain checks out.

​

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.

Status	When
contained	The pod was admitted by a webhook on a cluster you run yourself, and the sidecar presented the webhook’s signed record of that pod when it registered.
unverified	Any run without a record. This includes every run on Amazon EKS and Google GKE managed clusters, where the webhook still checks and refuses pods but signs no record, and every run in the restricted setup.
violated	The Quint sidecar reported that the pod’s setup was bypassed. The run keeps this status.

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

• Run an agent in a container with Docker
• Standard setup
• Restricted setup
• The Quint admission webhook