Denne oversettelsen er maskinoversatt og venter på gjennomgang. Bytt til engelsk
Dashbord

Threat Categories

Six categories of threat. Each one tuned to catch automation, fraud, and abuse — without wrongly challenging real customers.

Detection isn’t a single check. Real-world fraud blends automation, infrastructure, and behavior. We map every category to the kind of decision your team actually makes — block, challenge, allow, observe.

The categories run roughly from “loud” — clearly malicious automation — to “quiet” — subtle behavioral signals. They’re independent inputs to the same calibrated risk score. A session can be flagged by one category, several, or none.

01. Automation and bots

Headless browsers, automation frameworks, and scripted abuse — including the “stealth” variants built to evade detection. The fast lane and the slow lane both get caught.

What we look for

  • Invisible, headless browsers and the family of stealth patches that try to hide them.
  • The fingerprints automation frameworks leave behind, even after they’re told to cover their tracks.
  • Signs that a session is being driven by a remote control tool rather than a person.
  • Internal contradictions that give away a script pretending to be a real browser.

Outcome

Recognize automated traffic before it reaches login, signup, or checkout.

Tuning

The default weighting here is heavy — automated traffic that survives our checks is the most reliable sign of malicious intent in the whole model. If you have a legitimate automation use case, such as uptime monitoring or scheduled reporting, allowlist it by key rather than relaxing the weights for everyone.

02. Fingerprint tampering

Sessions where the browser is lying about itself. Faked drawing tests, manipulated browser behavior, anti-fingerprint tools running aggressive countermeasures.

What we look for

  • A drawing-test result that doesn’t match the browser and operating system the session claims to be.
  • A graphics signature that contradicts the rest of what the device reports.
  • The browser’s stated identity disagreeing with what it actually renders.
  • The residue left by aggressive anti-fingerprint tools.

Outcome

Surface deliberate evasion attempts without blocking honest privacy choices.

Tuning

We separate lying from protecting. A privacy-browser user has a consistent, declared profile — that produces a privacy-browser signal (see 04), not a tampering signal. Tampering means the session is claiming to be one thing while everything else says it’s another.

03. Infrastructure abuse

Traffic from datacenters, anonymizing proxies, outdated network behavior, and known-bad ranges. We flag the patterns without blocking real users who happen to be on a corporate VPN.

What we look for

  • Traffic from major cloud providers — the wholesale fraud lanes.
  • Known-bad ranges from threat-intelligence feeds, including residential proxies sold to fraud rings.
  • Outdated or downgraded network behavior that hints at proxy chaining.
  • Time-zone, language, and location signals that contradict each other — a sign a proxy is rewriting the surface but not the underlying session.

Outcome

Identify the wholesale-fraud signal — without misfiring on remote workers.

Tuning

Datacenter traffic is not automatically malicious. A corporate VPN, an employee on a cloud workspace, a journalist behind a hosted relay — all of these can look like “infrastructure flagged” without being malicious. We treat it as a weak signal that only escalates when it’s combined with other categories.

04. Privacy-browser handling

Recognized privacy browsers, treated with calibrated leniency. Privacy-conscious users stay welcome; bots hiding behind privacy browsers do not.

What we look for

  • The known shapes of popular privacy browsers.
  • Consistency rather than tampering — a real privacy browser produces a stable profile we can recognize.
  • A cross-check against the hardware (05) and behavioral (06) signals to tell a privacy-conscious human from a bot hiding behind the same browser.

Outcome

Welcome legitimate privacy users while still catching the actors hiding among them.

Tuning

This is one of the most important categories for false-positive prevention. The default is to allow recognized privacy browsers. The network and infrastructure scoring still applies, but we suppress the “low detail” signals that would otherwise misfire on a privacy browser’s deliberately uniform profile.

05. Hardware checks

Device-level checks catch emulators, virtual machines, and replay attacks. The bots that beat browser-only checks fail the hardware check.

What we look for

  • Graphics signatures that reveal software rendering — often a virtual machine or emulator rather than a real device.
  • Graphics capabilities that don’t match the device’s claimed hardware.
  • Audio signatures that reveal a real audio path versus a simulated one.
  • The everyday device characteristics a real machine has but a fresh, throwaway container often doesn’t.

Outcome

Verify the device is what it claims to be — not just the browser running on it.

Tuning

Hardware is the strongest signal we have, and the most expensive to fake at scale. Fraud rings can rent residential proxies cheaply; they can’t rent millions of real devices cheaply. We weight hardware mismatches accordingly.

06. Behavioral anomalies

Mouse, keyboard, scroll, and post-challenge timing patterns. The shape of a real user — and the shape of an automated one — differ down to the millisecond.

What we look for

  • Mouse movement: humans have jitter, micro-corrections, and natural limits on speed. Scripts often draw straight, perfectly smooth lines.
  • Typing rhythm: real typing varies; programmatic input tends to land in a suspiciously tight window.
  • Scrolling: real scrolling decelerates naturally; programmatic scrolling often doesn’t.
  • Timing after a challenge: humans pause; scripts continue immediately.

Outcome

Catch the sessions that look human on paper but don’t behave like a person.

Tuning

Behavioral signals are the quietest in the model. They’re the difference between a session that passes every other category and one that still feels wrong. We use them to escalate otherwise-clean sessions, not as a primary blocking signal — judging on behavior alone would punish users with motor differences, assistive technology, or simply unusual habits.

How the categories combine

Every category produces a calibrated risk score and a confidence measure — not a verdict. Your team owns the final policy. We just make sure the inputs are honest.

The flow is simple: the browser collects the profile, the six categories each weigh in, those weighted inputs combine into a single calibrated risk level, and your code decides what to do — block, challenge, or allow.

The confidence measure reflects how much the session actually gave us to work with. A session that spent only a few seconds on the page tells us less than one with a full minute of interaction, regardless of its risk level.