Skip to main content
What PromptGuard detects is listed on Threat Detection. This page explains how a scan reaches its decision.

​
The detection tiers

A scan runs its detectors in three tiers, in order, and stops early only when one finds something:
  1. The fast path: in-process pattern and heuristic detectors (injection, exfiltration, PII, secrets, URLs and the rest), plus a cache of verdicts for identical input. It runs in under 10 ms.
  2. The ML path: transformer classifiers for injection and toxicity. A request the fast path finds clean continues here by default, on every plan.
  3. The slow path: LLM-judge detectors, such as LLM Guard rules and multi-turn escalation. They run only when a project enables them, each under a hard timeout, and fall open to the earlier verdict when it runs out.
Each detector’s budget, and what was measured, is on Latency Budgets.

​
The four decisions

Each detector and policy rule ends in one decision:
  • Block: the request is refused with HTTP 403 and never reaches the provider.
  • Redact: the detected values are replaced (for example [SSN_REDACTED]) and the request continues.
  • Flag: the request is allowed, and the event is recorded with its rule, policy and threat type.
  • Allow: nothing was found.
Which decision a detector takes is set by the project’s strictness level and its policies. Blocked events, and events at confidence 0.8 or above, raise webhook alerts. To route detections into your own systems, send them to a webhook or your SIEM (SIEM export). PromptGuard does not call your code during a scan: to change what is detected, change the project’s guardrails or policies.

​
Detection accuracy

The published figures are the aggregate across the benchmark suite, from the run of 25 March 2026, measured at the moderate preset, the shipped default operating point (the threshold value is not published):
Precision and recall move against each other as the threshold moves, so the pair only means anything together with the operating point above. Per-detector accuracy is not separately published — we do not have a per-detector confusion matrix we would stand behind, and inventing one would be worse than the omission. See the benchmark write-up for the dataset breakdown, confidence intervals and the limits of a non-adaptive evaluation.

​
Seeing what was detected

Threat reports are available in the dashboard at app.promptguard.co → your project → Analytics, where you can filter security events by time range and threat type (prompt injection, data exfiltration, PII, and more) and drill into individual blocked requests. For programmatic monitoring, aggregate request counts are available via the Developer API:

​
Evaluation Framework

PromptGuard’s detectors are continuously evaluated against labeled datasets and industry-standard benchmarks:
  • Dataset-based evals: JSONL datasets with labeled examples benchmark detector accuracy
  • ROC AUC: Measures overall discrimination ability across all thresholds
  • Precision@Recall: Precision at specific recall targets, tuned for risk tolerance
  • Latency Percentiles: p50, p95, and p99 detection latency
  • PINT benchmark: Invariant Labs adversarial prompt injection benchmark (850 samples)
  • Garak benchmark: NVIDIA red-teaming framework with 666+ real-world jailbreak probes

​
Checking your own configuration

You can run your own spot-checks against your live configuration by sending known-attack payloads to the Guard API and asserting they are blocked:
Loop over a file of labeled attack and benign examples in CI to catch regressions whenever you change policies. See the Guard API reference for the full request and response schema.

​
Next steps

Threat Detection

Every detector and what it catches

Evaluate as a developer

Inputs that produce each decision, with their responses
Last modified on October 31, 2026