Deployment & isolation
DataStrict for Private Cloud.
Single-tenant software you run inside your own perimeter - 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 crosses your perimeter 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.
For the runtime that does the enforcing, see the Enforcement Fabric and the control layer.
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.
Containers
One shared kernel. Isolation by namespaces + cgroups.
Virtual machines
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.
# 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: RuntimeDefaultWhy in-perimeter 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?
Is a container as isolated as a virtual machine?
Does DataStrict ever see our data?
Can it run fully air-gapped?
What is single-tenancy and why does it matter?
How do we verify the image we run?
Govern AI like infrastructure.
Talk to our team about deploying DataStrict across your enterprise stack.