THE ENGINE PIPELINE — VAULT ALONGSIDE, NOT ANOTHER STEP
1
Input. A request arrives from a person, application, or agent, via a Gateway lane or the Workspace.
2
Detection. The self-hosted PII model finds sensitive spans in free text; deterministic validators handle structured identifiers on a fast path.
3
Tokenization. Detected values become typed tokens — PHONE_8f3a — and the mapping is written to the vault.
4
Policy. Rules decide what is masked, blocked, allowed, or held for approval — per user, app, agent, data class, and destination.
→
External AI. The tokenized request crosses the boundary; the provider writes its answer around the tokens.
5
Streaming restore. Tokens in the response are resolved against the vault and restored inline as the stream arrives.
6
User or agent. The caller receives the restored answer; every decision and restore lands in the audit stream.
Vault
token ↔ value
mapping
written at step 3
read at step 5
customer keys
audited access

One engine behind every surface#

The engine is the invariant part of the platform. Whether traffic arrives from an application pointed at the gateway, from the Salus Desktop endpoint agent on a managed laptop, or from the Workspace client, it lands in the same pipeline: detect → tokenize → policy → egress → restore. That is why tokens stay consistent across surfaces, why policy is written once, and why the audit trail is one stream rather than one per product.

The components#

  • Gateway / data plane — receives traffic from capture lanes, orchestrates mask → forward → restore, and originates provider egress. Stateless and horizontally scalable.
  • Detection engine — the self-hosted PII model for free text, deterministic validators for structured identifiers, and optional visual detection for documents and images. Runs entirely inside the customer environment.
  • Tokenizer — typed, deterministic, HMAC-backed token generation with configurable scope, as described in Tokenization.
  • Vault — the token-to-value mapping, envelope-encrypted under customer-controlled keys. Covered in Vault.
  • Policy engine — declarative rules per user, group, app, agent, data class, destination, and risk level. Policy-as-code; a bad policy push is rejected and the last-known-good policy stays active.
  • Audit and observability — policy decisions, token events, and restores, exported to the customer SIEM. Logs carry tokens and metadata rather than raw values.

Trust property#

The division of labor is deliberate: the local detection intelligence is allowed to see real values because it runs inside the customer environment; the external answer-writing model cannot see them because it receives tokens only. Everything that can re-identify a token — vault, keys, policy, restore — stays on the customer side of the boundary.