Burein has no backend. No telemetry. No remote config. This page walks through what that means in practice, and why it isn't just marketing.
Burein.collect() — attach to your own API (header, body, any channel your stack already runs)No collector or engine module makes a network call. CI enforces this with static analysis on every build. Customers can verify by running a packet capture against any production build — there's nothing to see.
All rules, thresholds, and ML models ship inside the SDK binary. There is no channel to swap our logic at runtime. Updates require a version bump in your build pipeline.
Class-0 and Class-1 signals (computed, derived, device characteristics) are on. Class-2 (quasi-identifiers like ad-ID, WebRTC IPs) require host opt-in. Class-3 (IMEI, MSISDN) require both opt-in and a matching platform permission.
The same device in the same state produces the same visitor_id and the same signal hashes. This makes every report testable, replayable, and auditable.
Every report is canonicalized (RFC 8785 JCS) and signed with your Ed25519 key, embedded at build time via your toolchain. Your server holds the public key. An in-app attacker that hooks the host code can't forge a report the SDK didn't produce.
Pick a signal set per call: full, balanced, minimal. Override severities. Bring your own rules. Disable any collector. Tune the engine without forking.
Every release builds bit-for-bit identical across machines. Customers can independently rebuild and diff against the published artifact.
Every artifact carries provenance attesting the build environment, source revision, and inputs.
Releases are signed; verification keys are published; revocation is possible.
Full SBOM with every release. No surprise dependencies; zero non-vendor native dependencies on mobile is a target.
The BureinReport is the single thing the SDK hands back. The host invokes a public method — Burein.collect() on web, Buren.collect { … } on iOS, buren.collect() on Android — and receives a deterministic, signed, schema-versioned, JSON-serializable report containing every signal you asked for, every threat that fired, a contributing-evidence list per threat, a tunable risk score, and a decision hint.
You attach it to your existing API — typically as an X-Burein-Report HTTP header, or as a JSON field on the request body, or via any other channel your stack already uses. Burein never picks the transport. The signed report flows over your APIs, on your wire, terminating at the backend you already verify against.
Two consumers, both yours: your client (to make immediate UX decisions like step-up auth), and your server (to verify the signature and feed your risk model). Burein is in neither.
Browse all signals →{
"schema_version": "1.0.0",
"sdk": { "platform": "web", "version": "1.0.0" },
"collected_at": "2026-05-13T10:14:22Z",
"device": {
"visitor_id": "v1_b3c1...e7",
"confidence": 0.97
},
"signals": { ...1042 entries },
"threats": [
{ "id": "FRIDA_HOOK_DETECTED",
"severity": "critical",
"confidence": 0.98,
"evidence": [...] }
],
"risk": { "score": 87, "band": "high" },
"signature": {
"algorithm": "Ed25519",
"key_id": "host-app-2026-Q2",
"value": "..."
}
}Talk to us about your fraud and integrity goals — we'll show you the signals that matter for your stack.