DataStrict for Private Cloud.

Single-tenant software you run inside your own environment - private cloud, on-premises, or air-gapped - never a multi-tenant service you route your data through.

An enforcement boundary sees the most sensitive traffic in the company, so it has to live inside the same trust boundary as the data it protects. Private cloud is the flagship shape; on-premises and air-gapped are the same architecture in stricter environments. This is the technical account of how it deploys and why that topology is the security control.

The thesis

Deployment topology is the first security control, not an afterthought.

DataStrict sits in the request path and sees everything: every prompt, retrieval, tool call, and model output passes through it before it is allowed. That concentrates the most sensitive traffic in your company at a single point.

A governance layer that runs in a vendor's multi-tenant cloud is not a boundary - it is an exfiltration path with a dashboard. The moment governed data leaves your environment to reach the thing that governs it, the control has already failed at the only place that matters.

So the topology is the control. We sell you the software, not a seat in our cloud. It runs where your data already lives, behind your firewall, under your keys - and we never receive a byte of governed traffic.

Deployment topologies

Three shapes, one boundary. The difference is who owns the metal.

On-premises and private cloud are often treated as the same thing. They are not. Both keep DataStrict inside your trust boundary, single-tenant, under your keys - the difference is where the hardware lives and where the shared-responsibility line falls. Air-gapped is the strictest form of both: the same software with the network route to the outside world removed entirely.

Dimension	Private cloud (BYOC)	On-premises	Air-gapped
Where it runs	Your own AWS / Azure / GCP account, inside your VPC	Your datacenter - bare metal or your own hypervisor	An isolated network with no route to the internet
Who owns the hardware	The cloud provider owns the metal; the account and tenancy are yours	You own the physical machines	You own it, typically on-prem
Network egress	Governed by your VPC routing; egress-deny by default	Governed by your firewall; none required to operate	None - zero egress, no phone-home, no license callout
Isolation model	Account + VPC + single-tenant	Physical + single-tenant	Physical + network + single-tenant
Patch & upgrade cadence	Yours - you pull the image on your own schedule	Entirely yours	Offline images loaded from a tarball, on your schedule
Best fit	Cloud-native teams that want elasticity inside their own boundary	Existing datacenter estates that want full physical control	Classified, sovereign, or strictly regulated environments

For the plain-language overview and the commands to run it, see self-hosted deployment. This page is the deeper account of the isolation underneath it.

First principles

What a container actually is - and why we ship one.

A container is not a small virtual machine. It is a single process (plus its dependencies) running directly on the host's Linux kernel, made to believe it is alone on the machine. Three kernel features do that: namespaces isolate what the process can see (its own view of process IDs, network interfaces, mounts, users, and hostname); cgroups cap what it can consume (CPU, memory, I/O); and a layered, immutable filesystem gives it a fixed, reproducible root.

container vs. virtual machineSHARED KERNEL

Containers

App A

DataStrict

App B

Container runtime

Host OS / kernel

Hardware

One shared kernel. Isolation by namespaces + cgroups.

Virtual machines

Guest OS + App

Hypervisor

Host OS

Hardware

A full guest OS per workload. Heavier, stronger.

A virtual machine, by contrast, runs a whole guest operating system with its own kernel on top of a hypervisor that virtualizes the hardware. That is a heavier, stronger boundary. A container is lighter and starts in milliseconds because it shares the host kernel - which is why kernel-level hardening (dropped capabilities, seccomp, non-root, read-only rootfs) matters so much, and why the optional microVM and enclave layers exist for workloads that want both.

We package DataStrict as one signed OCI image because it is the most boring, most auditable unit of software your platform team already knows how to run in your own private cloud: scan it, pin it by digest, roll it back, and run it under the exact same controls as everything else in your estate. No bespoke installer, no agent sprawl, no kernel modules.

Defense in depth

Seven layers between an attacker and governed data.

No single mechanism is trusted to hold. This is defense in depth: the layers are concentric - outermost network to innermost enclave - so a failure at any one of them still leaves the next intact.

Network perimeter

A private VPC and subnets, security groups, and an egress-deny network policy. Service-to-service traffic is mutually authenticated (mTLS). Nothing routes out that you have not allowed.

Tenancy

Single-tenant by default: your own instance, with no compute, database, or memory shared with another customer. The cross-tenant blast radius of a multi-tenant SaaS control plane simply does not exist here.

Host / node

Dedicated compute. For stronger separation, the gateway can run inside a microVM (Firecracker, Kata Containers) or under a user-space kernel (gVisor), so a container escape meets a second, VM-grade wall instead of the host.

Container runtime

The process runs as a non-root UID on a read-only root filesystem, with every Linux capability dropped, a seccomp-bpf syscall filter, no-new-privileges set, no privileged mode, and a distroless base image - the smallest possible attack surface.

Supply chain

A signed OCI image (Sigstore / cosign) with an SBOM and SLSA build provenance, pinned by digest and gated by admission control - so only the exact, attested build you reviewed is ever admitted to run.

Keys & data

Encryption keys, model credentials, and TLS private keys live in your KMS or vault; the Ledger is written to a database you run. DataStrict cannot decrypt or exfiltrate what it never holds.

Confidential computing (optional)

Run inside a hardware-encrypted enclave (AMD SEV-SNP, Intel TDX) so memory is encrypted in use and even the host operator cannot read it - with remote attestation to prove exactly what is executing.

