On-prem / cloud boundary

The most important architectural property of kilasec: raw payload data never leaves the customer network. All the security-sensitive material — API keys, prompt contents, body fields — stays on the customer's collector. Only decisions (and, where the admin opts in, aggregate counts) cross to the cloud.

This page is the canonical list of what does and doesn't cross. It's the document a customer's security team will read before signing.

What crosses (collector → cloud)

Per-event:

• id — opaque event id (random).
• ts — unix timestamp.
• status — verdict (allow / log / redact / deny / require_approval).
• request.agent — agent name (resolved on the collector; never the API key).
• request.action — kind (tool_call / http_request / llm_prompt).
• request.destination.host / tool / model — type of the destination.
• request.destination.ip / port — destination network coordinates (since 369f3d2).
• request.args.method — HTTP verb only (GET / POST / …).
• request.args.path — URL path (no query string).
• request.metadata.source_ip / source_port — LAN source.
• request.metadata.identity — {name, hostname, mac, vlan, principal_type, display_name, labels.hostname_source}. MAC is optional and only included when DHCP integration is enabled.
• request.metadata.user_agent — UA string (sanitised; no auth tokens).
• decision.action — verdict (echoes status).
• decision.matched_rule — name of the policy rule that fired.
• decision.reason — string from the rule's reason field.
• decision.redacted_fields — names of fields that were redacted (["body.card_number"]), never values.
• decision.duration_ms — engine wall-clock time.

Aggregate (opt-in, periodic):

• Token counts (prompt_tokens, completion_tokens, cache_read_tokens, cache_write_tokens) — per-agent rollups for cost attribution.
• Estimated cost in USD — computed at the collector from the customer's pricing.yaml.
• DHCP lease snapshots — only when the customer runs the lease feeder.

What never crosses

Hard never:

• Authorization, x-api-key, api-key, apiKey, x_api_key — scrubbed in _classify_request before the event is built. The collector keeps the original on local audit.log.jsonl only.
• Request bodies — unless the policy author explicitly lists a body field for audit (e.g. for redact rules, the names of redacted fields ship; the values never do).
• Response bodies — kilasec proxies the request and forwards the response unchanged; the response stays between the agent and the provider.
• mitmproxy CA private key — generated on the collector at first launch, lives in /var/lib/kilasec/mitmproxy/. Never serialised over the cloud uplink.
• DHCP MAC addresses — only when the customer explicitly runs the lease feeder, and only the entries the customer wants to ship.

Soft (configurable, defaults to no):

• Prompt text — there's a audit_prompt_excerpts config flag for compliance use cases that need to see what was prompted. Off by default. When on, ships first 200 chars only and respects all redaction rules.

Why it's drawn here

A traditional cloud SIEM works by collecting raw events and analyzing them on the vendor's side. That model has two well-known weaknesses for a security product specifically:

1. The vendor becomes a high-value target. Centralising every customer's secrets / prompts / payload data into one place is a single point of catastrophe.
2. Customer compliance becomes harder. "We send raw prompts to a third party for analysis" is a non-starter for many regulated industries.

kilasec inverts this. The policy engine runs at the customer's network edge — it sees the raw request, makes a decision, and forwards only the decision. The cloud is a multi-tenant control plane, not a multi-tenant data lake.

The trade-off: the cloud cannot reconstruct what an agent actually said to a provider. It knows that something happened, what kind, with what verdict — never what was said. For incident forensics that need the original content, you SSH into the collector and read audit.log.jsonl (which lives on the customer's host, encrypted at rest if they configured that).

Practical implications for operators

Backups. The cloud holds decisions and metadata, not source data. Your collector's local audit log is the canonical record. Back it up if you care about long-term forensics.

Incident response. When a customer asks "show me what request triggered this redact", the answer comes from the collector, not the cloud. The cloud dashboard shows the fact of the redaction.

Data retention. The cloud audit table can hold years of decisions with no compliance concerns — there's no PII in it. (Verify with grep -irE "[A-Z0-9]{20,}" /opt/agentfw/data/cloud.db once in a while to confirm no api-keys leaked through a misconfigured rule.)

Egress firewall. The collector talks to kilasec.com/api/* over HTTPS. If your customer firewalls outbound, they only need to allow that. No other domains required.

Threat model summary

• A compromise of kilasec.com reveals: decisions, metadata, customer org names, IPs, hostnames. Does not reveal: API keys, prompt content, response content, mitm CA private keys.
• A compromise of a customer's collector reveals: everything for that one customer. Same blast radius as compromising any other host on their LAN.
• A compromise of an admin's session cookie reveals: read access to that one tenant's decisions + write access to that tenant's policy. No access to other tenants.

→ Up next: see the API reference for the exact wire format of every endpoint.