Operate inside the boundary
Keep agent orchestration, tool use, data access, and model calls within customer-controlled infrastructure—without a public model API or external SaaS control plane at runtime.
Tightest controls · Your inference · Your boundary
Air-gapped agentic AI for
defense and intelligence environments.
When your environment demands the tightest controls, run Decision Terrain inside it: agents, tools, and review on your infrastructure, connected to the inference stack your organization selects. DT engineers are available to help you deploy.
Governed agent platform
Your inference stack
Optional DT engineers
Deployment mode. Air-gapped deployment places the platform, inference, and required tools inside your environment. It does not mean every DT platform capability operates offline; the supported configuration defines which do.
Review DT platform deployment options01 / Operating requirement
The capability must fit the boundary—not ask the boundary to move.
Many agent platforms assume access to hosted models, public APIs, external telemetry, and vendor-managed services. Those assumptions do not carry into disconnected or tightly controlled environments.
Air-gapped agentic AI needs a different deployment model. The runtime operates with local inference, while each tool and workflow is built for the systems and authorities inside the boundary. Our air-gapped agentic AI architecture reference shows how those layers and trust boundaries fit together.
Use the inference you approve
Connect the platform to the organization’s selected on-premises or enclave-accessible inference stack instead of forcing the mission into a predetermined model provider.
Fit the systems already there
Integrate agents with approved data, tools, identity, logging, policy, and human-review points so the capability reflects the environment in which it must operate.
Leave a maintainable capability
Build the deployment, documentation, evaluation practices, and knowledge transfer required for the customer team to understand and operate what has been delivered.
02 / Solution model
One platform, deployed inside your environment.
This is not a cloud product repackaged for an enclave. The platform deploys inside your environment, connects to approved inference, and runs a bounded workflow you can test where it will operate. Review the security and governance controls with the people who will accredit it.
Discuss the target environmentThe DT platform, inside your boundary
Deploy the agent runtime, orchestration, tool interfaces, and governance controls on your infrastructure, with no external control plane at runtime.
Starting point: a running platform baseline inside the target environment.
Customer-selected inference
Connect the platform to the inference service, model runtime, or accelerator stack your organization has approved.
Starting point: working model access with known performance and operating constraints.
Mission workflow integration
Connect agents to the local tools and data required for a defined workflow, with clear boundaries around permissions, actions, and human oversight.
Starting point: a bounded workflow you can exercise and evaluate in context.
Optional DT engineers
Add DT engineers to your mission, platform, and security teams for deployment, integration, testing, and knowledge transfer.
Starting point: a supported path from first deployment to your own operation.
03 / Optional engineering
Deployment happens with the teams who own the environment.
Optional DT engineers work with your technical, mission, and security teams to resolve constraints and transfer operational knowledge.
Define the boundary and workflow
Identify the user, decision, data, allowed actions, infrastructure, inference options, and operating constraints before choosing a deployment topology.
Establish the in-environment baseline
Deploy the platform and connect it to the chosen inference layer using components suitable for the target environment.
Integrate and evaluate
Add the smallest useful set of tools and data, then test task performance, failure modes, permissions, observability, and human-control points.
Operationalize and transfer
Document the architecture, automate repeatable operations, train the customer team, and define the support model for continued improvement.
04 / Principles
Customer control is an architectural requirement.
The platform is designed around customer control and a clear transfer of responsibility, not dependence on Decision Terrain as a permanent external control plane. That responsibility includes a documented, reversibleair-gapped AI model update lifecycle for models, runtimes, and dependencies.
Your infrastructure, your control
The platform runs on infrastructure you control, with no external control plane at runtime. Your team operates it and sets the policy.
Inference choice stays yours
Model and runtime decisions follow the mission, infrastructure, and evaluation evidence—not a required commercial inference provider.
Built for the tightest controls
Exact-call review, audit evidence, and halt from your security tools are part of the platform, not add-ons. The supported configuration confirms which apply in your boundary.
Customer authorities remain authoritative
Your platform, security, and authorizing teams keep their decisions and authorities. DT is built to support them, not replace them.
05 / Practical questions
What teams usually need to know first.
A credible starting scope depends on the target boundary, available infrastructure, selected inference, and one defined workflow. Those facts matter more than a generic feature list.
What does air-gapped mean in this solution?
The target capability is designed to operate without public model APIs or an external SaaS control plane at runtime. The exact architecture depends on the boundary, infrastructure, and components the customer approves.
Which models and inference systems can it use?
The organization’s inference of choice, provided the selected runtime exposes an interface that can be integrated and meets the environment’s technical and operating requirements.
Why use DT for an air-gapped environment?
Because the controls are part of the product. Agents, inference, tools, review, and audit evidence all run inside your boundary, so you aren’t assembling and accrediting separate pieces. Teams with the tightest requirements get one platform they can test where it will operate.
What can DT engineers help with?
Optional DT engineers can help with architecture, deployment automation, inference integration, agent and tool development, evaluation, troubleshooting, documentation, and knowledge transfer. Your team can also deploy from the platform documentation on its own.
06 / Get started
See it in your boundary.
Start with one workflow.
At an unclassified and non-sensitive level, describe the target environment, candidate inference, and one workflow. We’ll show you the platform and what a first deployment would take.
Request an air-gapped demo