The host-isolation and confidential-computing layers (microVM and hardware enclaves) are supported deployment patterns for teams that want them; the default single-tenant container already delivers the network, tenancy, runtime-hardening, supply-chain, and key-custody layers.

Runtime hardening

Least privilege, written down.

The container ships to run non-root, read-only, and unprivileged, with every Linux capability dropped and a seccomp profile that allows only the syscalls the gateway needs. It is the same posture whether you run it under Docker on a single host or as a pod in your cluster.

Nothing here is exotic. It is the hardened baseline any security team would demand of a workload that sits in the request path - stated explicitly so there is nothing to discover.

runtime hardeningREFERENCE CONFIG

# Docker - non-root, read-only, unprivileged
docker run \
  --read-only \
  --cap-drop=ALL \
  --security-opt=no-new-privileges \
  --security-opt=seccomp=default.json \
  --user 10001:10001 \
  datastrict/gateway@sha256:<digest>   # pinned + signed

# Kubernetes - the same posture as a securityContext
securityContext:
  runAsNonRoot: true
  runAsUser: 10001
  readOnlyRootFilesystem: true
  allowPrivilegeEscalation: false
  capabilities:
    drop: ["ALL"]
  seccompProfile:
    type: RuntimeDefault

Why your environment wins

Why this is the most defensible way to govern enterprise data and AI.

Data never leaves your boundary

Every prompt, retrieval, tool call, and model output is adjudicated in-process, inside your network. No governed byte is transmitted to us, there is no telemetry channel, and there is no phone-home to switch off - because there is none to begin with.

Single-tenant blast radius

One deployment, one tenant. No shared control plane, no shared database, no noisy neighbor. A compromise of another customer cannot reach you, because in your instance there is no other customer to compromise.

Minimal trust in the vendor

We ship a signed image; you hold the keys. We never receive your traffic, never hold your KMS or TLS private keys, and require no outbound connection. The software is a deterministic function your team can inspect and pin.

Kernel-level container isolation

Namespaces partition what the process can see (PIDs, network, mounts, users); cgroups cap what it can consume; seccomp-bpf and dropped capabilities shrink the reachable syscall surface to the minimum the gateway needs and nothing more.

Supply-chain integrity

Every image is signed, carries an SBOM, and ships with SLSA build provenance. You pin it by digest and enforce verification with admission control, so no silent update and no substituted layer can ever slip into the boundary.

Sovereign and compliant by construction

Air-gap support, in-jurisdiction data residency, and customer-held evidence (the Ledger in your own database) map directly onto FedRAMP-style authorization boundaries, HIPAA, GDPR residency, and classified-network rules.

FAQ

Deployment & isolation, answered.

What is the difference between on-premises and private cloud deployment?

On-premises means DataStrict runs on hardware you own, in your own datacenter. Private cloud (BYOC, bring-your-own-cloud) means the same single-tenant software runs inside your own cloud account - your AWS, Azure, or GCP VPC. The practical difference is who owns the metal and where the shared-responsibility line falls. In both, the software sits inside your trust boundary, runs under your keys, and never sends your data to us.

Is a container as isolated as a virtual machine?

A container shares the host kernel and isolates the workload with namespaces, cgroups, and seccomp; a virtual machine runs its own guest kernel over a hypervisor, which is a stronger boundary but heavier. When you need VM-grade separation with container portability, DataStrict can run inside a microVM (Firecracker or Kata Containers) or under a user-space kernel (gVisor), or inside a confidential-computing enclave - so a container escape still meets a second wall.

Does DataStrict ever see our data?

No. The gateway runs in-process inside your own environment. Governed traffic is adjudicated locally and is never transmitted to us, so there is no data egress to a vendor. There is no phone-home, no telemetry channel, and no outbound connection required to operate.

Can it run fully air-gapped?

Yes. Air-gapped deployment loads the image from a tarball with no registry, needs no license server or callout, and operates with zero egress. It is the intended shape for classified, sovereign, and strictly isolated networks, and it keeps data residency absolute by construction.

Does semantic detection need an external AI service?

No. The machine-learning classifiers that score every request run inside the gateway, and the adjudication model that reviews genuinely ambiguous cases deploys alongside it, inside your own environment - air-gapped included. Sending your traffic to a third-party API to decide whether it is safe to send out would invert the guarantee, so we don't. The models in this path are developed and trained in the United States, and every model-graded verdict names its model on the signed Ledger record.

Is DataStrict quantum-safe?

Yes. Connections into the gateway use hybrid post-quantum cryptography (ML-KEM), and every record in the audit Ledger is signed with a post-quantum signature (ML-DSA), so traffic and evidence resist a harvest-now, decrypt-later attack. Because you hold the keys and run it inside your own environment, the protection is yours to verify - air-gapped deployments included.

What is single-tenancy and why does it matter?

Single-tenant means one deployment serves exactly one customer, with no shared compute, database, or memory. It removes the cross-tenant blast radius that a multi-tenant SaaS control plane carries, so another customer's incident can never reach your instance.

How do we verify the image we run?

Every release is a signed OCI image with an SBOM and SLSA build provenance - software supply chain assurance end to end. You pin it by digest and enforce signature verification with admission control, so only the exact, attested build you reviewed is ever executed inside your boundary.

Read the support docs

Govern AI like infrastructure.

Talk to our team about deploying DataStrict across your enterprise stack.

Request a demo Contact sales