FAQ

Is KaizoCore unbeatable?

No, and treat anyone who claims that about any bot-detection product with suspicion. KaizoCore's specific, measured position: a well-resourced attacker running genuinely slow, attended, real browser sessions produces real behavioral data — and real behavioral data is exactly what the behavioral layers are built to read faithfully, not defeat by definition. What KaizoCore does raise, substantially, is the cost of automation: a captured fingerprint alone is no longer enough, a fast unattended script is no longer enough, and even a sophisticated Bezier-curve mouse generator is caught 82.2% of the time at a 0.5% human false-positive rate (see ML fusion) — not 100%, and that's disclosed on purpose.

Does a stable, consistent device fingerprint help my score?

Never. See Why KaizoCore — this is the single invariant the whole system is built around. A fingerprint is used only to correlate a session with a previously-seen bad actor; its presence, or its internal consistency, is never a reason to trust a session more.

What happens if a legitimate user has no mouse data (touchscreen, accessibility tooling)?

Nothing bad. Every rule that depends on optional behavioral data is gated on that data's presence, not just its value — absence of a signal is never itself treated as suspicious. See "the Golden Rule".

Can KaizoCore stop a fleet of coordinated bots (e.g. ticket-scalping rings)?

Not yet, as a dedicated capability. Detecting coordination specifically — an anomalously low seat-collision rate, synchronized abandon-and-retry timing across "unrelated" sessions — is architecturally distinct from detecting any one bot in isolation, and building it honestly requires real live event traffic from an actual high-contention drop to validate against, not synthetic approximation. This is on the roadmap, gated on a real customer relationship of that shape, not on engineering time alone.

Can an attacker farm ack tokens?

Not by replaying a captured one — the ack token's nonce is consumed on first use, and issuance requires a sustained, recent, genuinely clean PULSE history (see Ack tokens). What isn't stopped: an attacker running many real (necessarily slower) browser instances in parallel, each individually earning its own token honestly. That's real automation cost, not a shortcut — but it's a real, disclosed limit, not a claim that ack tokens make farming impossible.

Does KaizoCore support SSO, 2FA, or team accounts?

Not yet — today's dashboard is single email+password login per account. This is a known, deliberately deferred gap: it matters once an account has more than one team member, and will be built on demand rather than speculatively ahead of real need.

Is webhook delivery a durable queue?

Not currently — delivery runs in-process per decision (up to 4 attempts, exponential backoff), not through a separate durable job queue. This is a real scope limit worth knowing if your endpoint is occasionally slow to respond, though not something typical integrations notice in practice. See Webhooks.

How much real customer data trains the models?

Real, in-production ground truth is genuinely the scarcest input, and KaizoCore is honest about that rather than overstating it — it's supplemented heavily by a dedicated honeypot (real human testers plus a 17-script adversarial bot suite covering a wide range of real automation techniques) and diverse external human-baseline and bot datasets. See ML fusion. Every customer's real, approved traffic directly improves this over time.

Why does a new account need manual approval right now?

A deliberate, temporary step — new signups are reviewed before their key goes live, with a time-boxed trial once approved. This exists so real integration traffic can be reviewed at the current stage, and will move to an automated (email-verification) flow as signup volume grows.