Start in Observe on one route. Use the deployment URL and installed package version supplied for your workspace. Historical host examples and source capabilities do not establish a live service or published release.
Verification Flow
sequenceDiagram
participant Browser
participant Alias as Your first-party collector alias
participant Gate as MANDATE Gate
participant Backend as Your protected route
Browser->>Gate: Load verification script
Gate-->>Browser: Verification payload
Browser->>Browser: Background verification
Browser->>Alias: Submit encrypted verification
Alias->>Gate: Proxy encrypted collector request
Gate-->>Browser: Set HttpOnly Mndt-Sess
Browser->>Backend: Protected request with Mndt-Sess
Backend->>Gate: Hosted verification of credential and request proof
Gate-->>Backend: Live decision and authenticated updatesStep 1: Script Loads
Add the MANDATE script to your page. It loads asynchronously and does not block rendering or require any user interaction.
Step 2: Browser is Verified
The script performs invisible verification in the background and collects browser-integrity and request-context evidence. MANDATE uses that evidence to make route-scoped trust decisions; it does not claim to prove that a human is operating the browser. This process is automatic and requires no user interaction.
Step 3: Server Credential Issued
After successful verification, production deployments issue a short-lived, signed HttpOnly Mndt-Sess credential. The page does not receive raw token material to inspect. The credential remains a bounded bearer credential: HttpOnly limits direct page-script reads, but does not make copied cookies, captured browser profiles, same-origin scripted requests, XSS, or endpoint compromise replay-proof.
Step 4: Your Protected Route Enforces
Protected browser routes enforce the server-issued credential at the same-origin boundary. For protected browser actions, hosted validation adds one-shot replay, route proof, request proof, lineage, and freshness checks. Local X-Mndt verification remains available for non-production compatibility, SDK tests, and bounded legacy integrations. Offline Emergency uses its dedicated scoped reader.
Key Properties
| Property | Benefit |
|---|---|
| Background verification | Trusted sessions continue without visible challenge UI |
| Short-lived tokens | 15-minute TTL limits exposure |
| Server-issued credential | Bounded same-origin continuity; use hosted validation for one-shot replay-sensitive actions |
| Opaque tokens | Header compatibility tokens cannot be decoded without your secret |