There is a design assumption embedded in almost every network security and analytics platform that is rarely made explicit: the daemon trusts the client to decide what the user is allowed to see.
Role-based access control. UI-level field masking. Query-result filtering. These are all variations on the same pattern. The server sends the full dataset. The client software decides what to render. Enforcement lives in the display layer.
This has one fatal property: the data the user is not supposed to see is nevertheless transmitted to their machine, in cleartext, before any enforcement decision is made. A compromised client, a misconfigured one, a debug build with filters disabled — any of these collapses the model instantly. The data was already there.
For deployments carrying PII, subscriber identifiers, authentication tokens, or regulated content — which describes most enterprise and all carrier deployments — client-side enforcement is not a security model. It is a UI convention dressed up as one.
Vantage inverts the model entirely.
Enforcement at the Daemon, Never the Client
In Vantage, enforcement happens inside the daemon processes before a single byte is transmitted to any client. Content above a session's clearance is not redacted on the way out. It is never decrypted in the first place. The encryption keys required to read it are not derivable from the session's key material.
A compromised Lynx client — the analyst-facing frontend — shows its user exactly the same data as an uncompromised one: whatever the daemon decided the session's clearance permitted. There is no client-side code path that could, if subverted, reveal more. The data that would be revealed was never transmitted.
This is not a policy configuration. It is a cryptographic property of the architecture.
Three Daemons, One Clearance Model
Vantage is three specialized daemons, each owning a distinct part of the data lifecycle, each enforcing the same clearance model in its own domain.
Sentinel owns the wire. It captures packets, runs the Protocol Stack, writes the capture file with the Query Analytics Tree and events stream embedded, and performs encryption at capture time. Sentinel's external surface is deliberately narrow — it publishes statistics and service-discovery beacons, but never serves packet content directly to users. Its attack surface is minimized by keeping user sessions out of its process space entirely. A Lynx compromise does not expose Sentinel's key hierarchy.
Lynx is the analysis daemon — where user sessions live. When an analyst connects via the web frontend, terminal UI, or pipe interface, the connection attaches to a Lynx daemon that resolves the session clearance, derives only the decryption keys that clearance permits, decrypts only the fields the session can access, applies obfuscation and redaction, and emits the result. Multiple analysts can share a live session. Each person's clearance rides independently with their own session — not the inviter's.
Quarry is the virtual filesystem and control-plane daemon. It owns the Token Stream projection surfaces that AI and ML pipelines attach through, and it owns the Vantage Ledger — the cryptographically chained audit record shared across all three daemons. Every access through Quarry runs through the same enforcement pipeline as Lynx.
The 0–20 Clearance Scale
A unified 0–20 clearance scale drives encryption strength, PII obfuscation, redaction policy, and access control in a single dimension. Every field in every token has a sensitivity level. Sessions that lack the clearance to read a field never receive the key material needed to decrypt it.
The same underlying capture produces different output for different sessions simultaneously. A level-15 SOC analyst attached through Lynx and a level-7 ML inference pipeline attached through Quarry read different projections of the same data — produced independently by different daemons, without either session's output being visible to the other.
Level 0 — the default for single-user standalone deployments — applies no enforcement overhead beyond standard file permissions. The security model scales in complexity only as the deployment's clearance requirements scale. Roughly ninety percent of users operate at level 0 and never interact with the clearance system at all.
The Split-Clearance Pattern for AI
The most consequential application of the clearance model is what we call the split-clearance pattern for AI and ML pipelines.
The governance question that kills most AI deployments in regulated environments is: where does our data go, and under whose enforcement? Vendor-hosted AI platforms require shipping captured traffic — including PII, authentication tokens, and sensitive content — into someone else's environment. Data-governance reviews on this posture fail frequently for exactly that reason.
The split-clearance pattern sidesteps the question entirely. The ML model runs in the customer's own infrastructure, at whatever clearance level fits its operational context. Quarry projects the Token Stream down to that clearance before transmission. Sensitive data never leaves the Quarry daemon in readable form. The model trains on and infers against the projection its clearance permits — the same token structure as a higher-clearance session, with PII tokenized to consistent pseudonymized values that preserve joinability without exposing identifiers.
The governance question becomes trivial: the data does not go anywhere. The model consumes a filtered view that cannot expose more than the filter allows.
For customers whose AI governance reviews have previously failed on vendor platforms, the split-clearance pattern is often the architectural difference that lets the deployment proceed.
The Vantage Ledger
Every enforcement decision across all three daemons is recorded in the Vantage Ledger — a Merkle-chained audit record owned by Quarry and written to by Sentinel and Lynx. Every session open and close, every field access at every clearance level, every encryption key derivation event, every obfuscation application.
The Ledger is not something an operator enables. It is a property of the enforcement pipelines running. For regulated environments — lawful intercept, financial services, healthcare, government — the Ledger is the compliance proof layer, produced automatically as a consequence of the platform operating.
The Architectural Claim
The Vantage security model rests on one claim, and every other decision is constructed to support it: a client that is compromised, misconfigured, or operated by an unauthorized user cannot access data above its clearance level — not because the software refuses to display it, but because the data was never transmitted in a readable form. Bypassing enforcement is cryptographically impossible.
This is a different claim from "our access control is very good." Access control can be circumvented. Cryptographic enforcement cannot be circumvented by the client, because the client never had the keys.
Read the Full Architecture Paper
The whitepaper covers the three-daemon model in depth, the nine-stage enforcement pipeline, the key hierarchy, per-user session projections, and the Vantage Ledger chain format.
Read the Whitepaper