Privacy
Privacy by Design
Cerbera AI is built so that the default posture is privacy-preserving, and seeing employee prompts is a deliberate, auditable exception rather than the norm. This matters: the goal is security, not surveillance, and the program should be one your employees and works council can support.
No customer data is sold, and no model is trained on your traffic. Patterns that improve the rule catalog are learned anonymously, never by sharing one customer's data with another.
What Is Collected by Default
By default, nothing sensitive is sent to Cerbera. The only data collected is metrics, for example that a user used Claude. There is no prompt body and no response.
What Cerbera Never Captures
By default, the following never leave the device and never reach Cerbera:
- Prompt bodies and AI responses. By default these are never shared with Cerbera. Body logging can be turned on, but only where two settings agree, and reading captured content requires a data request.
- Non-AI traffic. Banking, health, personal webmail, and any destination outside the AI catalog is never decrypted or inspected. See Only Known AI Endpoints Are Decrypted.
- Keystrokes, passwords, and form inputs. Cerbera evaluates requests to known AI endpoints. It is not a keylogger and does not watch general browser activity.
- Activity on devices Cerbera is not installed on, such as a personal phone.
Logging a Body Requires Two Settings to Agree
If you want a rule match to carry the request body, two independent settings both need to be turned on:
- Organization-wide: logging is off for the whole organization by default. Turning it on also lets you choose a maximum body size to capture, and whether to log every tool invocation, not just rule matches.
- Per rule: each rule (allow, monitor, redact, or block) has its own "log body" setting. It only takes effect where the organization-wide setting is also on.
In other words, a rule cannot start capturing bodies on its own, and turning on the organization-wide setting does not retroactively make every rule start capturing bodies either. Both have to agree, which makes it hard to turn on broad body logging by accident.
You can also disable logging entirely for the organization. In that state, no rule can capture a body no matter how it is configured.
| Setting | Effect |
|---|---|
| Organization logging: off (default) | No rule can ever capture a body. |
| Organization logging: on, rule "log body": off | This rule still records only that it matched, not the body. |
| Organization logging: on, rule "log body": on | This rule's matches carry the request body, up to the configured size limit. |
Reading Flagged Content Requires a Data Request
Turning on body logging for a rule is only half the story: an admin still cannot casually browse what was captured for a specific person. To read a given employee's flagged content, an admin opens a data request: naming that employee and a reason.
- The request grants a time-boxed window (30 minutes) to view that person's content.
- Every data request is recorded in an append-only audit trail: who requested it, for whom, why, and when.
- Only one open request per employee at a time, so access cannot be quietly kept open indefinitely.
This gives you a real, checkable answer to "who looked at this person's prompts, and why" rather than a policy you have to take on trust.
What an Alert Carries
By default an alert records only that a rule matched, for which user, at what time. Whether the request body is attached depends on the combination described above:
- Alert only (the default outcome for any rule without body logging enabled): the rule matched, for this user, at this time. No body, no response.
- Body attached: only when both the organization-wide setting and that rule's own setting are on, and only viewable by an admin through a data request.
See Rules for where the per-rule logging setting lives.
Recommended Approach
Start with metrics only
Leave organization-wide logging off while you calibrate rules against alert metadata alone: which rule matched, for whom, how often.
Turn on body logging narrowly, if you need it
If a rule needs tuning and metadata is not enough, turn on organization-wide logging and enable "log body" for that one rule, then use a data request to review a specific case.
Roll out privacy-first
For broad deployment, keep organization-wide logging off (or scoped to as few rules as possible) once rules are well calibrated, so the system runs privacy-by-design.
Note on Token Metrics
Cerbera AI can give rough, fleet-level token usage, with an important caveat: tokens are not comparable across providers (a Claude token is not a ChatGPT token is not a Gemini token), and usage outside the device (for example on a phone) is never captured. Treat token figures as broad orders of magnitude, not exact accounting. This is roadmap rather than a precise feature today.