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.

Where you do this: Four surfaces, walked step-by-step below.

• On the collector host (Linux, sudo) — install and verify.
• In the cloud dashboard (kilasec.com/app/) — approve the collector and copy the PAC URL, CA cert, and verify command from Collectors → your collector. Requires the tenant_admin role. Setup Network generates the DHCP snippet.
• On your DHCP server — set option 252 to the PAC URL.
• On client devices (pushed via MDM / GPO / Jamf / Intune) — trust the collector's CA before you flip routing.
• On your egress firewall — block outbound UDP 443 (QUIC), or HTTP/3 clients silently bypass inspection. See the warning box below.

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

On the collector host: run the one-liner from Install a collector.

In the dashboard → Collectors: approve it. It won't inspect traffic until approved. Once approved, open Collectors → your collector — the detail panel 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)

Pushed to client devices via MDM / GPO / Jamf / Intune. Do this on 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

On your DHCP server. 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.

In the dashboard → Setup Network 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 the client picks up the PAC URL.
2. Make a real AI call — open a tool that hits a provider, or run the verify curl from Collectors → your collector in the dashboard.
3. In the dashboard → Live Traffic: within ~60 seconds the request appears.

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

Block QUIC (UDP 443), or HTTP/3 traffic bypasses the collector

The collector intercepts as an explicit HTTP proxy over TCP (the browser issues CONNECT). HTTP/3 runs over QUIC, which is UDP — a browser speaking HTTP/3 sends packets straight to the provider on UDP 443, never touching the proxy. Cloudflare-fronted services (including ChatGPT and Claude) advertise HTTP/3, so a client that uses it will silently skip inspection — you'll see the provider's real certificate and nothing in Live Traffic.

Close the gap one of two ways:

1. On your egress firewall — block outbound UDP 443 (recommended). QUIC then fails to establish and browsers automatically fall back to HTTP/2 over TCP — straight through the collector. One firewall rule covers the whole site.
2. Via GPO / MDM on client devices — disable HTTP/3 in managed browsers (Edge/Chrome: QuicAllowed=false; Firefox: network.http.http3.enabled=false).

If AI traffic is mysteriously not appearing in Live Traffic even though the PAC and CA are correct, QUIC is the usual culprit — check for UDP 443 egress.

Step 5 — Start in observe mode, then tighten

In the dashboard → Policy Rules. 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.