Skip to main content

Detection Engines, Pattern Sources & Stability

Rivaro's detection pipeline runs in layers. The default detectors — built-in pattern matchers, ML classifiers, and the LLM-as-judge for nuanced cases — cover most use cases out of the box. When you need more, you can plug in external engines (Presidio, Google DLP, Amazon Comprehend), import pattern feeds from threat-intel providers, and tune the stability layer that suppresses noisy detections.

Where to find it in the app​

Dashboard → Administration → Detection Engine.

The Detection Engine page has three tabs:

  • Detection Rules — the org-wide rule library (also reachable from Policies & Authority)
  • Detection Coverage — enable / disable / configure external detection engines (Presidio, Google DLP, Amazon Comprehend) and see which built-in layers are active
  • LLM Configuration — configure the LLM-as-judge model and any per-org overrides
Custom pattern feeds

If you have a threat-intel feed or regulated vocabulary you want ingested, contact your Rivaro account team. Once it's wired in, the patterns appear in your Detection Coverage tab as detection types you can attach policies to.

Built-in detection layers​

Each request flows through multiple stages:

LayerWhat it does
Pattern matchingRegex / dictionary detectors. Fast, deterministic. Covers PII, credentials, known indicators.
ML classificationTrained classifiers for content categories (toxicity, prompt injection, etc.).
LLM-as-judgeFor nuanced cases where pattern + ML aren't enough — a sandboxed model evaluates the content against the detection definition. Configure under the LLM Configuration tab.
External engines (optional)Presidio, Google DLP, Amazon Comprehend — configured under Detection Coverage.
Stability layerSuppression of known noisy detections; correlation of related signals into single events.

You always get layers 1–3. Layers 4 and 5 are opt-in.

External detection engines​

When you want defense in depth — running a second engine on the same content and combining results — Rivaro can call out to:

EngineTypeUse case
Microsoft PresidioPII detectionBest-in-class open-source PII detector; great for non-English content
Google Cloud DLPPII / structured data classificationStrong at structured data, payment cards, regulated identifiers
Amazon ComprehendNLP / sentiment / PIIAWS-native option with strong English-language coverage

Each runs in parallel with the built-in detectors; the union of detections is what's evaluated against policy.

Configuring an external engine​

Open Administration → Detection Engine → Detection Coverage. Each engine has its own card with Configure, Test connection, and an Enabled toggle.

Presidio​

Click Configure on the Presidio card and fill in:

  • Endpoint URL — your self-hosted Presidio instance, e.g. http://your-presidio.internal:5001
  • API key — optional, if your Presidio is behind auth

Click Test connection to validate. Then toggle Enabled on.

You can self-host Presidio (recommended for data-sensitive environments) or point at any HTTP-reachable Presidio endpoint.

Google DLP​

Click Configure on the Google DLP card and fill in:

  • GCP Project ID
  • Service account JSON — paste the service account JSON; stored encrypted
  • Info types — pick from the dropdown which Google DLP info-type detectors to run (e.g. EMAIL_ADDRESS, PHONE_NUMBER, CREDIT_CARD_NUMBER, US_SOCIAL_SECURITY_NUMBER). Leave empty for the recommended default set.

Amazon Comprehend​

Click Configure on the Comprehend card and fill in:

  • AWS region (e.g. us-east-1)
  • Access key ID / Secret access key — stored encrypted

To remove the configuration entirely, use the Remove action on the engine card.

Toggling an engine on or off​

Every engine card has an Enabled toggle. This is the kill switch — disable an engine instantly without removing the configuration. Useful when you suspect an engine is producing false positives and you want to bypass it while you investigate.

LLM Configuration​

The LLM Configuration tab lets you choose which LLM acts as the judge for nuanced detections, plus advanced tuning:

  • Judge model — default model used for ambiguous cases (Rivaro provides a sensible default; override if you have a contractual preference)
  • Provider override — point the judge at your own provider deployment instead of Rivaro's
  • Sampling rate — how often borderline cases get escalated to the LLM (vs handled by the deterministic layers alone)

Changes apply on next request; existing detections are unaffected.

Pattern sources​

A pattern source is an external feed of detection patterns — typically a threat-intel provider, a regulated-vocabulary publisher, or an internal repository of known-bad indicators. Rivaro periodically polls the source, ingests the patterns, and makes them available as detection definitions you can attach policies to.

Ingested patterns appear in Detection Coverage as available detection types. You attach policies to them the same way as built-in detections. Standard threat-intel formats are supported; to have a feed wired in for your org, contact your Rivaro account team.

Detection stability — suppression and correlation​

Real-world detection traffic is noisy. The same pattern can fire hundreds of times for the same actor on the same session, drowning out the signal you actually care about. The stability layer keeps that noise from reaching policy and operators.

Stability metrics are surfaced in two places:

  • Risk & Compliance → Detection Analysis — per-detector suppression rates and correlation effectiveness over time
  • Executive View → Reports → Guardrail Summary — high-level "are detectors actually catching things" view

Suppression​

When a detector fires repeatedly for the same (actor, detectionType, content-cluster) tuple, subsequent firings are suppressed — recorded but not surfaced as separate events. The suppression metrics tell you which detectors are noisy.

A detector with 95% suppression is firing on something legitimate that you should either tune out at the detector level or scope away with policy.

Correlation​

Related signals are correlated into single events. A prompt-injection pattern + a privilege-escalation attempt + a data-exfiltration probe within the same session aren't three independent detections — they're one attack. Correlation surfaces them as a single grouped event for operators.

Detector analytics​

For per-detector tuning, Risk & Compliance → Detection Analysis shows confusion-matrix-style data per detector: total firings, suppressed firings, escalated to incidents, action distribution. This is where you decide whether to tune a detector or replace it.

Validation report​

For compliance evidence, the Compliance Reporting flow includes a detection validation report — coverage, stability, suppression rates — ready to attach to evidence packages. See Compliance Reporting.

Next steps​