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.
Decryption happens locally on the device. Unlike a cloud secure web gateway, traffic is never routed to a Cerbera data center to be broken and inspected. The plaintext exists only in memory on the user's own machine, for the moment a request is evaluated against the rules, and is never written to disk or sent to Cerbera unless a rule with logging is explicitly enabled. See Privacy.
Only Known AI Endpoints Are Decrypted
Cerbera does not decrypt everything. It selectively intercepts traffic to the AI endpoints it recognizes and leaves all other traffic untouched. A request to a bank, a health portal, or personal webmail is never decrypted, never inspected, and never logged. It passes straight through.
This is the same "do not decrypt" principle that mature secure web gateways apply to sensitive categories, except Cerbera inverts the default. Rather than decrypting all traffic and carving out exceptions for sensitive sites, it decrypts only the narrow set of AI endpoints in its catalog and exempts everything else by default. See Allow-by-Default for Unknown Traffic.
The Certificate Model
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.
If Cerbera Were Breached
It is worth stating the worst case plainly. If an attacker fully compromised Cerbera's cloud, they:
- Could not decrypt your traffic. No root CA and no per-device private keys live in Cerbera's cloud, so there is no key to steal that would unlock fleet traffic.
- Could not redirect the agent to a different server. The agent runs within fixed constraints and will only talk to Cerbera.
- Would not find a store of your prompts. By default Cerbera holds only metrics, never prompt or response bodies. See Privacy.
The blast radius of a Cerbera compromise is limited by design, not by policy.
Like any new layer, a man-in-the-middle proxy adds surface area. Cerbera mitigates this with per-device certificates, authenticated rule updates, third-party penetration tests, and SOC 2 and ISO 27001 certification. See Privacy and Security & Trust.
Rules, Authenticated and Cached
Rules are defined in the Cerbera cloud. The agent authenticates to Cerbera over HTTPS with a per-device key and pulls the current rule set, re-fetching only what changed since the last check.
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 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: rule evaluation is signature-based (regex and binary logic) rather than a local model, so it adds negligible overhead next to the round trip to an AI provider, which itself typically takes seconds. The Rules page includes a performance view showing rule evaluation latency, so you can check the impact of your own rule set as you add to it, the same way you would tune a firewall rule set. See Rules.
Protocol Support
AI traffic rides on several transport protocols, and Cerbera handles each differently. The table below shows where Cerbera inspects traffic, where it passes it through untouched (so the connection still works, but no rule is applied), and where interception would break a connection.
| Protocol | Status | Notes |
|---|---|---|
| HTTP/1.1 | ✅ Inspected | The baseline. Fully parsed, so all rules apply. |
| HTTP/2 | ✅ Inspected | Negotiated over TLS via ALPN. Where an upstream only speaks HTTP/1.1, the request is translated transparently. |
| HTTP/3 & QUIC | ↪️ Passthrough | QUIC runs over UDP and is not decrypted today. It is passed through so traffic keeps working, but no rule is applied to it. |
| WebSockets | ✅ Inspected | Inspected after the HTTP upgrade, including over HTTP/2. |
| Known relayed clients (e.g. Docker Desktop) | ↪️ Passthrough | A small set of local processes that run their own trusted relay and cannot accept Cerbera's certificate are tunneled through without decryption instead of being broken. |
| HSTS | ✅ No impact | Works normally. Because Cerbera's leaf certificate chains to a CA trusted on the device via MDM, strict-transport-security does not trigger a warning. |
Certificate pinning is a separate case from the protocols above: a pinned app trusts one specific certificate issuer rather than the device trust store, so it rejects Cerbera's certificate even though the CA is trusted. The fix is to pass the host through. See Troubleshooting.