Trust Score Engine:
Real-Time Risk Assessment in 20.8µs

Authentication is binary. Trust is continuous. A simple "authenticated" or "not authenticated" answer ignores crucial context: Is this user behaving normally? Is this device recognized? Is this location expected? Is the request pattern suspicious?

H33's Trust Score Engine answers these questions in 20.8 microseconds -- fast enough to run on every request without impacting latency. Integrated directly into the full-stack authentication pipeline that delivers 1.595 million authentications per second, the trust score adds continuous risk intelligence without adding meaningful overhead to the ~42µs per-auth budget.

Why Binary Auth Falls Short

Traditional authentication systems return a boolean: pass or fail. This model worked when threats were simpler, but modern attack surfaces demand richer signal processing. A credential that was legitimate five minutes ago might be compromised now. A device that was trusted last week could be jailbroken today. A login from New York at 9 AM is expected; the same credential from Lagos 30 seconds later is not.

Continuous trust scoring bridges this gap. Instead of a one-time gate, every request carries a confidence value between 0.0 and 1.0 that reflects the probability the request is legitimate. Downstream services consume this score to make granular authorization decisions: full access, read-only, step-up MFA, or outright denial.

A trust score is not a replacement for authentication. It is a continuous enrichment layer that turns a binary gate into a risk-aware policy engine.

The Trust Score Pipeline

Every authentication request flows through a five-stage pipeline that evaluates multiple risk signals:

The pipeline is designed for zero-copy data flow. Each stage operates on the same memory buffer, avoiding allocation overhead. The behavioral model and risk classifier both complete in sub-nanosecond time because they execute as lightweight lookup operations against pre-computed decision boundaries cached in the in-process DashMap -- the same 0.085µs-lookup store that powers H33's ZKP cache layer.

What Gets Evaluated

The trust score incorporates multiple signal categories, each contributing a weighted component to the final composite score:

• Device fingerprint: Hardware characteristics, browser configuration, installed fonts, WebGL renderer hash, and screen geometry. Each attribute is hashed independently, producing a composite device identity that tolerates minor changes (browser updates) while flagging major deviations (new hardware).
• Behavioral biometrics: Typing patterns, mouse movements, touch pressure, and scroll velocity. These signals are encoded as 128-dimensional feature vectors and compared against enrolled baselines using BFV FHE inner product -- the same encrypted computation that powers H33's core biometric match.
• Location context: IP geolocation, timezone consistency, and travel velocity. An impossible-travel detector flags requests that would require physically moving faster than commercial air travel between consecutive authentications.
• Session patterns: Request frequency, API usage patterns, time-of-day distributions, and endpoint access sequences. Sudden spikes in API call volume or access to previously unused endpoints reduce the score proportionally.
• Historical baseline: Deviation from the user's established patterns over a rolling 30-day window. The engine computes a z-score for each signal dimension: deviations beyond two standard deviations trigger score suppression.

Benchmark Results

January 2026 benchmarks show each component running well under target:

How Trust Scoring Fits the Full-Stack Pipeline

The trust score engine does not run in isolation. It is embedded directly into H33's single-API-call authentication pipeline, which chains BFV fully homomorphic encryption, STARK-based ZKP verification, and Dilithium post-quantum attestation into one ~42µs operation. The trust score runs in parallel with the ZKP lookup stage, so it adds zero latency to the critical path.

Because the trust score runs concurrently with the DashMap-backed ZKP cache lookup (0.085µs per query), it is entirely hidden behind the FHE batch computation. The result: you get continuous risk assessment with every authentication call at zero additional latency cost.

Using Trust Scores

Trust scores enable adaptive security policies. Rather than hard-coding access rules, your application can respond proportionally to risk level:

const result = await h33.auth.fullStack({
  userId: 'user_123',
  biometric: faceData,
  mode: 'turbo'
});

// Trust score: 0.0 (suspicious) to 1.0 (trusted)
if (result.trustScore < 0.5) {
  // Require step-up authentication
  await requireMFA(user);
} else if (result.trustScore < 0.8) {
  // Log for review, allow access
  auditLog.flag(result);
} else {
  // High trust, proceed normally
}

Score Thresholds and Policy Tiers

We recommend a four-tier policy model that maps trust scores to concrete actions:

• 0.9 -- 1.0 (High Trust): Full access. User behavior matches historical baselines across all signal dimensions. No step-up required.
• 0.7 -- 0.9 (Normal): Standard access with background logging. Minor deviations detected but within acceptable variance.
• 0.4 -- 0.7 (Elevated Risk): Require secondary verification. New device, unusual location, or behavioral drift detected. Trigger SMS OTP or biometric re-enrollment.
• 0.0 -- 0.4 (Critical): Deny access or require full re-authentication. Multiple anomaly signals firing simultaneously. Possible credential compromise or replay attack.

Privacy-Preserving Design

Trust scoring runs entirely on encrypted data using FHE. This is not a marketing claim -- it is an architectural requirement. The behavioral feature vectors that feed the trust score are encrypted under BFV before they leave the client. The server performs inner-product comparisons, deviation calculations, and anomaly detection entirely in the ciphertext domain. At no point does H33's infrastructure see raw behavioral signals.

• No raw biometrics stored: Only encrypted feature vectors, protected by BFV lattice-based encryption with 128-bit security
• No behavioral logs: Patterns computed on-the-fly from encrypted signals using homomorphic addition and multiplication
• No location history: Only encrypted deviation scores -- the server knows how far a value deviates from baseline without knowing the baseline or the value
• Zero-knowledge compatible: Prove trust level without revealing signals. The ZKP layer can attest that a trust score exceeds a threshold without disclosing the score itself

Even H33 can't see the signals that produce your trust score -- we only see the encrypted computation results. The Dilithium post-quantum signature on the attestation ensures that neither a classical nor a quantum adversary can forge the trust score output after the fact.

Privacy and performance are not tradeoffs. BFV FHE gives us both: encrypted computation at ~42µs per authentication, with trust scoring included at zero marginal latency.

Why 20.8 Microseconds Matters

Most risk engines operate asynchronously -- evaluating trust in the background and updating scores minutes or hours after the authentication event. By that time, a compromised credential has already been used. H33's approach is fundamentally different: the trust score is computed synchronously, inline with the authentication request, and returned in the same API response. At 20.8 microseconds, the trust engine adds less than half the latency of a single Dilithium signature verification.

This speed comes from three architectural decisions: zero-copy pipeline stages that avoid memory allocation in the hot path, in-process DashMap lookups at 0.085µs for pre-computed baselines, and branch-free scoring logic that eliminates pipeline stalls on modern ARM cores. On the production c8g.metal-48xl with 96 Graviton4 workers, the trust engine scales linearly to 3.1 million scores per second.