> ## Documentation Index
> Fetch the complete documentation index at: https://docs.insightsecure.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Beyond RASP

> Device-to-user graph mapping, network-level correlation, and securing the telemetry pipeline itself

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:

<CardGroup cols={2}>
  <Card title="One device, many accounts" icon="users">
    Surfaces device-farm and multi-accounting patterns — a single device transacting across accounts that have no legitimate relationship to each other.
  </Card>

  <Card title="One account, many devices" icon="mobile-retro">
    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.
  </Card>
</CardGroup>

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](/api-reference/webhooks-and-payload).

## 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:

<Steps>
  <Step title="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.
  </Step>

  <Step title="Hardware-backed device identity">
    The device-binding key described in [RASP](/device-intelligence/rasp#detection-categories) means the identity your backend correlates against is anchored in secure hardware, not just a value the client sent.
  </Step>

  <Step title="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](/api-reference/authentication).
  </Step>
</Steps>

## Where this data goes

<CardGroup cols={2}>
  <Card title="Real-time delivery" icon="bolt" href="/api-reference/webhooks-and-payload">
    Webhook or live socket channel — see the full payload reference.
  </Card>

  <Card title="AML case investigation" icon="diagram-project" href="/aml/overview">
    The same device and user graph feeds mule-account detection on the AML side.
  </Card>
</CardGroup>