Reading your detection numbers
Your dashboard shows how many requests were analyzed, flagged, and blocked. Here is what those numbers actually mean so you can read them with confidence.
How detection works
Every request runs through a four-tier inline pipeline, plus a cross-session correlator that runs afterward:
- 1.Regex (under ~1ms) — pre-compiled patterns catch the majority of known attacks instantly.
- 2.Embedding similarity (~5–15ms) — semantic match against known injection vectors (default threshold 0.75).
- 3.Intent classification (~15ms) — zero-shot NLI, plus base64/URL/hex decoding, Unicode normalization, and character-split detection for obfuscated payloads.
- 4.LLM escalation (rare, slower) — reserved for genuinely ambiguous inputs, routed through the AI Gateway.
The cross-session correlator then tracks prompt fragments per user over a rolling 7-day window to catch slow, multi-turn attacks that no single request would reveal. It is not a fifth inline tier — it runs after detection completes.
What the numbers mean
- ▸Coverage spans 24 attack categories across API, MCP, and AI-specific threats.
- ▸At scale, the ML classifier runs about 90% precision and 87% recall.
- ▸On an independent held-out set, recall is ~0.84 at a 0.5% false-positive rate.
Our CI shows "0 false positives" on a regression corpus. That is a stability gate that keeps a build from regressing — not an accuracy benchmark, and not "100% precision." Real-world accuracy is the held-out numbers above.
The semantic tier's very low false-positive rate holds for in-distribution traffic. On unusual, out-of-distribution benign inputs it rises to around 4%. Watch your own false-positive rate as you tune thresholds.
Deep ML tiers are opt-in
By default, detection uses the fast regex and semantic tiers with a curated pattern set. The deeper NLI and LLM tiers are off by default and can be enabled when you want maximum depth at the cost of latency.