How It Works
The Local Proxy
Cerbera AI installs a lightweight local proxy on each device. It behaves much like a VPN client, except instead of routing traffic to an internal network, it routes traffic destined for AI tools through a local inspection step before the request reaches the provider.
When a user (or an agent) talks to ChatGPT, Claude, Claude Code, or an MCP server, the request passes through this local program first. That is where monitoring, redaction, and blocking happen. Whether the traffic comes from a browser tab or a local application makes no difference, because the proxy is positioned in the request path itself.
TLS Interception
AI traffic is encrypted, so the proxy performs HTTPS interception (TLS offloading) to inspect it. This requires a certificate to be trusted on the device, which is installed automatically through the MDM into the trust store.
Cerbera is a cybersecurity company, and the certificate model is designed so that compromising Cerbera does not compromise your fleet:
- Cerbera does not hold a root CA. Each device generates its own certificate locally.
- Because the leaf certificate is per-device, a breach of Cerbera does not yield a key that can intercept your traffic.
- The only realistic supply-chain vector would be a malicious software release pushed through your own MDM, which requires your action to deploy. That risk is common to any vendor whose software you deploy.
Like any new layer, a man-in-the-middle proxy adds surface area. Cerbera mitigates this with per-device certificates, signed rule updates, third-party penetration tests, and SOC 2 and ISO 27001 certification. See Privacy.
Rules, Signed and Cached
Rules are defined in the Cerbera cloud. The agent pulls them periodically and verifies their signature before applying them, so a tampered rule set is rejected.
The agent operates within a fixed set of constraints. It cannot, for example, be redirected to talk to a server other than Cerbera. This limits what a local attacker can alter on the client.
Offline Operation
Because rules are cached and signed locally, the proxy keeps working even if Cerbera is unreachable. If the Cerbera backend were ever down, enforcement continues with the last known good rule set.
Allow-by-Default for Unknown Traffic
Cerbera AI recognizes the APIs of the AI tools it tracks. Its enforcement is allow-by-default for traffic it does not recognize: anything that is not explicitly identified as a known AI endpoint is permitted.
This has an important safety property. If an AI provider changes its private client API overnight without warning, the new traffic is simply not recognized as that tool and is allowed through, rather than blocking your users. Cerbera then updates the rules to match the new format. In practice these changes are usually visible in advance because providers A/B test with a subset of users before a full rollout.
"Block by default" for AI tools means blocking the AI solutions Cerbera knows about that are not on your allow list. It does not block general internet traffic. A brand-new agent nobody has catalogued yet is allowed until it is added.
Performance
The proxy is built to be invisible in normal use:
| Metric | Latency |
|---|---|
| P75 | under 1 ms |
| P99 | around 10 ms |
At the API layer this is imperceptible, and on AI tools that take seconds to respond it is far below the noise floor. As you add more rules, evaluate latency as part of rollout, the same way you would tune a firewall rule set.