How partners would capture the candidate behavioral-biometrics signal at the edge and consume sealed results downstream. This page documents the integration shape and its privacy boundaries — it is a preview of a contract, not a download page.
Scope
Candidate scope, labeled as such
Candidate signal Integration preview No downloadable artifacts
Behavioral biometrics is the seventh corroboration axis and the only one still in candidate scope: a human-interaction and device-consistency check that can help separate human application behavior from scripted or ring-linked activity. Until it is approved, every surface that mentions it — including this one — carries the candidate label, and no SDK packages are published.
This is candidate scope and must remain status-labeled until approved.
Conceptual overview
Two halves: capture and consumption
The integration has two halves that never share raw data. At capture time, a platform SDK records a behavioral session during the application flow and returns an opaque token. At consumption time, a REST API returns evidence the engine has already sealed.
Capture time
A session token from the edge
A platform SDK — browser, iOS, or Android — observes interaction and device-consistency signals while the applicant completes the form, computes everything on-device, and returns a session token you attach to the application payload. The token is the only thing that leaves.
Consumption time
Sealed evidence from the API
A REST API returns the sealed evaluation — recommendation, per-axis evidence, gate result — so you can surface it in your own workflow. The API does not re-decide anything; it only reads what the engine sealed. This half is implemented today and documented in the API reference.
Integration steps
Four steps, one token
Install the platform SDK and initialize it with your public key.
Start a session when the application form opens, keyed to your application id.
Finalize the session on submit and attach the returned session token to your application payload.
After the engine evaluates and seals the record, pull results from the consumption-time API.
Live demonstration · Human typing test
Prove you are human
Funny for about three seconds. Type. Move. Hesitate. Correct yourself. Real people are messy; bots try not to be. The joke is that proving you are human feels ridiculous. The problem is that more of the internet now has to ask.
On the surface, it is a small typing test: type the line, get your words-per-minute, and receive a mildly unfair judgment about your speed and accuracy. Underneath, your browser is watching simple local clues: how your pointer moves, how unevenly you type, whether you correct mistakes, whether the browser says it is automated, and whether the device details agree with each other. It observes nothing until you start, samples pointer motion only while the test is running, stores nothing, and sends nothing — open your browser’s network inspector and verify.
Two things to know. First, the panel waits until it has enough movement or typing to say anything. Thin evidence gets no guess. Second, this is only a local illustration. The real SDK works on-device, turns richer capture data into a session token, and never sends raw typing or pointer trails.
Inactive — nothing is observed until you start proving it.
Once the test starts, type the line in the box below to sample keystroke cadence, and move your
pointer or finger anywhere on this page — motion is sampled page-wide.
Type this line—
Your typing resultAwaiting proof—Start proving it, then type the line above to clock your speed.
Keystroke record0 corrections
Humans mistype and fix it mid-sentence; a script pastes the final string with zero
corrections. That correction rhythm is itself a signal.
Your pointer path across the whole page. Real motion curves and wanders; a scripted cursor
draws straight lines between targets.
Pointer samples
0
Pointer positions captured so far. Humans drift, overshoot, pause, and fix themselves; more
samples sharpen every read below.
Path efficiency
—
How straight your pointer travels toward a target (0–1). Real hands curve and overshoot; a
near-perfect 1.00 is the signature of a scripted straight line.
Hesitations
—
Brief slow-downs as the pointer settles on a target. Humans make these micro-corrections;
scripts usually don't.
Keystroke μ
—
Average gap between keystrokes. Human typing sits in the tens-to-hundreds of milliseconds;
near-instant timing suggests injected input.
Cadence σ
—
How irregular your typing rhythm is. Humans vary a lot; a near-constant cadence is the
strongest tell of machine-generated keystrokes.
Automation flag
—
Whether the browser reports it is being driven by automation tooling
(navigator.webdriver), the standard WebDriver signal.
Device consistency
—
Cross-checks of language, timezone, screen size, and touch support that should agree on a
genuine device but often conflict in a headless environment.
Session
0s · 0 events
Elapsed observation time and the number of pointer and keystroke events seen this session.
Input forensics
Behavioral biometrics, with the apex caveat in the box
Behavioral biometrics catches scripted automation — pointer-trajectory naturalness, keystroke cadence, and target-landing precision separate a curve-fitted bot from a real hand. It does not, on its own, catch the apex tier: a real operator driving a remote desk, a GAN producing human-quality trajectories, or a replay of recorded legitimate input. Those defeat behavioral signals entirely, and the demo names this plainly.
The composition we ship pairs the behavioral atom with a non-behavioral coherence atom (stated residence vs. session-origin region) so the apex tier still flags. The interactive demo, including the apex-mode toggle and the composed verdict, lives inside the gated app — that’s the right surface for a risk-team audience and the one canonical implementation.
A drop-in JavaScript SDK that captures the behavioral session in the page and emits a session token on submit. Package coordinates below are illustrative — nothing is published yet.
<!-- Illustrative — no published artifact yet --><script src="https://cdn.kenshiki.example/sdk/kenshiki-web.min.js"></script>
const kenshiki = Kenshiki.init({publicKey: "pk_demo_xxx",platform: "browser",});// Begin a behavioral session when the application form opensconst session = kenshiki.startSession({ appId: "mortgage-01" });// On submit, finalize and attach the session tokenform.addEventListener("submit", async () => {const { vendorSessionId } = await session.finalize();// include vendorSessionId with your application payload});
Runs entirely client-side; nothing beyond the session token leaves the page.
Requires a visible consent notice and respects browser tracking protections.
Degrades gracefully when the browser blocks fingerprinting APIs — absence of the signal is handled by abstention, not failure.
Platform preview
iOS (Swift)
A native Swift package capturing interaction and device-consistency signals during onboarding. Coordinates are illustrative.
// Swift Package Manager — illustrative, not yet published.package(url: "https://github.com/kenshiki-labs/kenshiki-ios.git", from: "1.0.0")
import KenshikiSDKlet kenshiki = Kenshiki(publicKey: "pk_demo_xxx", platform: .ios)let session = kenshiki.startSession(appId: "mortgage-01")// When the applicant submitssession.finalize { result in switch result { case .success(let token): // attach token.vendorSessionId to your application payload case .failure(let error): print(error) }}
Requires the platform tracking-usage disclosure and consent prompt where applicable.
Uses on-device signals only; no raw biometrics are transmitted.
Targets current and previous major iOS versions; integrates with both UIKit and SwiftUI.
Platform preview
Android (Kotlin)
A native Kotlin library capturing device and behavioral signals during the application flow. Coordinates are illustrative.
// build.gradle (app) — illustrative, not yet publishedimplementation("com.kenshiki:kenshiki-android:1.0.0")
val kenshiki = Kenshiki.init( publicKey = "pk_demo_xxx", platform = Platform.ANDROID,)val session = kenshiki.startSession(appId = "mortgage-01")// On submitsession.finalize { result -> result.onSuccess { token -> // attach token.vendorSessionId to your application payload }.onFailure { e -> Log.e("Kenshiki", e.message ?: "") }}
No special permissions required for the default signal set.
Signals are computed on-device; only the session token is sent.
Compatible with Jetpack Compose and Views.
Privacy posture
What never leaves the device
The capture half is designed so there is nothing sensitive to intercept. Signals are computed on-device and reduced to an opaque session token before anything is transmitted. The consumption half only returns evidence the engine has already sealed — the API cannot be used to re-derive raw signals or re-decide an application.
The SDK emits a session token; raw biometric data never leaves the device.
What is real today
Use the API reference; watch this page
The consumption-time API is implemented, generated from the same Zod contracts the server validates against, and runnable against the synthetic demo dataset. The OpenAPI specification documents only implemented endpoints, so capture-time endpoints will appear there — and downloads will appear here — only if the behavioral-biometrics signal graduates from candidate scope.
The boundaries behind the preview — what exists, what does not, and what the data never includes.
Can I download the Kenshiki SDKs today?
No. The browser, iOS, and Android SDKs are an integration preview for a candidate signal. The snippets show the intended contract shape; package coordinates are illustrative and no installable artifacts are published yet.
Does the SDK send raw biometric data to Kenshiki?
No. Signals are computed on-device and reduced to an opaque session token. Only that token leaves the device, and the consumption-time API returns only evidence that has already been sealed by the engine.
Is the live signal demo the production Kenshiki signal?
No. The live panel is a browser-local illustration of the signal classes the candidate axis would draw on. It runs only after you start it, observes only inside its own panel, stores nothing, transmits nothing, and abstains when the sample is too small.
Which half of the integration is real today?
The consumption-time API is implemented and documented in the API reference, running against the synthetic demo dataset. Capture-time endpoints and SDK packages ship only if the behavioral-biometrics signal graduates from candidate scope.
Live today
Need a browser-to-phone trust gate now?
Unlike the capture-time SDKs above, the Pulse beta embed is shippable today: a hosted script that locks a browser action until the carried phone proves the same human is present. Request a publishable key, allowlist your origins, and paste one snippet.