Skip to main content

Platform architecture

ThreatLens sits between your people and the AI models they use, so every request passes a single governed checkpoint before a model ever sees it. The same core deploys three ways — in our cloud, inside your own cloud, or fully on‑premises. What changes between them is the trust boundary and where inference and data‑at‑rest live.

The governed checkpoint

Identical in every deployment. Before a model receives anything, ThreatLens:

StageWhat it does
IdentitySigns the user in (SSO / SCIM) and trims access to what they're already permitted to see.
Classify & DLPDetects sensitive content and redacts or withholds it.
Policy & RouteDecides allow / warn / block, and which model may serve the request.
AuditWrites an immutable, per‑request record of the decision.

Public cloud · SaaS

ThreatLens runs the governed checkpoint and stores governed data in our multi‑tenant cloud. You connect your identity provider and content sources; models are reached through governed egress to provider APIs.

ThreatLens public cloud (SaaS) architecture: users and content sources connect into the ThreatLens cloud, which holds the governed checkpoint and an encrypted, tenant-isolated store; governed egress reaches external model providers.

Best when you want the fastest path to adoption with no infrastructure to run.

Private cloud · your VPC

The same checkpoint and encrypted store run inside your cloud account. Governed data never leaves your VPC; models are reached by governed egress from your network using your keys. ThreatLens delivers software and policy updates through a control‑plane link only.

ThreatLens private cloud architecture: the governed checkpoint, encrypted store and content connectors run inside the customer's own cloud account; models are reached by governed egress from the customer VPC; a thin control-plane link brings policy and software updates from ThreatLens.

Best when data residency or single‑tenant isolation matters and you want ThreatLens running inside a boundary you already control.

On‑premises · air‑gap capable

Everything — checkpoint, store, and the model itself — runs inside your data center. Inference uses a private model on your own infrastructure, so there is no runtime dependency on any external service. Egress to approved providers is optional and off by default.

ThreatLens on-premises architecture: users, content connectors, the governed checkpoint, the encrypted store and a private local model all run inside the customer's data center perimeter, which is air-gap capable.

Best when you operate under strict isolation, sovereignty, or air‑gap requirements and inference must stay on infrastructure you own.

Choosing a deployment

The governed checkpoint is identical across all three. These are the real trade‑offs.

Public cloud (SaaS)Private cloud (your VPC)On‑premises
Runs inThreatLens cloudYour cloud accountYour data center
Governed data at restThreatLens tenant — encrypted, isolated, your retention policyYour VPC — never leaves your accountYour perimeter — never leaves your walls
Model inferenceProvider APIs (your keys or included credits)Provider APIs, egress from your VPC (your keys)Private / local model on your infrastructure
Runtime dependency on ThreatLens cloudYes — it is the serviceControl plane only (policy & updates)None — air‑gap capable
Adopt it whenSpeed; no infra to runResidency & VPC controlStrict isolation / sovereignty
note

This page is a conceptual reference to how ThreatLens is structured and deployed. Exact component boundaries and integrations are confirmed for your environment during onboarding.