Agent hosts

When the machines you want to inspect are servers or VMs running AI agents, scripts, or SDK apps — not browsers — there are two ways to route their traffic through a collector. Prefer the AI gateway.

Choose the lane

	AI gateway (recommended)	Proxy + CA config script
How	Kilasec Connect runs as a resident client; AI CLIs/SDKs point at a loopback gateway via ANTHROPIC_BASE_URL / OPENAI_BASE_URL	kilasec.com/host script sets HTTPS_PROXY + installs the inspection CA into every runtime bundle
CA on the host	None — no forged certs, nothing in any trust store	Required, in the system store and Python/Node bundles
Cert pinning	Can never break — the tool never sees a certificate	Breaks pinned clients
Latency	~direct speed — +4 ms at 1 KB, +30 ms at 10 KB	~2× direct — +137 ms at 1 KB, +156 ms at 10 KB
Use when	Any host that can run a resident client — this is the default for terminal and headless agents	A daemon isn't an option: immutable images, minimal containers, strict change control

Both lanes reach the same collector and the same policy engine — the gateway hairpins through the proxy by design, so traffic is inspected identically either way. The difference is how expensively that inspection is carried. See lane benchmarks for the measurements behind the table.

Terminal and headless agents should not use the proxy+CA path. They are short-lived processes: every claude / curl / python invocation opens a fresh connection and pays the MITM lane's full setup cost — CONNECT, device-TLS hop, and a forged-certificate TLS handshake — on every single request. The gateway is plain HTTP on loopback over a pooled upstream tunnel, which is why it lands within a few milliseconds of uninspected traffic. Go to Kilasec Connect to set it up.

Proxy + CA config script (fallback)

Use this only when the host can't run a resident client. It's configuration, not an endpoint agent: nothing resident is installed, and one flag reverts it.

Where you do this: On each agent host (Linux, sudo), running the kilasec.com/host script. The two values it needs come from the cloud dashboard at Collectors → your collector — the collector's LAN IP and its id (col_…). Scope (the decrypt allowlist) is managed in the dashboard at TLS Inspection.

curl -fsSL https://kilasec.com/host | sudo sh -s -- \
  --proxy <collector-lan-ip> --collector <collector-id>

On each host the script:

1. Trusts the inspection CA — into the system store and the paths Python (certifi / REQUESTS_CA_BUNDLE / SSL_CERT_FILE) and Node (NODE_EXTRA_CA_CERTS) actually read. This is the usual silent-failure gap: the system store alone doesn't cover most SDKs.
2. Points the machine at the collector — writes proxy env to /etc/environment (idempotent managed block) and a systemd drop-in, with a NO_PROXY that excludes localhost, the cloud host, and 169.254.169.254 (cloud metadata / credentials must never transit a proxy).
3. Verifies end-to-end — makes a request through the proxy and prints the collector's policy decision.

Restart your agent services (or re-login) afterward so running processes pick up the new environment. Undo everything with --uninstall.

How scope is applied

"Scope" is your decrypt allowlist — the AI hosts the firewall inspects (managed in the dashboard → TLS Inspection, see reference). The single most misunderstood part of host setup is where that scope gets enforced, because not every client can read a scope file.

Browsers and PAC-aware clients → scope on the host

Browsers (and any client that honors proxy auto-config) read the collector's PAC file:

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

That PAC is generated from your scope.yaml: its FindProxyForURL routes only in-scope hosts to the collector and returns DIRECT for everything else. This is a genuine host-side scope file — for the clients that support one. Push it via MDM/GPO, or hand it out by DHCP (see Single-site / PAC).

Agents and SDKs → scope on the collector

curl, the OpenAI / Anthropic / httpx / requests libraries, and Node do not read PAC files. They read the HTTPS_PROXY environment variable, which is all-or-nothing: you can send everything to a proxy with a bypass list, but there is no environment mechanism for "only proxy these hosts."

So the config script points all of their HTTPS traffic at the collector, and the collector applies scope:

• destinations in scope → decrypted, policied (allow / redact / deny / require-approval / log);
• everything else → CONNECT-tunnelled straight through, untouched (the collector never decrypts it).

This isn't a shortcut — for env-proxy clients it's the only correct place to enforce scope. A positive "inspect only these" allowlist can't be expressed on the host for these clients, so it lives at the collector.

The one host-side lever that works for agents

The bypass does work with env proxying. Pass hosts you want to skip entirely:

curl -fsSL https://kilasec.com/host | sudo sh -s -- \
  --proxy <collector-lan-ip> --collector <collector-id> \
  --no-proxy internal.example.com,10.0.0.0/8

Those are added to NO_PROXY, so that traffic never reaches the collector at all — useful for internal services and anything latency-sensitive you don't want proxied.

Trade-off to plan for

Because agents use HTTPS_PROXY, all of their HTTPS egress depends on the collector being reachable — if the collector is down, their outbound HTTPS stalls until it's back (not just AI calls). Browsers on the PAC degrade gracefully to DIRECT; env-proxy agents do not. Size the collector for the full egress volume of the hosts you point at it, monitor it, and see Sizing & failure modes before pointing production agents at a single collector.

Verifying

On the agent host — after running the script and restarting an agent process, make a real AI call. In the dashboard → Live Traffic it appears within ~60 seconds. If it doesn't, check that the CA is trusted for that client (SDKs need the certifi/Node paths, which the script sets), the collector is reachable on :8080, and the destination is actually in scope. See Collector is offline.