Zero-False-Positive AI Detection for SMB Security Teams

Most SMB security teams suffer from a brutal asymmetry: a single attacker needs one good day, and the defender must catch every bad one — across every endpoint, every log source, every shift. The industry's response has been to crank up alert volume. The result is the well-known alert-fatigue cycle, where analysts mute, dismiss, or snooze warnings until a real incident lands in the discard pile.

A working zero false positive strategy doesn't try to be cleverer than the alert engine. It admits that unusual and malicious are different things, and engineers a pipeline that can tell them apart at scale.

The two questions every alert must answer

Every actionable alert should arrive on the analyst's screen with two facts already established:

Is this unusual for this endpoint? A 3 AM PowerShell run on the

developer's laptop is unusual; on the build server, it's the nightly release pipeline. The detector needs a per-endpoint baseline before it speaks.

Does the unusual event correlate with known-bad behaviour?

Encoded PowerShell on a host that has never run it before, combined with a brand-new outbound connection to a low-reputation IP, is the signal. Either alone is just noise.

Most legacy SIEMs answer the first question only at query time — and only when the analyst remembers to ask. A modern detection pipeline answers it BEFORE the alert leaves the pipeline.

Three architectural moves that cut false positives by 60-90%

In our customer deployments we measure a 60-90% reduction in analyst-acknowledged false positives. The three moves that matter:

1. Per-endpoint embedding baselines

Every alert gets a small vector embedding (we use a bundled BGE-small ONNX model — no external API) of its enrichment text. The pipeline maintains a rolling 30-day centroid per endpoint. New alerts that come within a tight cosine distance of the centroid AND carry a severity at or below medium are downgraded to a forensic note rather than an actionable alert.

The math is intentionally conservative — empty corpus defaults to alerting, not silencing. The first day at a new endpoint, the analyst sees everything; from week two onward, the noise floor collapses.

2. Two-signal flagging

A single deviation can never push past the action threshold. Off-hours activity by itself doesn't flag; a never-before-seen action by itself doesn't flag. The two together do. This is the single highest-leverage change for cutting false positives in user behaviour analytics.

3. Engine attribution

When the AI cascade is unreachable (rate limited, outage, budget exhausted), our pipeline falls back to a deterministic rule engine and TAGS the resulting alert with engine = "fallback". The analyst's queue can filter rules-based verdicts and treat them with appropriate caution — instead of treating every alert as gospel.

The dashboard that actually works for an analyst

When the pipeline does its job, the analyst dashboard becomes scannable again. A handful of HIGH-severity, high-confidence alerts at the top — each with a one-paragraph plain-language summary, MITRE technique mapping, and a one-click playbook (block IP, isolate host, kill process).

If you want to see this in action, start a free trial — the live SecOps console at /dashboard/live shows the validator, the predictor, and the playbook dispatcher all running against your own telemetry.