Skip to main content
RASP answers “is this specific device compromised right now.” It can’t see across sessions, across users, or across time — that requires a backend with history. This is what Device Intelligence adds on top of the on-device SDK.

​
Device-to-user graph mapping

Every telemetry event links a device_id to whatever user/account identifier your app passes at the time. Over time, this builds a graph the backend can query in both directions:

One device, many accounts

Surfaces device-farm and multi-accounting patterns — a single device transacting across accounts that have no legitimate relationship to each other.

One account, many devices

A sudden jump in distinct devices on one account, especially combined with a new-device + VPN + high-value-transaction pattern, is a strong account-takeover signal.
This is delivered as a correlation block on flagged events — device_seen_on_users, visitor_id_seen_on_users, and shared_ip_sessions are the three views most integrations key off. Full field reference: Webhooks & Payload Reference.

​
Behavioral and velocity analytics

Signals that only make sense aggregated over a session or a time window, not from a single snapshot:
  • Interaction entropy — mouse/touch movement and keystroke timing variance. Scripted/automated interaction produces unnaturally low entropy and regular timing intervals; human interaction doesn’t.
  • Velocity — events-per-minute against a rolling threshold, with burst detection for sudden spikes.
  • Reuse windows — how many times a device, browser visitor ID, or IP address has been seen across distinct accounts within a rolling window (10 minutes to 24 hours, depending on the signal).
  • Automation likelihood — a composite score combining timing variance and interaction entropy into a single 0–1 estimate of scripted/bot activity.

​
Web fingerprinting (browser sessions)

For web-based checkout and login flows where a native SDK isn’t in play, Device Intelligence layers a browser fingerprinting provider (FingerprintJS or equivalent) to produce a stable visitor_id independent of cookies, plus a bot-signal detector that flags known automation indicators (headless browser markers, low input entropy, timing regularities specific to scripted browsers like Puppeteer/Selenium).

​
Securing the pipeline itself

Device intelligence data is only as trustworthy as the pipeline carrying it:
1

Signed telemetry

Every payload from the SDK to InsightAI’s ingest endpoint is HMAC-signed with your tenant’s private secret. The backend verifies the signature before processing anything — an unsigned or mismatched-signature payload is rejected outright, not just logged.
2

Hardware-backed device identity

The device-binding key described in RASP means the identity your backend correlates against is anchored in secure hardware, not just a value the client sent.
3

Signed outbound delivery

Webhook and API responses back to you are signed the same way, so your backend can verify a payload genuinely came from InsightAI before acting on a BLOCK/REVIEW decision. See API Authentication.

​
Where this data goes

Real-time delivery

Webhook or live socket channel — see the full payload reference.

AML case investigation

The same device and user graph feeds mule-account detection on the AML side.