Skip to main content

Deploying AI Security in Air-Gapped Environments

In highly regulated sectors such as defense, finance, and critical infrastructure, AI development often occurs within strictly isolated networks. These "Air-Gapped" environments physically or logically prevent outbound internet connections to mitigate the risk of data exfiltration and external command-and-control (C2) communication.

Deploying traditional AI security scanners in these environments presents a paradoxical challenge: modern Machine Learning models (like DeBERTa or GLiNER) and their tokenizers rely heavily on dynamic downloads from external registries (e.g., Hugging Face Hub) at runtime. If an internet connection is blocked, the security scanner crashes, leaving the MLOps pipeline unprotected.

Veritensor is fundamentally architected to solve this problem. This guide details how to deploy the Veritensor Control Plane and Heavy Analysis Engines in a 100% offline, Air-Gapped environment without sacrificing detection capabilities.

The Architectural Challenge of ML in Docker​

A naive approach to containerizing ML applications involves running pipeline("text-classification", model="...") inside the application code. Under normal circumstances, the transformers library attempts to reach huggingface.co to download the model weights (.bin or .safetensors), configuration files, and tokenizer vocabularies, caching them in ~/.cache/huggingface.

If this container is deployed in an Air-Gapped VPC, the request times out, resulting in a fatal OSError: Can't load tokenizer or Model not found exception during the first scan task.

The Veritensor Solution: Pre-Baking Models​

Veritensor eliminates runtime dependency on external networks by "pre-baking" all required Machine Learning models directly into the Docker image layers during the build phase.

1. The download_models.py Script​

Veritensor includes a dedicated script (scripts/download_models.py) designed specifically for CI/CD build environments. When executed, it forces the transformers and gliner libraries to download the required models and save them to a deterministic directory defined by the HF_HOME environment variable.

2. The Worker Dockerfile​

To ensure the models are permanently embedded in the image, the Dockerfile.worker (and Dockerfile.worker.gpu) executes this script before the final application code is copied.

# --- ENTERPRISE ML CACHING STRATEGY ---

# Set the directory inside the image where models will be stored
ENV HF_HOME=/app/models_cache

# Copy ONLY the download script first (optimizes Docker build cache)
COPY scripts/download_models.py /app/scripts/

# Download models during build (They will permanently remain in this Docker layer)
RUN python /app/scripts/download_models.py

# Enforce offline mode! 
# Prevents HuggingFace from attempting to connect to the internet at runtime.
ENV HF_HUB_OFFLINE=1

# --- END CACHING STRATEGY ---

By setting HF_HUB_OFFLINE=1 directly in the Dockerfile (and enforcing it in the docker-compose.yml), the transformers library is mathematically guaranteed to never initiate an outbound HTTP request. It will exclusively load the models from the /app/models_cache directory.

Deployment Workflow for Air-Gapped Networks​

To deploy Veritensor into an Air-Gapped environment, administrators must utilize an intermediate "DMZ" (Demilitarized Zone) or a bastion host with temporary internet access to build the images, before transferring them to the isolated network.

Step 1: Build the Images in a Connected Environment​

On a machine with internet access, clone the Veritensor Enterprise repository and build the images:

docker-compose build

Note: During the build of the worker image, you will observe the downloading of the DeBERTa and GLiNER models. This process may take several minutes depending on your bandwidth.

Step 2: Export (Save) the Docker Images​

Once built, export the images into compressed tarball archives:

docker save ghcr.io/your_org/veritensor-api:v1.6.4 | gzip > veritensor-api.tar.gz
docker save ghcr.io/your_org/veritensor-worker-cpu:v1.6.4 | gzip > veritensor-worker-cpu.tar.gz
# Repeat for postgres, redis, and minio images if they are not already in your internal registry

Step 3: Transfer to the Air-Gapped Network​

Securely transfer the .tar.gz files and the docker-compose.yml file across the air-gap boundary (e.g., via secure USB, data diode, or internal artifact registry).

Step 4: Load and Run​

On the isolated server, load the images into the local Docker daemon:

docker load < veritensor-api.tar.gz
docker load < veritensor-worker-cpu.tar.gz

Finally, start the infrastructure:

docker-compose up -d

Caveats and Limitations in Offline Mode​

While Veritensor's ML engines (DeBERTa, GLiNER), OCR (EasyOCR), and binary scanning (YARA) operate at 100% capacity offline, administrators must be aware of one specific limitation regarding Supply Chain Security.

OSV.dev CVE Checking: The Veritensor CLI relies on the Google OSV.dev Batch API to dynamically check requirements.txt and lock files for known vulnerabilities (CVEs). In a strictly air-gapped environment, the CLI cannot reach https://api.osv.dev. The CLI is designed to fail open gracefully; it will log a debug message indicating the API is unreachable and proceed with local Typosquatting checks (which use a hardcoded distance algorithm) without blocking the build.