Explicit-proxy chaining

If you already funnel outbound traffic through a forward proxy or secure web gateway — Squid, a NGFW (Palo Alto, FortiGate), Zscaler, or similar — you can route AI-provider traffic through the collector without touching DHCP or client PAC settings. You chain the collector into the egress path you already control.

When to use this instead of PAC

• You have an existing egress proxy every client already uses.
• You'd rather not manage a PAC file / DHCP option 252.
• You want AI inspection to sit inside the egress policy you already enforce.

If you don't already run a proxy, PAC / single-site is simpler — don't stand up a proxy just for this.

The shape

   clients ──► your existing proxy ──► collector :8080 ──► providers
              (routes AI domains        (inspects, decides,
               to the collector)         redacts)

Your proxy stays the client-facing endpoint. For the destinations in Kilasec's scope (the AI providers), it forwards to the collector as an upstream proxy; everything else it handles as it does today.

Configuring the chain

The exact syntax depends on your proxy, but the pattern is: for AI-provider domains, use the collector as the next-hop (parent/upstream) proxy.

Squid — a cache_peer plus an ACL that selects AI domains:

# The collector as a parent proxy
cache_peer 192.168.10.20 parent 8080 0 no-query no-digest name=kilasec

# Match the AI providers you want inspected
acl ai_providers dstdomain .openai.com .anthropic.com .githubcopilot.com .deepseek.com
acl ai_providers dstdomain .googleapis.com .bedrock.amazonaws.com

# Send those through the collector; everything else goes direct
cache_peer_access kilasec allow ai_providers
never_direct allow ai_providers
cache_peer_access kilasec deny all

NGFW / SWG (Palo Alto, FortiGate, Zscaler, etc.) — create an egress/forwarding rule that sends the AI-provider URL category or explicit domain list to the collector's IP on :8080 as the next proxy hop. Use the same domain list as your Kilasec scope so the two agree on what's inspected.

Keep the proxy's domain list and Kilasec's scope in sync — if the proxy forwards a domain the collector doesn't expect, or vice-versa, you get gaps. Manage the canonical list in Kilasec's Scope and mirror it in the proxy.

CA trust still applies

Chaining changes how traffic arrives, not who terminates TLS — the collector still decrypts, so clients still need to trust the collector's CA. If your existing proxy already does its own TLS interception, you now have two interceptors in the path; decide which one inspects AI traffic (usually the collector) and make sure the chain doesn't double-intercept in a way that breaks the cert path.

Verifying

From a client behind the proxy, make an AI call and confirm it appears in Live Traffic. If it doesn't, check: the proxy is actually selecting the AI domains, the collector is reachable from the proxy on :8080, and the CA is trusted on the client. See Collector is offline.