Skip to content

Repository files navigation

Cerberus — Client Instrumentation Packages

Instrumentation for API and AI agent security monitoring: what your APIs served, what your agents called, and what your models spent.

These are the libraries and gateway policies you add to your application, or place in front of it, so that a request, an MCP tool call, or an LLM call becomes something you can see. Each integration targets a different runtime and they all emit the same event schema, so they are interchangeable and can be mixed in one deployment.

Values under known sensitive key names are redacted in the client, and source IPs are HMAC pseudonymized when a secret key is configured, both before anything is transmitted.

Looking for the backend/platform (event ingestion, processing, dashboards, infrastructure)? That lives in the separate cerberus-int repository.

Guides

Background on what these packages are for, independent of which one you use:

  • Securing MCP servers: tool poisoning, prompt injection that becomes a tool call, excessive agency and exfiltration by chaining. Why network controls miss them, what to record, and how it maps to OWASP.

Packages

Package What it's for Runtime Distribution
cerberus-core Shared sanitization + PII-hashing utilities used by the Python integrations (SENSITIVE_KEYS, sanitize_dict(), hash_pii()) Python PyPI
cerberus-django Django middleware that captures HTTP request/response metadata and streams it over WebSocket — a one-line MIDDLEWARE addition Python · Django PyPI
cerberus-mcp Drop-in FastMCP replacement that instruments MCP tool / resource / prompt calls Python · MCP (FastMCP) PyPI
cerberus-flex-gateway Custom policy for MuleSoft Anypoint Flex Gateway — captures and forwards request metadata with no application code changes Rust → WASM (wasm32-wasip1) Prebuilt bundle → customer's own Anypoint Exchange (INSTALL.md)
cerberus-envoy-ai-gateway OTLP trace bridge for Envoy AI Gateway — converts the gateway's LLM + MCP telemetry into Cerberus events, deployed beside the gateway with a few OTel env vars Python · OTLP/HTTP PyPI / container image

Shared test fixtures: parity-fixtures — language-agnostic YAML cases that keep the Python and Rust sanitization logic byte-for-byte consistent.

Which one do I need?

  • Django appcerberus-django (depends on cerberus-core)
  • MCP server (FastMCP) → cerberus-mcp (depends on cerberus-core)
  • Envoy AI Gateway in front of LLM providers / MCP servers → cerberus-envoy-ai-gateway (depends on cerberus-core)
  • Any API / non-Python stack / no code changescerberus-flex-gateway deployed in front of your service
  • Building a new integration → reuse cerberus-core's sanitization contract and the shared event schema

How they fit together

  • All integrations emit the same event payload (CoreData / MCPEventData), so the Cerberus backend (event_ingest) needs no per-client changes.
  • Sanitization happens before any data leaves the client, via cerberus-core (Python) or its ported equivalent in the Rust gateway. Redaction matches key names against SENSITIVE_KEYS, so it catches the usual suspects rather than inspecting values. Source-IP pseudonymization is HMAC-SHA256 and requires a configured secret key; without one, IPs are sent in the clear.
  • The Flex Gateway policy re-implements the sanitization logic in Rust (there is no shared crate across languages). Parity is enforced by parity-fixtures: cerberus-flex-gateway/tests/parity_runner.rs and cerberus-django/tests/test_parity.py consume the same YAML cases, so any drift fails CI. (cerberus-envoy-ai-gateway imports cerberus-core directly, so it needs no parity runner.)
    • ⚠️ If you change SENSITIVE_KEYS (or other sanitization rules) in cerberus-core, update the matching fixture in the same PR.

Development & publishing

  • The Python packages build with uv build and publish to PyPI via ./publish_package.sh <package> (e.g. ./publish_package.sh cerberus-core).
  • cerberus-flex-gateway compiles to WASM and is distributed as a prebuilt bundle each customer publishes into their own Anypoint Exchange via the bundled install.sh (see INSTALL.md). Maintainers build the bundle with make bundle; CI attaches it to a flex-gateway-v* GitHub Release. It can also be dropped onto a Flex Gateway pod as a .wasm (Local mode).
  • cerberus-envoy-ai-gateway additionally ships as a container image (make image, push to your registry) with Kubernetes manifests in its deploy/ directory.
  • Repo-wide guidance (architecture, commands, conventions) for contributors and AI assistants: CLAUDE.md.

License

See LICENSE.

About

Client-side instrumentation for API and AI agent security monitoring. Django middleware, MCP server instrumentation, an Envoy AI Gateway OTLP bridge, and a MuleSoft Flex Gateway policy that capture request, tool-call and LLM traffic and stream it to Cerberus.

Topics

Resources

Stars

1 star

Watchers

1 watching

Forks

Releases

Packages

Used by

Contributors

Languages