Deploy AI behind the air-gap. Prove what’s running.
Package models, containers, and configs into a signed offline bundle with fail-closed egress enforcement. Zero cloud dependencies.
Every private AI deployment starts with the same unanswered questions.
What exactly are we installing? Which licenses apply? Does it phone home at startup? Can we verify the installed files match what was approved? What changed in the new release? Teams answer these manually — inspecting repos, comparing manifests, writing one-off scripts that break on the next deployment.
Uncontrolled Outbound Connections
An inference server, embedding model, or document parser can silently contact external registries, license servers, or cloud APIs at startup. Without observation and enforcement, you don't know what your stack is doing — and your security review blocks the deployment.
No Cryptographic Proof of What Was Installed
Without SHA-256 hashes and a signed manifest for every artifact, your security team cannot confirm that what's running in production matches what was approved. A year later, an audit will ask — and you won't have the answer.
Unrepeatable, Undocumentable Deployments
The first deployment works. The second one is different. A new model version changes three dependencies, adds an external endpoint, and invalidates the hardware sizing. Without a release process, every update is a new project.
One workflow. Ten steps. Everything stays inside your environment.
Describe, test, package, and control your release.
Describe the release
Record exactly what the AI system contains: component versions, image digests, model file hashes, hardware requirements, and dependency relationships. No floating references. No "latest."
Test the release
Run eBPF network observation during startup, model loading, inference, and error paths. Scan every dependency for known vulnerabilities, model and software licenses, and hard-coded download behavior.
Package the release
Create a signed offline bundle: artifacts, SBOM/ML-BOM inventory, observed network policy, test evidence, local verifier binary, and deployment instructions — all hashed and ed25519-signed with your keys.
Control the release
Inside your environment, install the local policy that blocks every connection not explicitly approved. Run self-tests that confirm allowed paths work and prohibited paths are blocked — across IPv4, IPv6, and DNS.
Built for critical industries, including healthcare, financial services, and defense.
Air-Gap Native by Design
The local verifier, policy installer, and acceptance runner are static binaries with no external dependencies. No daemon. No cloud agent. No remote monitoring of your environment. What runs inside stays inside.
Fail-Closed Enforcement
Every allowed connection is explicitly approved. If the policy fails to load, the system reports failure — it never defaults to allow-all. Self-tests cover approved destinations, prohibited destinations, IPv4, IPv6, and DNS on every targeted container or Pod.
Cryptographic Integrity
SHA-256 hashes on every artifact. ed25519 signature on the release manifest. Customer-held keys — Enclave's signature identifies the publisher, but it is never the only trust decision. A second build from the same inputs must produce the same result or explain the diff.
Local-First Evidence
Release manifests, SBOM, network observations, benchmark results, vulnerability findings, exceptions, and approvals are stored inside your environment. Nothing leaves unless you export it. Evidence is labeled declared, observed, or inferred — so a README claim is never confused with a measured result.
From stack definition to accepted deployment, in a defined process.
The first nine steps happen in a connected staging environment. The last step — and all updates after it — happen entirely inside your restricted site.
| # | Step | What happens |
|---|---|---|
| 01 | Define the project | Record the target environment, hardware, network mode, and approval policy. |
| 02 | Define the stack | Add every component: model, inference server, vector DB, document parser, containers. |
| 03 | Resolve the release | Freeze versions, resolve image digests and model hashes, record all dependencies. |
| 04 | Run checks | Scan licenses, known CVEs, download-on-start behavior, and hard-coded endpoints. |
| 05 | Observe the network | Run the workload with eBPF tracing; classify every outbound connection during startup, model load, inference, and error paths. |
| 06 | Resolve findings | Fix, replace, exception-approve, or accept each finding with a named approver and expiration date. |
| 07 | Build & sign the bundle | Package artifacts, evidence, verifier, and policy. Sign the release manifest with customer keys. |
| 08 | Transfer & verify | Customer transfers bundle via approved process. Local verifier checks signature and all artifact hashes before anything installs. |
| 09 | Apply policy & test | Install Enclave Guard. Confirm approved connections work and prohibited ones are blocked — across IPv4, IPv6, and DNS. |
| 10 | Accept & update | Generate local acceptance report. On the next release, compare manifests to see exactly what changed: components, versions, hashes, licenses, network behavior. |
Start with a fixed-scope Assessment for one AI stack.
One stack. One target environment. Full evidence report, signed bundle, and acceptance procedure as the deliverable.
Start with a single stack. One environment. Fixed scope.
The first engagement is a managed release Assessment. You supply the stack and target environment. We build the release manifest, run the checks, observe the network, and produce the signed bundle with a full evidence report and acceptance procedure. No annual commitment required to start.
Access Requested
Thank you for joining the evaluation program. We will contact you soon with pre-release of Enclave.