Why Kyli
The threat model this was built against, and why fingerprinting alone doesn't hold up.
Most integrations start with the same question: what is Kyli actually checking, and why should a fingerprint-based tool not be enough on its own? This page is the honest answer — the specific threat model Kyli was built against, the reasoning behind treating a device fingerprint as a correlation signal rather than proof of trust, and where that leaves Kyli relative to older, fingerprint-first approaches.
The short version: attackers who can buy or generate a convincing fingerprint shouldn't be able to buy their way past detection too. Everything below explains what that means in practice — what Kyli checks instead, what it deliberately never penalizes, and what it still can't do.
Why fingerprinting alone isn't the whole answer
Device fingerprinting — collecting a set of stable browser signals (canvas hash, WebGL hash, screen size, fonts, TLS handshake shape), hashing them together, and using that hash to recognize the same "device" across requests — is a widely used building block across the industry, and many vendors already combine it with their own behavioral or network signals. Kyli uses fingerprinting too, but treats it as one input among several rather than the primary basis for a decision.
Fingerprinting is useful for correlation, but static identifiers alone can be replayed or spoofed. Commodity anti-detect browsers and fingerprint-spoofing services exist specifically to hand an attacker a fingerprint that's stable, internally consistent, and hard to distinguish from a real device — in some cases because it is a real device's fingerprint, captured once and reused across a farm of automated sessions. A detection system that treats a matching fingerprint as evidence of trust is relying on exactly the kind of signal those tools are built to supply.
The Kyli answer: Fingerprints are for correlation, not Trust
This is the single invariant the whole scoring engine is built around:
A device fingerprint is used to link a session to a previously-seen bad actor. By design, Kyli does not treat a stable, valid-looking fingerprint as sufficient evidence of legitimacy — its presence, or internal consistency, is not on its own a reason to increase trust in a session.
Concretely: the bad-actor lookup only ever adds risk — a fingerprint matching a known bad actor raises the score — and never subtracts it. There is no rule anywhere in the scoring engine that treats a stable canvas or WebGL hash as evidence that a session is more human. A rule like that would be exactly the thing fingerprint-harvesting tools are built to exploit.
What provides stronger evidence of a legitimate, live session?
Two categories of evidence, both harder to fake cheaply than a static hash:
- Continuous behavioral signal — Kyli analyzes temporal interaction patterns such as movement variability, directional changes, and session continuity to help distinguish automated activity from legitimate use. This is measured continuously (see PULSE), not once.
- Short-lived, server-issued attestations — an ack token is issued only after a session has sustained multiple clean PULSE heartbeats in a row. Tokens are single-use with a 30-second TTL and are designed to reduce replay risk: the nonce is consumed on first use.
The Golden Rule: absence of a signal is never suspicious by itself
The other invariant that shows up everywhere in the rules engine: if a
signal is missing — no mouse data because the user is on a touchscreen, no
environment fingerprint because a corporate proxy stripped it, no completed
collect() because the page loaded fast — that absence must never, by
itself, score as suspicious. Every rule that depends on optional data is
gated on that data's presence, not just its value. A rule like "no natural
idle periods" only fires once there's enough real behavioral sample to trust
the absence as meaningful, not just insufficient data.
This matters because the alternative — penalizing missing data — creates a detector that's biased against exactly the real users most likely to have thin telemetry: accessibility-tool users, slow networks, privacy-conscious browsers, and fast, confident purchasers.
Where this leaves Kyli vs. the field
Read How it works for the full architecture. Kyli emphasizes continuous session evaluation rather than relying primarily on a single fingerprint collected at session start — but it is not unbeatable: a well-resourced attacker running real, slow, attended browser sessions is still producing real browser traffic, which is a different and harder problem than replaying a captured fingerprint. Every limitation Kyli knows about is documented, not hidden — see FAQ.