kilasec docs

How it works ​

This page follows a single AI request from the moment an app on your network makes it to the moment the dashboard shows the decision. If you understand this path, the rest of the product follows.

The request lifecycle ​

  app on your network                collector (on your LAN)                provider
  ───────────────────                ───────────────────────                ────────
                                                                         
  1. HTTPS to api.openai.com                                            
     (routed via PAC/proxy) ───────► 2. mitmproxy :8080                 
                                         terminates TLS with a          
                                         per-connection cert signed     
                                         by the collector's CA          
                                                                        
                                      3. request normalized →           
                                         POST /evaluate (PDP :8000)     
                                         first-match-wins over your     
                                         policy rules                   
                                                                        
                                      4. verdict:                        
                                         allow → 6. re-encrypt, forward ─► provider
                                         redact → mask fields, then 6.  ─► provider
                                         deny → request stops here       ✕
                                         require_approval → held up to 60s
                                                                        
                                      5. decision (redacted) buffered   
                                         for the cloud uplink           
                                                                        
        dashboard ◄──── HTTPS ──────  cloud control plane ◄──── uplink every ~10s

Step by step:

  1. A client makes an AI call. Any app, agent, browser, or CLI on the network makes an ordinary HTTPS request to a model API. It reaches the collector because the network is configured to route AI-provider traffic through it — via a PAC file handed out by DHCP, or an explicit proxy setting.

  2. The collector terminates TLS. mitmproxy on :8080 decrypts the request. It presents a certificate minted on the fly, signed by a CA the collector generated on first run. For this to work without browser warnings, that CA must be trusted on the client — this is the one piece of setup that touches devices, and it's usually done once via MDM/GPO. See Trusting the CA.

  3. The policy engine evaluates it. The decrypted request is normalized (agent, destination, action, user identity, and a scan of the body) and handed to the Policy Decision Point (PDP) on loopback :8000. The PDP walks your rules top to bottom, first match wins, and returns a verdict.

  4. The verdict is applied in-line:

    • allow — the request is re-encrypted and forwarded to the provider unchanged.
    • redact — matched secrets/PII are masked in the body, then the request is forwarded. The provider only ever sees the masked version; the original stays on-prem.
    • deny — the request is stopped at the collector. It never reaches the provider.
    • require_approval — the request is held (up to 60 seconds) while an operator resolves it in the dashboard. Allowed → forwarded; denied or timed out → stopped.
    • log — allowed through, but recorded (used for observe-only rules).

  5. The decision is recorded. The collector writes the decision to its local audit log and buffers a sanitized copy for the cloud. Sanitization strips credentials and — unless you explicitly opt in — replaces prompt/response content with a metadata stub. The raw body does not leave the network.

  6. The request continues to the provider (unless denied), and the response returns to the client the same way.

  7. The cloud receives the decision. Every ~10 seconds the collector's uplink pushes buffered decisions to kilasec.com, which stores them per-tenant and fans them out to your dashboard's live feed within a few milliseconds.

What runs where ​

On the collector (your network):

  • mitmproxy :8080 — TLS termination and interception.
  • Policy engine / PDP 127.0.0.1:8000 — evaluates rules, bound to loopback only, never exposed to the LAN.
  • PAC server :9443 — serves the proxy auto-config file so DHCP can hand it to clients. This is the only port the collector exposes to the LAN besides the proxy itself, and it serves the PAC file only.

In the cloud (kilasec.com):

  • The control plane (policy, identity map, audit history, collector fleet), the dashboard SPA at /app/, and the API the collector talks to.

Scope — what gets decrypted ​

Kilasec does not decrypt everything on your network. You define a scope: the list of destinations to intercept (the AI providers). Traffic to anything outside the scope bypasses the collector entirely — routed direct, untouched, with no added latency and no decryption. This is both a performance choice (most traffic is never touched) and a privacy one (you're only inspecting AI calls, not your users' banking).

Failure behavior ​

  • If the cloud is briefly unreachable, the collector keeps enforcing policy locally and buffers decisions to disk; they flush when the uplink recovers.
  • If the collector itself is down, traffic behavior depends on your network config — see Sizing & failure modes for fail-open vs fail-closed and how to plan for it.

Next ​

Documentation for kilasec — the AI Agent Firewall.

© 2026 kilasec