Security for air-gapped AI, in one place
Where the data goes, what the vendor can see, how updates get in, and what happens if we disappear: answered together, and mapped to NIST SP 800-53, the NCSC Cyber Assessment Framework and MOD Secure by Design.
What is air-gapped AI security?
- Air-gapped AI security
- Air-gapped AI security is the set of controls that keep an offline AI system trustworthy once the network is gone: what can reach the models, how updates get in, where data is stored, and what the system could send out. An air gap removes remote network attack paths. On its own it does nothing about the files and devices people carry across it, or about who can physically reach the unit, so the other controls matter as much as the gap.
An air gap is the foundation these controls sit on. For why organisations require one in the first place, see air-gapped AI.
What the controls are for
Security reviews of AI systems ask the same questions: where prompts and documents go, what the vendor can see, how models are updated, and what depends on the vendor staying in business. The answers here are the same facts published across this site, gathered for that review.
None of it is a certification claim. If your process needs a specific standard, or your own questionnaire, send it with your enquiry; these controls are what it will be answered against.
Inputs and outputs stay on the unit, inside your boundary. There is no outbound telemetry and no vendor-side logging, so there is nothing for anyone outside to collect.
An air gap protects the network, not the file somebody carried across it. Untrusted media is checked before it reaches a model.
Every model or template that arrives is a change to a trusted system, so each one is verified before it is installed, and can be undone.
A delivered version is perpetual and runs without a licence server. Letting a support term lapse stops updates arriving; it disables nothing.
The controls, one by one
What is in place on every unit, and how each works.
- 01
No telemetry, no phone-home
No analytics, no online licence check, no update ping, no crash reports carrying context. This is not a setting to be switched off; the code that would do it is absent.
- 02
Pre-ingest scanning
A scanning pipeline sits in front of the analysis stack, so media from outside the boundary is checked before it reaches a model.
- 03
Encryption at rest
Model weights, the catalogue and anything you index are stored on the unit’s own NVMe storage, encrypted at rest with AES-256.
- 04
Verified, reversible updates
New models and platform versions arrive as signed, versioned bundles, moved by whatever transfer process your policy allows. Each is verified by checksum on the unit before installation, and the previous version is kept so a change can be rolled back.
- 05
Declared model provenance
Every capability declares its model, version and licence, and the deployed catalogue is restricted to Western-developed open-weight models, so your legal and security teams can see exactly what they are agreeing to.
- 06
One capability at a time
One AI capability runs at once, with its own configuration and secrets, so GPU memory, ports and power stay predictable and the operator can always see what is running.
Aligned with NIST, NCSC CAF and MOD Secure by Design
Each RAPTOR control, mapped to the frameworks a UK defence or government assessment works from. The Cyber Assessment Framework and Secure by Design assess the organisation and the programme that deploy a system, so this is the product evidence for that assessment rather than a certificate.
| RAPTOR control | NIST SP 800-53 Rev. 5 | NCSC CAF v4.0 | MOD Secure by Design |
|---|---|---|---|
| No network dependency; no data egress | NIST SP 800-53 Rev. 5: SC-7 Boundary Protection | NCSC CAF v4.0: B3 Data security; B5 Resilient networks and systems | MOD Secure by Design: 4 Define Security Controls |
| No telemetry or phone-home code; one capability at a time | NIST SP 800-53 Rev. 5: CM-7 Least Functionality | NCSC CAF v4.0: B4 System security | MOD Secure by Design: 4 Define Security Controls |
| Pre-ingest scanning of untrusted media | NIST SP 800-53 Rev. 5: SI-3 Malicious Code Protection | NCSC CAF v4.0: B4 System security | MOD Secure by Design: 4 Define Security Controls |
| Encryption at rest, AES-256 | NIST SP 800-53 Rev. 5: SC-28 Protection of Information at Rest; SC-28(1) Cryptographic Protection | NCSC CAF v4.0: B3 Data security | MOD Secure by Design: 4 Define Security Controls |
| Signed update bundles, verified by checksum before installation | NIST SP 800-53 Rev. 5: CM-14 Signed Components; SI-7(1) Integrity Checks; SI-7(15) Code Authentication | NCSC CAF v4.0: A4 Supply chain; B4 System security | MOD Secure by Design: 5 Engage and Manage the Supply Chain; 7 Enable Through Life Management |
| Previous version retained for rollback | NIST SP 800-53 Rev. 5: CM-2(3) Retention of Previous Configurations | NCSC CAF v4.0: D1 Response and recovery planning | MOD Secure by Design: 7 Enable Through Life Management |
| Declared model provenance; Western-developed open-weight models only | NIST SP 800-53 Rev. 5: SR-4 Provenance | NCSC CAF v4.0: A4 Supply chain | MOD Secure by Design: 5 Engage and Manage the Supply Chain |
| Perpetual licence; no licence server or remote switch-off | NIST SP 800-53 Rev. 5: n/a | NCSC CAF v4.0: B5 Resilient networks and systems | MOD Secure by Design: 7 Enable Through Life Management |
Secure by Design principles 1 (Understand and Define the Context), 2 (Plan the Security Activities), 3 (Implement Continuous Risk Management) and 6 (Assure, Verify and Test) belong to the deploying programme; RAPTOR supplies the product evidence they draw on. Sources: NIST SP 800-53 Rev. 5; NCSC Cyber Assessment Framework v4.0; MOD ISN 2023/09, Secure by Design Requirements.
A cloud AI service versus RAPTOR, in a security review
| Cloud AI service | RAPTOR | |
|---|---|---|
| Where prompts and documents are processed | Cloud AI service:Vendor infrastructure | RAPTOR:On the unit |
| Vendor access to your data | Cloud AI service:Governed by contract | RAPTOR:No route to it |
| Telemetry | Cloud AI service:Usually collected | RAPTOR:None |
| When the model changes | Cloud AI service:When the vendor decides | RAPTOR:When you install a bundle |
| Rolling back a change | Cloud AI service:Rarely possible | RAPTOR:Previous version kept |
| If the vendor stops trading | Cloud AI service:The service ends | RAPTOR:The unit keeps running |
Security: common questions
Keep reading
Why organisations remove the network in the first place, and what an AI stack needs in order to work without one.
Who owns the weights, the hardware and the decisions, and why a local cloud region does not settle it.
Published prices, and how a perpetual licence with a support term works when nothing can phone home.
Ready to deploy?
Configurations, timelines, evaluation units, or a licence for hardware you already own.