> ## Documentation Index > Fetch the complete documentation index at: https://docs.quintai.dev/llms.txt > Use this file to discover all available pages before exploring further. # 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. > [!NOTE] > > 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](https://docs.quintai.dev/install/docker.md). The same image also runs as a Kubernetes pod with one container: see [On Kubernetes](https://docs.quintai.dev/install/docker.md#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](https://docs.quintai.dev/dashboard/workloads.md) page, and each container start is a run there. ## The Kubernetes setups | Setup | Use it when | What runs in the pod | | - | - | - | | [Standard](https://docs.quintai.dev/install/kubernetes-standard.md) | 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](https://docs.quintai.dev/install/kubernetes-restricted.md) | 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](https://docs.quintai.dev/install/docker.md#on-kubernetes) | 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](https://docs.quintai.dev/install/admission-webhook.md), 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](https://docs.quintai.dev/install/docker.md#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](https://docs.quintai.dev/install/kubernetes-restricted.md#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](https://docs.quintai.dev/install/admission-webhook.md#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](https://docs.quintai.dev/install/admission-webhook.md). ## Next * [Run an agent in a container with Docker](https://docs.quintai.dev/install/docker.md) * [Standard setup](https://docs.quintai.dev/install/kubernetes-standard.md) * [Restricted setup](https://docs.quintai.dev/install/kubernetes-restricted.md) * [The Quint admission webhook](https://docs.quintai.dev/install/admission-webhook.md) This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.