> ## Content Index > Fetch the complete content index at: https://www.theack.net/llms.txt > Use this file to discover other available public pages before exploring further. # Mind the Airgap? Defence has its own challenges - URL: https://www.theack.net/mind-the-airgap-defence-has-its-own-challenges/ - Published: 2026-09-22T11:48:44.000Z - Updated: 2026-09-22T12:51:48.000Z - Description: "Offline, that safety net is gone and 'is it hallucinating?' becomes an operational question..." - Author: Edward Targett - Tags: Software, Elastic, AI When OpenAI research scientist Noam Brown sat down with a podcaster earlier this month and suggested that AI might, in future, bypass airgaps by detecting the temperature change in neighbouring computers’ CPUs, his intention was, he later said, “to illustrate how hard it is to make absolute guarantees about isolation.” It sparked a predictably furious and frustrated reaction from many cybersecurity professionals – particularly Brown’s suggestion that “one lesson from the HF \[Hugging Face\] incident is that we put too much trust in sandbox isolation.” (That is, most suggested; nonsense: OpenAI had simply not built nor monitored its sandbox well.) But it did put industry attention back on airgaps – and the adjacent challenges of running modern software (including AI) in constrained environments. Few sectors have more challenges on this front than the defence sector. High security requirements, ageing hosting hardware getting bashed about in a tank, limited connectivity, fat-fingered field users with their hands otherwise alarmingly full; none of these add up to easy software deployment. ### A Q&A with Elastic defence expert James Garside The Ack fired some eclectic questions at the talented James Garside about building software for defence users; airgaps, and running AI at the edge. (Garside is a field architect lead for software company Elastic's public sector team, working across the Five Eyes countries. He led its technical contribution to the MoD's [Defence Cyber Marvel](https://www.army.mod.uk/learn-and-explore/army-of-the-future/modernisation/army-innovation/defence-cyber-marvel/?ref=theack.net) competition and delivered a multi-tenanted security platform, AI services, and custom agents that supported 2,500 personnel from 29 nations. **Q: What are the biggest issues when it comes to deploying software on tactical edge hardware (ruggedised servers, field units, etc) with tight Size, Weight, and Power (SWaP) constraints, legacy OSs, or non-x86 architectures?** The first issue is that modern software is built on assumptions the field breaks. It expects container registries, licence servers, external APIs and a reliable clock. A ruggedised unit in the back of a vehicle offers none of those, and has a fraction of the compute, memory and power the software was developed against. Add non-x86 architectures – ARM is increasingly the norm in low-power units – and legacy operating systems, and commercial software can either fail outright or run as a cut-down version of itself. The second failure is the one to watch in procurement. If a capability only exists in the vendor’s cloud, it does not exist for the operator in the field. Software taken to the tactical edge needs feature parity with its cloud form, within the limits of the hardware in front of it. ### Follow [The Ack on LinkedIn ](https://www.linkedin.com/company/ackdefense?ref=theack.net) It’s also worth being precise about what edge means. Tactical deployments sit on a spectrum: fully connected but resource-constrained, through Denied, Degraded, Intermittent and Limited (DDIL) links, to fully isolated. A deployment can move along that spectrum several times in a day, so the engineering challenge is designing for the whole spectrum, not a single operating state. The data question follows. Store and analyse locally so the system remains useful when disconnected; when a link appears, synchronise and federate so commanders can query across the wider estate without hauling everything to one place first. A distributed data mesh, where data stays where it was created and the search travels to it, handles both states. What does not work is software that falls over when the link disappears again. **Running LLMs/SLMs in airgapped environments: What's working, what's not? Can you share some lessons learned from deployments?** The biggest lesson is that air-gapped AI works when the whole stack is designed for isolation from the start. Lifting a cloud architecture and moving it offline leaves you running software that assumes an internet it no longer has. Running LLMs and SLMs locally is now genuinely viable, and the capability gap to frontier cloud models is narrowing. For most defence tasks, raw model power matters less than people expect. The limiting factor is often context. A smaller model given the right local data – including doctrine, reporting, logs and prior incidents – can produce more useful output than a larger model guessing. The engineering effort therefore belongs in retrieval and context engineering inside the boundary. The harder lesson arrives once the model is running: you are now the provider. In a cloud deployment the vendor carries part of the quality burden. Offline, that safety net is gone and “is it hallucinating?” becomes an operational question your own telemetry has to answer. This is where observability becomes critical. It has to extend beyond model health into model behaviour. The prompt, retrieved context and output are already inside the boundary, so they can be scored there. Groundedness scoring compares what the model said against what it was given; claims that appear in the answer but nowhere in the retrieval are a measurable signal of hallucination. A second local model can act as an “automated judge”, scoring groundedness and relevance without sensitive data leaving the perimeter. Quality can then be managed like availability: with objectives, thresholds and alerts. If groundedness degrades after a model update or a quantisation change, the trend line moves before the operators notice. Underneath all of that sits a non-negotiable: log every model invocation, whatever product wraps it. The joint Five Eyes advisory on agentic AI calls for agent actions, including triggering prompts and tool calls, to be captured and made available to security operations. You cannot report or investigate an AI incident you cannot see. We saw this in practice on[ Defence Cyber Marvel 2026](https://www.elastic.co/security-labs/blog/elastic-defence-cyber-marvel?ref=theack.net), where Elastic ran the on-range AI service for more than 2,500 participants from 29 nations. Every invocation was guardrailed, logged and attributable, giving the exercise security operations centre complete visibility into what was asked and by whom. In a fully isolated environment, that governance has to live inside the boundary: the model, guardrails, judge and telemetry cannot depend on an external service. And keep the history. A complete record of real interactions is the most honest test set you will own. When a model or prompt changes, replay historical prompts and rescore the outputs before deployment. Point-in-time accreditation cannot do that; retained telemetry can. **How do you handle transitive dependencies without constant access to online registries/handle manually tracking and bundling complex, deeply nested dependency trees?** Stop treating the internet as part of your build process. Everything you depend on gets pulled, verified and bundled while you are still connected, then moved across the boundary as a single known-good package. In practice that means an internal mirror or artefact repository as the source of truth, pinned versions and lockfiles so builds are reproducible, and a software bill of materials so you know what you are carrying. Where possible, ship the whole environment – container images or self-contained builds – rather than resolving packages individually on the far side. In the most sensitive cross-domain work the bar is higher still: develop low-side, build high-side. Rather than pulling built packages across the boundary, you pull the source code across and build the final artefact inside the trusted environment. This is an artifact provenance measure more than anything else. A binary built in an environment you control is a binary you can account for; one built somewhere else is a statement of trust in someone else's pipeline. Every extra library has to be tracked, scanned, signed and physically carried across the gap, creating a strong incentive to keep the stack simple. Updates stop being a continuous stream and become scheduled, tested releases. The same discipline applies above the package level. On DCM26, the exercise estate was managed as code with Terraform. A deployment you can reproduce from code is one you can carry across a boundary and stand up identically on the far side. Hand-built environments do not survive the trip. **Other "teachable moments" - type lessons from running software in air-gapped and edge environments with intermittent connectivity welcomed.** Remember who operates it. The person running the system in the field is unlikely to be the person who built it. Simple architectures, clear failure messages and documented manual recovery steps are worth more than clever automation a generalist cannot fix at 3am. Treat disconnection as the normal state, not an error condition. Software that assumes connectivity will find a way to remind you: online licence checks that fail closed, clocks drifting because there is no NTP, telemetry silently backing up until it fills the disk. Your test environment needs to look like the deployed one, because these problems only surface when the network genuinely is not there. Plan for degraded rather than binary behaviour. An intermittent link is often harder than no link at all. Transfers need to be resumable and tolerant of interruption, and the system has to keep working while synchronisation is half-finished. And invest in the people. Enablement is as decisive as the deployment. Handing operators capable tooling they have never been taught helps nobody. In a disconnected environment, there is no support desk to fall back on. The training has to travel with the system. ## Sign up for The Ack Interviews, Insight, Intelligence across defense technology (EW, C-UAS, and beyond) and procurement policy Subscribe Email sent! Check your inbox to complete your signup. No spam. Unsubscribe anytime.