I'm developing an air-gapped product that runs entirely in Docker, including trained AI models and proprietary backend logic. The customers are laboratories that need full root access to the host machines where the software is deployed, and they must be able to operate without internet connectivity.
The concern is that an administrator could enter the containers, copy image layers, inspect the filesystem, trace the application, or dump process memory to recover the models and business logic. I understand that someone who controls the host cannot be completely prevented from accessing software that runs on it, but I would like to make extraction sufficiently expensive and inconvenient to deter casual or opportunistic copying.
Ideas under consideration include encrypting container contents behind a master key, deleting images after failed unlock attempts, compiling the Python components into native binaries, obfuscating the model files, and using offline licensing. What practical measures can raise the difficulty of extracting code and model weights in an on-premises, air-gapped deployment?
5 Answers
Offline licensing can enforce entitlement and expiration, but it cannot make the protected implementation safe from the administrator of the machine running it. A hardware security key may raise the cost of casual copying, and encrypted model files reduce the value of simply copying the disk, but a determined operator can usually observe the application after it unlocks the files or patch the license checks. Frequent updates may reduce the value of an old copy, but they do not prevent extraction from a deployed version.
First challenge the requirement for unrestricted root access. If the software can run with a dedicated service account and a small, documented set of privileged operations, use a hardened appliance or tightly controlled administrative workflow instead. A virtual machine can improve isolation and operational control, but it does not protect the guest from an administrator who controls the hypervisor. Hardware-backed confidential-computing features can help only when the hardware, firmware, and attestation chain are under trusted control.
Use legal and commercial controls alongside technical ones: licensing terms, audit rights, deployment-specific builds, and customer-specific watermarks. Watermarking model weights is especially useful because copied weights are often reused unchanged, allowing a leaked model to be traced back to a deployment. This will not stop theft, but it can make unauthorized redistribution risky and provide evidence if a copy appears elsewhere.
The strongest practical design is to avoid handing over a general-purpose host deployment. Provide a dedicated appliance or leased server with a locked-down operating system, secure boot, TPM-backed disk encryption, restricted administration, and a narrow local API. The customer can use the product over their isolated network without receiving the image or having administrative access to the machine that contains the valuable assets. This changes the problem from protecting software on their computer to protecting a device you control.
If the customer controls the host as root, there is no reliable software-only boundary. They can inspect the container, modify the runtime, attach a debugger, replace binaries, or capture secrets and decrypted model data from memory while the application is running. Encryption protects files at rest, but it cannot protect content that the customer is authorized to make the program use. Obfuscation and native compilation may slow analysis, but they are speed bumps rather than security controls.
Rotating keys or decrypting only at startup does not fundamentally change this threat model. A root user can capture the plaintext model or the decryption key from the process while the application is operating, so those measures are mainly useful against offline disk theft rather than a hostile system administrator.