Single-site deployment (PAC)

The common case: one office or subnet, one collector, and a PAC file handed out by DHCP so clients auto-route AI-provider traffic through it with zero per-device proxy config. This is the fastest path to a working deployment.

What you'll end up with

   clients (laptops, servers, VMs)          collector host (Linux)
   ─────────────────────────────            ──────────────────────
   fetch proxy.pac via DHCP opt 252 ──────► PAC server :9443
   AI-provider domains → PROXY :8080 ─────► mitmproxy :8080  ──► providers
   everything else → DIRECT                 PDP :8000 (loopback)
                                            uplink 443 → kilasec.com

Clients ask DHCP where the PAC file is, fetch it, and from then on send only AI-provider domains to the collector. All other traffic goes direct.

Prerequisites

• A Linux host (systemd, amd64/arm64) on the same LAN as your clients, reachable on :8080 and :9443. See Sizing.
• Control of your DHCP server (to set the PAC URL via option 252) — or another way to set the system PAC/WPAD URL (GPO, MDM).
• Ability to distribute the collector's CA to clients — see Trusting the CA. Do this first, on a pilot group.

Step 1 — Install and approve the collector

Follow Install a collector: run the one-liner on the Linux host, then approve it in the dashboard under Collectors (or Fleet health for staff). It won't inspect traffic until approved.

Once approved, open the collector's detail panel in the dashboard. It shows the three things you need next: the PAC URL, the CA certificate download, and a verify command.

Step 2 — Distribute the CA (pilot group first)

Push the collector's CA to a small pilot group before anything else — see Trusting the inspection CA. If you route traffic before the CA is trusted, clients get TLS warnings on every AI call.

Step 3 — Point DHCP at the PAC file

The collector serves its PAC at:

https://<collector-lan-ip>:9443/proxy.pac

Hand that URL to clients via DHCP option 252. Examples:

ISC dhcpd (dhcpd.conf):

option wpad-url code 252 = text;
option wpad-url "https://192.168.10.20:9443/proxy.pac";

Windows DHCP — add a Predefined Option 252 (String) with the URL, then set it at the scope or server level.

MikroTik / pfSense / other — set DHCP option 252 to the PAC URL string.

The Setup Network page in the dashboard generates the exact snippet for common DHCP servers — copy it from there rather than hand-typing.

The PAC file only routes the domains in your scope (the AI providers) to the proxy; everything else it returns DIRECT. So turning this on does not put your whole network through the collector — only AI-provider traffic.

Step 4 — Verify

On a pilot client that has both the CA trusted and the PAC applied:

1. Renew DHCP (or reboot) so it picks up the PAC URL.
2. Make a real AI call — open a tool that hits a provider, or run the verify curl from the collector's detail panel.
3. Within ~60 seconds the request appears in Live Traffic in the dashboard.

If it doesn't show up, see Collector is offline and the troubleshooting notes on the Setup Network page (proxy reachability, CA trust, scope).

Step 5 — Start in observe mode, then tighten

Ship with a permissive policy first (default allow/log, redaction on for obvious secrets). Watch Live Traffic and Agents for a few days to learn what's actually on your network — which providers, which agents, which users. Then add deny/require_approval rules deliberately. See Managing policy and Writing policy rules.

Step 6 — Expand

Once the pilot group is clean, widen the CA distribution and the DHCP scope to the rest of the site. Nothing about the collector changes — you're just adding clients.

Scaling beyond one subnet

If clients live on multiple VLANs/subnets that can't all reach one collector, run a collector per subnet (each enrolls separately) or route via your existing proxy — see Explicit-proxy chaining.