Trust

Honesty is a feature.

Security products earn trust by being right about what they can’t do, not just what they can. PubSentry is the AI Security Engineer for ad publishers — it blocks invalid traffic before the ad fires, and it tells you exactly where the line of catchable fraud is today, never a fake number to paper over it. Here’s every promise we hold ourselves to.

0 humans wrongly blocked on the human test corpus — the one number we obsess over
The #1 principle

FPR = 0, by covenant.

Blocking a real reader is the worst thing this product can do — worse than missing a bot. A wrongly-blocked human is a lost reader, a support ticket, and a reason to churn. So a false-positive rate of zero isn’t a target we hope to hit; it’s the constraint everything else is built around.

Conservative by default

When a verdict is uncertain, we serve the ad. The defaults are tuned so the engine would rather miss a borderline bot than risk a single real human — you opt into more aggression deliberately, with eyes open.

A CI calibration gate

Every change to the scoring engine runs against a human test corpus, and the build asserts FPR = 0 on it. If a tweak would block a real reader, it doesn’t ship. The covenant is enforced in CI, not just in copy.

Blast-radius preview

Before any rule or IP block goes live, we replay it against your real recent traffic and show exactly who it would have caught — retroactively. You see the collateral before you commit, not after.

The covenant. We measure ourselves on humans wrongly blocked, and we hold it at zero. Every other metric is downstream of that one.
Radical honesty

The detection boundary — what we catch, and what we don’t.

Most vendors quote one big recall number and let you assume it covers everything. It never does. Invalid traffic comes in two flavors, and they are not equally catchable. We’ll tell you exactly where the line is.

~100%
Recall on obvious bots (GIVT) — at 0% false-positives
0
Humans wrongly blocked on the human test corpus
~3%
Sophisticated residential-IP mimicry caught today — by design
never
Do we claim a perfect number. There is no such thing.

Obvious bots: ~100% recall, 0 false-positives

Headless browsers, automation tells, datacenter and known-bad ASNs, honeypot trips, impossible behavior — general invalid traffic (GIVT) leaves fingerprints. The deterministic engine catches essentially all of it without ever touching a real reader.

Sophisticated mimicry: ~3% today, by design

A bot on a residential IP with a real browser and human-like timing leaves almost no tell. Catching it on signals alone would mean blocking real people — so we don’t. That ~3% is a deliberate floor, not a bug.

How the gap closes

Sophisticated invalid traffic (SIVT) is closed by scale, not by a riskier gate: the cross-site reputation network (provisional until scale) and the ML moat both sharpen as traffic flows. An entity flagged on any PubSentry site is pre-flagged on yours.

“Awaiting traffic,” not a fake score

Before your site has data, the dashboard says awaiting traffic — not an invented 99.9%. The day-one numbers you see are the day-one numbers we actually have. We’d rather show you a blank than a lie.

Why a perfect number is a tell. Anyone who quotes you flawless detection is either ignoring false-positives, ignoring sophisticated bots, or both. The honest answer has two numbers and a boundary — and that boundary is in our docs, not buried. Read the detection boundary →
Privacy by design

We score visitors without hoarding them.

Fraud detection needs signals, not identities. PubSentry is built so the data that could identify a real person is hashed and dropped before it ever lands in storage — the engine keeps the verdict, not the visitor.

Raw IP & User-Agent are dropped

The server enriches datacenter / ASN / geo from the request, then HMAC-SHA256 hashes the raw IP and User-Agent and discards the originals. They are never written to storage in raw form. The verdict survives; the PII doesn’t.

Fingerprints are non-PII

Client-side device fingerprints use a fast fnv1a hash — a non-reversible bucket for spotting the same automation twice, not an identity. The tag only sends client-knowable fields; the server enriches the rest and drops the raw inputs.

Same-origin sessions

Dashboard auth is scrypt-hashed passwords and opaque, same-origin cookie sessions — no third-party tokens, no cross-site cookies. The control room sets no CORS; only your own browser talks to it.

Per-account scoping

Every API call is gated by a session and scoped to the sites your account owns. One account can never read another’s traffic, verdicts, or config — isolation is enforced on every request, not assumed.

A note on the reputation network. The cross-site signal that pre-flags bad actors everywhere shares reputation — hashed entity verdicts — never a publisher’s raw visitor data. You get the network effect without exposing your readers.
Block before serve

The only honest place to stop fraud is before the ad fires.

Once an impression is counted or a click is billed, the damage is already on your account — the fraud happened, and the best a report can do is tell you about it. PubSentry makes the verdict before the ad loads. A blocked impression was never served, a blocked click was never billed, and your AdSense account never sees the spike.

  • The verdict lands in under 5 ms, locally, before any ad request goes out
  • Suppression across GPT, AdSense, Amazon apstag and Prebid — plus a universal MutationObserver fallback
  • The same scoring engine runs in the tag, at the edge, and on the server — a parity test guards it
  • It fails open: any error serves the ad. One tag, under 15 KB, ad-network-agnostic, never delays the page
Block before serve — the under-5-millisecond pipeline A left-to-right flow: a visitor reaches a local gate that scores 28 signals across 5 families in under 5 milliseconds, then forks. Allow lets the ad fire (green). Block suppresses the ad slot (red, circle-slash) and sends a beacon to enrich and persist. Block before serve The <5 ms pipeline ● Allow · ad fires ● Block · ad suppressed Visitor Local gate <5 MS Block-before-serve decides before the ad call — no round-trip VERDICT ALLOW BLOCK The gate Score 28 signals 5 families · fail-open collectors AUTOMATION ENV BEHAVIOR TIMING HONEYPOT Allow → ad fires IMPRESSION SERVED Block → suppressed No impression ALLOW BLOCK Enrich + persist beacon → IP / ASN / geo reputation · ClickHouse RAW IP / UA HASHED + DROPPED BEACON · OFF THE HOT PATH FAIL-OPEN EVERYWHERE · A REAL READER IS NEVER BLOCKED · FPR = 0
The standards we hold

Five promises, in one place.

We won’t block a real human

FPR = 0 is the constraint, enforced by the CI calibration gate and the blast-radius preview. The whole engine bends around it.

We won’t show a fake number

No invented scores, no claim of perfect detection. Before there’s data, the dashboard says “awaiting traffic.” What you see is what we measured.

We won’t hoard your visitors

Raw IP and User-Agent are HMAC-hashed and dropped server-side. Fingerprints are non-PII fnv1a buckets. The verdict is kept; the person isn’t.

The ML never decides on the hot path

Rules decide the verdict; the AI only narrates it. No black box gets to block a reader unsupervised — every block is explainable.

We stop fraud before it’s billed

Block-before-serve, not report-after. A blocked impression was never served and a blocked click was never billed to your account.

We’ll tell you what we can’t catch

~100% on obvious bots, ~3% on sophisticated mimicry today, closing as the network scales. The boundary is in the docs, not hidden.

Trust starts with the truth

Protect your account — honestly.

One tag, live verdicts in minutes, and a product that tells you exactly what it can and can’t catch. Free to start — you only see the value once your real traffic is scored.

0 humans wrongly blocked — that’s the promise