Security
Mastering LLM security: an air-gapped approach for high-security deployments
How to secure LLMs and AI agents in high-security environments: the OWASP 2025 risks, when an air-gapped deployment pays off, and the controls it still needs.
Maria-Elena TzanevAI strategy6 min readUpdated 
In short
An air-gapped LLM deployment runs the models, data and agent platform on infrastructure with no connection to outside networks, so prompts and documents cannot reach third parties. It suits classified and highly regulated workloads, but it does not remove LLM-specific risks such as prompt injection or excessive agency, which still need guardrails, approvals, access control and tracing.
LLM security means protecting the models, the data they read, the prompts and outputs they exchange, and the actions agents take. An air-gapped deployment is the strictest option: models, data and the agent platform run on infrastructure with no connection to outside networks, so nothing can leak to a third party. It removes the network as an attack path, but not the risks inside the application, such as prompt injection, over-privileged agents or poisoned models, so those still need their own controls.
This guide covers the main LLM security risks, when an air gap is worth its cost, what it does not protect against, and what running LLMs in an isolated environment takes.
What are the main security risks for LLM applications?
The OWASP Top 10 for LLM applications is the most widely used reference. Its 2025 edition lists these risks, with the controls that address each:
| Risk | What it means | Main controls |
|---|---|---|
| Prompt injection | Input, including text inside documents or web pages, overrides the system's instructions | Input detectors, least-privilege tools, approvals |
| Sensitive information disclosure | The system reveals personal, financial or confidential data | PII detection, permission-aware retrieval, output checks |
| Supply chain | Compromised models, datasets, packages or plugins | Verified sources, checksums, scanning, internal registries |
| Data and model poisoning | Tampered training, fine-tuning or retrieval data changes behavior | Data provenance, evaluations before release |
| Improper output handling | Model output is passed to other systems without validation | Output validation, sandboxed execution |
| Excessive agency | An agent has more permissions or autonomy than its task needs | Narrow tools, approvals on consequential actions |
| System prompt leakage | Instructions or secrets in prompts are exposed | Keep secrets out of prompts, test for leakage |
| Vector and embedding weaknesses | Retrieval stores leak data across users or accept poisoned content | Access control on retrieval, ingestion checks |
| Misinformation | Confident but false outputs are trusted | Grounding with citations, human review |
| Unbounded consumption | Runaway usage drives cost or denies service | Rate limits, loop caps, cost monitoring |
What is an air-gapped LLM deployment?
An air-gapped deployment runs every component inside a network with no path to the internet or other outside networks: the models and inference servers, vector stores and databases, the agent platform, identity, logging and monitoring. Models, software updates and data enter only through controlled, audited transfers. See our glossary entry on air-gapped deployment for a short definition.
It differs from the more common self-hosted setup, where the platform runs in your own cloud account or data center but can still call outside model providers through egress you control. The table below compares the options:
| Managed cloud | Self-hosted with controlled egress | Fully isolated (air-gapped) | |
|---|---|---|---|
| Where data lives | The vendor's cloud | Your cloud account or data center | Your isolated network |
| Outside calls | To the vendor and model providers | Only to providers you allow | None |
| Models | Hosted and open models | Hosted and self-hosted models | Self-hosted open-weight models only |
| Updates | Continuous, by the vendor | Your schedule | Controlled transfers on your schedule |
| Operational effort | Lowest | Moderate | Highest |
When does an air-gapped deployment make sense?
Choose an air gap when the data or the mission cannot tolerate any outside connection:
- Government and defense work with classified or mission-critical information.
- Critical infrastructure operators whose control networks are isolated by design.
- Financial institutions processing core banking or trading data under strict internal rules, where supervisors or policy rule out external processing.
- Healthcare and life sciences organizations handling patient or genomic data in isolated research environments.
For many regulated organizations, a self-hosted deployment with egress limited to approved providers, or to no providers at all for sensitive workflows, meets the requirement at lower cost. Decide per workload, not per organization: the same bank may run a public-data research assistant in a managed cloud and a customer-data agent fully inside its own network.
What does an air gap not protect against?
An air gap stops data from leaving over the network. It does not make the application itself safe:
- Prompt injection still works. A malicious instruction inside an internal document or an email the agent reads needs no internet connection.
- Insiders keep their access. Users with legitimate access can still misuse an assistant or extract data through it.
- Over-privileged agents can still act. An agent that can modify records will do so if it is manipulated or simply wrong.
- Imported models can be compromised. Weights and packages brought across the gap must be verified, or the air gap protects a poisoned model.
- Wrong answers are still wrong. Isolation does nothing for hallucinations.
So an isolated deployment needs the same application controls as any other: input detectors, least-privilege tools, approvals on consequential actions, output validation and full tracing.
What does it take to run LLMs in an isolated environment?
- Open-weight models whose licenses allow your use, sized for the hardware you have. Our overview of open-source LLMs covers the main families.
- GPU capacity for inference, and for fine-tuning if you customize models.
- A controlled transfer process for models, container images and packages: download outside, scan, verify checksums, move through an approved channel.
- Internal mirrors and registries for containers and packages, so nothing reaches outward during installs or updates.
- Identity and logging inside the boundary, integrated with your internal identity provider and monitoring.
- Offline evaluation, so every new model or prompt version is tested on your cases before promotion.
- People who can operate GPUs, Kubernetes and the platform without vendor access to the environment.
Which security controls does every LLM deployment need?
Whether in a managed cloud or an isolated network:
- Least privilege for users, agents and tools, with read-only access by default.
- Input screening for PII and prompt injection, including retrieved documents.
- Approvals before payments, record changes, outbound messages and other hard-to-undo actions.
- Output validation against schemas and policies before results reach other systems.
- Sandboxed code execution, separated from the platform and from other workloads.
- Secrets management, with credentials encrypted and never placed in prompts.
- Tracing and retention of every run, for investigation and audit.
- Testing on adversarial cases before each release, and incident response when something slips through.
How does Dynamiq support high-security deployments?
Dynamiq can be self-hosted on AWS, Azure, GCP, IBM Cloud, Red Hat OpenShift, any Kubernetes cluster or on-prem, with outbound calls going only to the model and tool providers you configure. Fully isolated and air-gapped environments are delivered with our engineers, who set up the platform and the models it uses to run entirely inside your boundary.
Inside any deployment, guardrails detect PII and prompt injection before a model reads the text, approvals with editable fields gate any tool step, agent code runs in isolated sandboxes, credentials are encrypted in a Vault-based secrets manager, and every run is traced with inputs, outputs, cost and latency. Dynamiq has SOC 2, HIPAA and GDPR in place, with SSO on the Enterprise plan. The Security and Trust Center lists the controls in detail.
FAQ
What is an air-gapped LLM?
It is a large language model deployed on infrastructure with no connection to outside networks, together with the data and applications that use it. Prompts, documents and outputs never leave the isolated environment.
Is an air-gapped deployment more secure than a private cloud?
It removes network paths for data to leave, which a private cloud with outbound access does not. It does not protect against application-level risks such as prompt injection or misuse by insiders, and it costs more to operate, so it is best reserved for workloads that truly require it.
Can you use GPT or Claude in an air-gapped environment?
Not through their public APIs, which need a network connection to the provider. Air-gapped deployments run open-weight models, such as Llama, Mistral, Qwen or Gemma, on local GPUs.
How do you update models in an air-gapped environment?
Through a controlled transfer: download and scan the model outside, verify its checksums, move it through an approved channel, then run your evaluation set inside the environment before promoting it.
Does Dynamiq offer air-gapped deployment?
Yes. Fully isolated and air-gapped environments are delivered with our engineers, who set up the platform and its models to run entirely inside your boundary. Standard self-hosted installs run in your cloud account or data center with outbound access limited to providers you configure.
