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.
The same visibility a tool like this provides already exists in tooling you likely run today. An EDR or VPN can already reveal browsing and activity patterns. Cerbera AI is not a new capability for your environment so much as a focused, privacy-conscious one. We can help frame this for works-council (CSE) discussions.
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.
Logging Is Opt-In and Auditable
If you want to log prompts or responses, it must be enabled in two separate places in the application. It cannot happen by accident, and it is auditable: who enabled it, for which alert, and when.
You can also disable logging entirely for the whole organization. In that mode the option no longer even exists in the app, and request and response data stay local on the user's device and never reach Cerbera.
| Mode | Where the data lives |
|---|---|
| Metrics only (default) | Only the fact that a tool was used reaches Cerbera |
| Logging disabled org-wide | Nothing is logged; the option is removed from the app |
| Local logging with consent | Logs stay on the user's device; shared only with explicit consent |
| Logged to Cerbera | Body attaches to the alert; requires double opt-in |
Local Logging With Consent
For a pilot, there is a middle ground that preserves consent. The agent can log locally on the device. Cerbera only ever sees an identifier. To inspect a specific event, Cerbera sends the user that identifier; the user finds the matching entry in their local logs, reads it themselves first, and chooses whether to share it back over Slack or email.
This gives a genuine in-between: you get the context needed to debug behavior during a pilot, but the employee controls disclosure of anything personal. Cerbera cannot retrieve the content on its own.
What an Alert Carries
When a rule matches in production, you choose what is attached to the alert:
- Alert only (default): the rule matched, for this user, at this time. No body, no response.
- Body logged locally: stays on the device, retrievable by the user via the identifier flow above.
- Body logged to Cerbera: attaches to the alert, only when explicitly enabled.
By default an alert carries only the fact that a rule matched.
Recommended Approach
Pilot with a consenting group
Start with users who understand the project. Local logging gives context to debug, without surveilling anyone.
Tune the rules
Use that context to calibrate rules so they fire on the right things.
Roll out privacy-first
For broad deployment, drop prompt access entirely so the system is privacy-by-design once rules are well calibrated.
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.