Auth says it’s valid. Cerberus asks if it’s still behaving like itself.
Cerberus observes authenticated machine identities — API keys, service credentials, the keys your agents carry — after authentication, and detects when one diverges from its own behavioral history. It works from operational telemetry, never from content.
In production today it runs one detector, narrow by design: distributed credential fan-out.
- Observation-only
- Outside request path
- No prompts/responses
- No raw credentials
- No raw IPs
01 · The gap
Authentication answers “is this credential valid?” Cerberus answers “is this valid identity still behaving like itself?”
When a credential is copied, resold or lifted from a build system, every request it makes still authenticates, still passes its checks and still fits under its limits. Nothing in front of your service compares an identity with its own past.
Keep every one of these controls. Cerberus is a layer after authentication, not a replacement for anything in front of it.
Authentication
Is this credential valid?
A copied or stolen key passes. It is exactly as valid as the original.
Secret scanning
Was it exposed in code?
Helps before a credential is used. A key copied from runtime, logs or a support workflow may never appear in a commit.
Rate limiting
How much can it do?
Constrains volume. Careful misuse stays under the ceiling.
Behavior after authentication · Cerberus
Is this valid identity still behaving like itself?
Compares each authenticated identity with its own behavioral history — the one question none of the layers above it asks.
02 · Architecture
Beside your request path. Never in it.
Cerberus is integrated where your service already sees the credential, and everything after that point is asynchronous. A Cerberus outage cannot slow, block or break a request of yours, because no request of yours ever waits on Cerberus.
Illustrative · authentication stays wherever it already runs in your stack · the branch to Cerberus is always asynchronous
The request never waits.
Nothing Cerberus does is on the path between your caller and your response.
Fingerprinted in your process.
The Python package on PyPI, a LiteLLM callback, or the HTTP API.
Bounded and counted.
If Cerberus is unreachable, events wait in the queue, then drop and are counted.
Evidence, not a dashboard.
An alert to your Slack, with a link to mark a change as expected, and a status API.
03 · Current detection
One detector is live: distributed credential fan-out.
This is the production detector today, and it is narrow by design. It looks for one identity suddenly operating from many more sources than its own history, with less work per source, dispersed across networks, sustained over consecutive hours — the shape a credential makes once it has been shared, resold or lifted. Every condition below must hold at once, judged only against that identity’s own baseline.
The thresholds are conservative starting values, published here so they can be checked. They have not yet been calibrated against a large body of production traffic.
Illustrative · one identity, hourly windows · the conditions are the live rule’s
- AMore sourcesDistinct sources in the hour reach at least 3× the identity's usual peak.
- BLess from eachRequests per source fall to 40% or less of its usual level — the same work, spread wider.
- CEnough of themAt least 10 distinct sources in the hour, so a small wobble never qualifies.
- DSustainedAll of the above for 3 consecutive hours. A single spike never alerts.
- EAcross networksIn the hour, distinct sources divided by distinct network blocks (IPv4 /16, IPv6 /48) is 2 or less, per address family: spread across many networks, not packed into a few.
Result
All five held together: one alert, carrying the evidence.
The identity’s fingerprint, what changed against its usual peak, how many network blocks, how long it held and why the rule fired — delivered to your configured Slack channel.
Cerberus remains observation-only. Rotation, revocation or anything else happens in your own platform, by your decision.
Evidence delivery
What an alert looks like.
A synthetic example, produced by the production alert builder from invented values. It contains no customer data. The structure and the wording are exactly what arrives in your configured Slack channel.
Unusual API key behavior detected
913f5b46ab7e770d9c534d8efc1404e7Look this up in your local fingerprint index.- What it meansOne identity's traffic fanned out: many more distinct sources than its own history, less work from each, spread across networks, and sustained for consecutive hours. Every figure is measured against that identity alone.
- What it does not meanAn alert does not mean the credential is compromised. Cerberus sees the shape of the traffic, not who is behind it.
- What decides itYour own ground truth is required: who holds the credential, and what changed in your deployment. Only you can confirm whether it was expected.
Known limits
What Cerberus does not claim.
Published before you integrate, so you can judge the fit yourself. Every entry is pinned to the code that makes it true, and changes with it.
What the current detector can miss
- Theft used from a single source.One new address beside an identity's usual ones barely moves its source count. The rule needs many more before it fires.
- Misuse from one or two extra sources.A finding needs at least 10 distinct sources in an hour and 3× the identity's usual peak. One or two more never get there.
- Activity behind the same NAT.A thief sharing an address the identity already uses adds nothing new to count, and more requests from the same place raise no alert.
- Low-and-slow misuse.The baseline is a trailing window, so misuse that grows gradually is absorbed into it, an hour at a time.
- Behavior already present while the baseline forms.If a credential is already being misused while its baseline is established, that activity can be learned as normal. Start from credentials believed to be clean; rotating first helps where practical.
- Identities whose normal traffic is already highly dispersed.The rule is multiplicative: a key normally seen from 200 addresses needs roughly 600 to fire. These are often the largest customers.
Legitimate changes can look the same
Autoscaling onto new networks · Regional expansion · Migrations · Replatforming
Each can put an identity on addresses it has never used, which resembles the pattern the detector watches. It alerts only when every condition holds at once; if one does, acknowledge it: one click covers the key for as long as you choose, and GET /v1/status lists anything currently suppressed, with a link to resume alerting on the ones you chose.
What Cerberus does not do
- Authenticate or authorize.Your identity provider and access policy still decide who gets in. Cerberus looks at what a valid identity does next.
- Proxy your requests.It never sits between a caller and your service. Telemetry is handed to a background worker and leaves on its own schedule.
- Inspect prompts or responses.No field is meant for a request's content: token counts, never tokens. Endpoint paths are expected as route templates; a live path sent in their place could carry personal data.
- Infer intent.It reports how an identity's behavior moved against its own history, in sources, volume and time. Why it moved is a judgment it leaves to you.
- Block or revoke credentials automatically.Cerberus remains observation-only. Rotation, revocation or anything else happens in your own platform, by your decision.
A detectable integration limitation
If an integration reports one address, nothing can fire.
A proxy behind a load balancer reports the balancer's address on every request unless it is configured otherwise. GET /v1/status marks every key sitting below the detection floor, and once 12 or more keys on one account share a single address, Cerberus sends the notice unprompted.
04 · How it works
A behavioral model of every identity, built from telemetry you already have.
Cerberus reads operational metadata about each authenticated request — never the request itself — and keeps a per-identity history. Six dimensions make up the model. The status beside each one says exactly what the production detector uses today.
- 01
Stable identity
LiveEach credential becomes a stable fingerprint, computed in your process. Every observation is attributed to that identity, so its history is its own.
- 02
Source & network behavior
LiveHow many distinct sources use the identity each hour, how much each of them does, and how those sources spread across networks and address families.
- 03
Timing & history
LiveBehavior is judged in hourly windows against a trailing history, and a change has to persist across consecutive hours before it counts.
- 04
Behavioral baseline
LiveCerberus learns each identity's own normal and will not judge it until it has 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). Nothing fires while it is still learning.
Gate includes 40 active hours
- 05
Route & tool behavior
Collected — not a detection signalThe route template is recorded on every event. A route-novelty detector is built but not enabled for any account, and tool-level telemetry for agents is not collected today.
- 06
Evidence-first alerts
LiveOne message per incident, carrying the identity fingerprint, what changed, what normal was, how long it held and why the rule fired. You decide what happens next.
05 · Who it is for
For environments where identities already have a history.
The qualification is not company size. It is whether your service sees the same identities again and again, with enough context to tell one week from the next.
What qualifies
Stable identity
The same credential, request after request.
Source context
The caller's address, its network and its wider block.
Timestamp
When each request happened.
Recurring traffic
Enough to judge: 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).
Where that history usually exists
Not a fit yet: identities that are short-lived, single-use or seen too rarely to have a history. Validating the current detector also needs identities that naturally reach your service from multiple source addresses or hosts over time; a single host or a shared NAT can validate the integration, but not the current fan-out detector. If an environment cannot support it, we say so before validation begins.
- 01AI and MCP gateways
- 02API gateways
- 03Inference infrastructure
- 04Machine and non-human identity platforms
- 05Agent orchestration platforms
- 06Internal enterprise AI platforms
- 07Zero-trust and network infrastructure
- 08High-volume machine-to-machine services
06 · Deployment
From validation to production.
Every engagement starts with a technical validation on your own traffic. Production scope and commercial terms are agreed directly before deployment.
01
Technical validation
Prepared teams can complete technical onboarding in roughly 30 minutes.
- Integrate the Python SDK, the LiteLLM callback or the HTTP API beside a real traffic path.
- Configure the 3–5 persistent identities the pilot will use.
- Run the preflight and verify transport before baseline traffic begins.
- Agree the validation criteria before the pilot begins.
The 30 minutes is integration work, not detection. Normal production traffic then builds each identity's behavioral history, and nothing is judged until it has 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).
02
Production
- Continuous observation, off the request path.
- Evidence-first alerts, delivered to your configured Slack channel.
- Production identities and environments in scope.
- Commercial scope agreed before conversion.
03
Platform and enterprise
- Larger identity populations.
- Multiple environments or business units.
- Integration at the gateway or platform level.
- An implementation and data-handling review.
Pricing
Production and platform pricing is scoped directly around deployment size, environments and integration requirements. There is no self-serve tier and no public price list.
07 · Privacy
Built to collect behavior, not your content.
Cerberus is designed to collect behavioral metadata rather than prompts, responses, raw credentials or raw IP addresses. Identity and source are fingerprinted before anything leaves your service.
01
Raw credentials stay with you.
Each key becomes an HMAC-SHA256 fingerprint inside your process, under a salt issued to you once that Cerberus does not store.
02
Raw source addresses stay with you.
The address, its network and its wider block are fingerprinted the same way, before anything is queued.
03
No prompts or responses, by design.
No field is meant for a request's content: token counts, never tokens. A field you fill yourself, such as the endpoint path, could still carry personal data if a live path is sent instead of a route template.
04
Fingerprints and behavioral metadata.
Counts, timings, status and a route template per request, derived locally and sent off the request path.
Raw events are scheduled for deletion thirty days after receipt, hourly aggregates after ninety: a schedule, not a hard deadline. SDK releases with health reporting also send a short operational report about themselves — counters, never anything about a request. The per-request field list is in the Trust Center, and the privacy notice lists both kinds in full.
Know when a valid identity stops behaving like itself.
Start with a technical validation on your own traffic. We will tell you plainly whether Cerberus fits.