What is Kilasec
Kilasec is an AI firewall for your network. It inspects every call your users, agents, and vendor tools make to model APIs — OpenAI, Anthropic, Copilot, Gemini, Bedrock, Ollama, and anything else — and decides, in-line, what's allowed to leave.
It runs where you already enforce policy: on the network, not inside every application. There is no SDK to integrate and no agent to push to endpoints. You drop in one container, point your existing proxy or PAC file at it, and it starts seeing traffic.
The problem it solves
AI calls are now leaving your network from places you don't control:
- An engineer pastes a script — with a live cloud credential in it — into ChatGPT.
- A support team's AI agent forwards raw customer transcripts, SSNs and card numbers included, to a provider.
- A vendor tool nobody in IT has heard of starts calling
api.deepseek.comfrom a finance laptop. - A misconfigured eval loop burns thousands of dollars on a frontier model overnight.
None of these go through an SDK you can wrap. They're ordinary HTTPS requests to an API. The only place that sees all of them is the network.
How Kilasec is different
Most AI-security tools are libraries or gateways: you integrate them, and they cover exactly the code paths you remembered to route through them. Kilasec sits at the network layer and sees the traffic itself.
| SDK / gateway | Kilasec (network layer) | |
|---|---|---|
| Covers agents with no code change | ✕ must integrate each one | ✓ inherent |
| Catches browser & desktop paste-ins | ✕ | ✓ |
| Discovers unknown providers | ✕ | ✓ on first call |
| Redacts before data leaves the network | ~ in-app | ✓ at the edge |
| Real user + AD-group identity | ~ token-scoped | ✓ |
| Deploys without touching endpoints | ✕ per app | ✓ one container |
What it does, concretely
- Discover — decrypted inspection of 30+ model endpoints, classified on the fly (including providers not yet named). You see every AI call on the network and who made it.
- Redact — secrets, credentials, PII and card numbers are masked at the wire before the request reaches the provider. The original never leaves your network.
- Enforce — first-match-wins policy rules decide the verdict for each request: allow, deny, redact, require approval, or log. Rules can match on agent, destination, user, AD group, time window, and request content.
- Attribute — every request is mapped to a real user and directory group, from Active Directory, DHCP, or a CSV import — so a rule reads
allow group:engineering → api.anthropic.com, not a list of IPs. - Prove — every admin change and every blocked request is written to an audit log, with configurable retention from 30 days to 7 years, exportable for SOC 2, HIPAA, or your own change control.
Who it's for
The person who deploys and operates Kilasec is a network or security administrator — someone who already runs a proxy, a PAC file, or an MDM, and thinks in terms of subnets, CAs, and policy. This documentation is written for that person.
The two halves
Kilasec has an on-prem half and a cloud half, and the split is deliberate:
- The collector runs on your network. It terminates TLS, inspects and decides on every request, applies redaction, and forwards the request upstream. Raw request payloads never leave your network — redaction happens here, before anything is sent anywhere.
- The cloud (
kilasec.com) is the control plane: it holds your policy, your dashboard, your audit history, and your fleet of collectors. It only ever receives the decision about a request (with redaction already applied) — not the request body.
That boundary is the core of the security model. See How it works for the full request lifecycle, and On-prem / cloud boundary for exactly what crosses it.
Next steps
- New to the product? Read How it works.
- Ready to deploy? Start with Deployment models to pick the right topology, then Single-site deployment.
- Operating it day-to-day? The Admin guide is the operator's manual.