Trust Center

What Cerberus does, what it does not, and how to check.

Every claim on this site is meant to be checkable. Detection thresholds on these pages are read from the same values the detector uses, and the known limits are published beside the detector they constrain.

01What Cerberus does

Builds a behavioral history for each authenticated identity from per-request metadata — the closed field list in the privacy notice — not from prompts or responses.
Judges an identity only once it has a baseline: at least 500 requests across 40 active hours inside a rolling 7 days, with its busiest hours reaching 3 or more distinct sources (the 95th percentile of its hourly counts).
Runs one production detector, distributed credential fan-out, in hourly windows against each identity's own trailing history.
Sends one evidence-first alert when that detector fires, with a link to mark the change as expected, and reports current state through a status API.
Tells you, unprompted, when an integration's traffic has a shape that makes detection impossible: 12 or more identities on one account all arriving from a single address.

02What Cerberus does not do

Block, delay, rate-limit or modify any request. It is not inline and has no enforcement path.
Rotate or revoke credentials. Every alert ends with a decision that is yours, in your own platform.
Receive prompts, model responses, request or response bodies, raw credentials or raw IP addresses.
Provide a dashboard. The alert is the product; the status API is the record.
Run any detector other than fan-out. Route-novelty detection is built but not enabled for any account, and tool-level telemetry for agents is not collected.
Replace authentication, secret scanning or rate limits. It answers a different question, after them.

03Methodology and limits

The live detector fires only when several conditions hold together for consecutive hours: an identity used from far more sources than its usual peak, each source doing much less, spread across networks rather than concentrated in one. The exact conditions and thresholds are on the detection section.

The thresholds are conservative starting values and have not yet been calibrated against a large body of production traffic. What the detector cannot see — slow ramps, abuse already present while a baseline forms, identities already used from many places — is listed under Known limits, each entry pinned to the code that makes it true.

04Data handling

Cerberus receives a closed set of fields per request, with identity and source fingerprinted on your side, and supported SDKs also send a short operational report about themselves. Both are described field by field in the privacy notice, which also states retention, deletion and erasure.

How data is stored, which secrets exist, who can access what, and what a breach would expose are on the security page.

What Cerberus receives

Twelve fields per request, nothing else. The ingest endpoint rejects any unknown field by name, so this list is enforced in code rather than promised in prose.

Timestamptsstring2026-08-04T14:03:11Z: When the request happened, ISO 8601.Everything is bucketed by hour. A timestamp more than an hour in the future is rejected as clock skew.
API key fingerprintkey_fpstring9f2b41c7e0a85d6314bb07e29c4af1d8: HMAC-SHA256 of the API key under your own salt, truncated to 128 bits and hex-encoded.This is the field that makes the product possible without the key itself. The server rejects anything that is not 32 hex characters, so a real key cannot be sent by accident.
Endpointendpointstring/v1/chat/completions: Which route was called.A route template, not a live path. Ids in the path are your data, not ours — the validator rejects the ones it can recognise, and your terms require templates.
Input tokenstokens_ininteger1180: Prompt tokens.A count, never the content. No field on this list is meant to carry a prompt.
Output tokenstokens_outinteger260: Completion tokens.Same as above: the size of the response, never the response.
Latencylatency_msinteger940: How long the request took.Part of the per-key usage shape. Not currently used by the fan-out rule.
HTTP statusstatusinteger200: The HTTP status you returned.Distinguishes a key being used from a key being rejected.
Client address fingerprintip_fpstring3c81a7be55d0f42a9e6c1b7380dd24f5: Fingerprint of the caller's IP address, same construction as key_fp.Counting distinct IPs per key per hour is the core of the rule. The address itself never leaves you.
Network fingerprintip_net_fpstringb04e9d217fc6a3358821e05c7ab4dd9f: Fingerprint of the surrounding network — /24 for IPv4, /64 for IPv6.Distinguishes forty addresses inside one allocation from forty scattered across the internet. The v6 prefix differs because a single /64 is one ordinary customer assignment holding 2^64 addresses.
Network block fingerprintip_block_fpstring7e15c8a0439bd6f2a1c93e470b28df61: Fingerprint of the wider block — /16 for IPv4, /48 for IPv6.The second, coarser dispersion measure. Together with ip_net_fp it is what separates a real fan-out from one noisy datacentre.
Address familyip_familystringv4: Either "v4" or "v6".The prefix sizes above are not comparable between families, so the family has to travel with them. Everything downstream is computed per family.
Costcostnumberoptional0.0041: What the request cost you, if you want to send it.The only optional field on the list, and the only one Cerberus does not need.

There is no field for a prompt, a response, an API key, or an IP address. The four fingerprints are HMAC-SHA256 under a salt that stays on your side and is never sent, so Cerberus cannot reverse them — not for you, and not for anyone who compels us.

Our SDKs also send a short report about themselves — counters such as events delivered and dropped, never anything about a request. The privacy notice lists it in full.

05Integration reference

Integration runs where your service already sees the credential. Ingest tokens are issued when technical validation starts.

Python

The cerberus-keys package is on PyPI, for Python 3.11 and later.

pip install cerberus-keys

from cerberus_keys import Cerberus

cerberus = Cerberus(ingest_token=TOKEN, salt=SALT, endpoint_url=URL)

cerberus.record(api_key=key, ip=request.client.host,

endpoint='/v1/chat/completions',

tokens_in=1180, tokens_out=260, latency_ms=940, status=200)

You pass the real key and the real address: both are fingerprinted in your process, under your salt, before anything is queued. The ingest token and the salt are issued when technical validation starts; the salt is shown once.

LiteLLM proxy

litellm_settings:

callbacks: cerberus_keys.litellm.handler

general_settings:

use_x_forwarded_for: true # required, not optional — see below

Both blocks are required. Without use_x_forwarded_for, LiteLLM reports the socket peer — behind a load balancer every request then carries the balancer’s address, the source count is permanently one, and the detector is inert while looking healthy. Cerberus checks for that shape and tells you.

Node.js and Express

A Node.js client with Express middleware is available to technical validation participants. It is not distributed through a public package registry; it is provided directly, with its checksum.

Confirm what arrived

curl -s -H "Authorization: Bearer $CERBERUS_TOKEN" \

https://api.cerberushq.dev/v1/verify

events_received counts what arrived and verdict says in a plain sentence what Cerberus read from it. A wrong salt, a local-time timestamp or a live path where a route template belongs all produce a cheerful 202 and attribute nothing correctly; verify makes that visible in the first minute instead of the seventh day.

06Security contact

Questions about security, privacy or a suspected vulnerability: hello@cerberushq.dev.