There is a question I ask early in most conversations with defence and infrastructure teams, and the answer is almost always the same. What happens to your security tooling when the network cannot reach the internet. The answer is that most of it stops being tooling and starts being a licence you are still paying for.
This is not a criticism of the products. It is an architectural consequence that nobody set out to create. The last three years of security tooling have been built on the assumption that a model call is a network call, and that the network is always there. On a corporate estate that assumption holds. On a classified network, a deployed system or an operational technology segment that was deliberately severed a decade ago, it does not hold at all.
The assumption is load bearing
It is worth being precise about what breaks, because vendors are often vague here. A product that calls a frontier model over an API does not degrade gracefully when connectivity goes. It does not fall back to a smaller local model or a rule set. It fails, and it fails at the exact moment the environment is under the most scrutiny.
The workarounds are worse than the problem. A one way diode that ships telemetry out for analysis moves your most sensitive data across the boundary you built the boundary to protect. A periodic sync means your reasoning layer is always operating on a stale picture. Neither is acceptable to an accreditor, which is why so many of these networks are still defended with people and scripts.
What solving it actually requires
Running an agentic system with no external calls is not a matter of swapping in a smaller model and hoping. Three things have to be true at once.
The model has to be small enough to run on what is already there, and good enough at the narrow task of security reasoning to be worth running. General capability is not the goal. Reliable triage, correlation and planning on your estate is.
The knowledge has to be local and it has to compound. A disconnected system cannot borrow context from a vendor cloud, so it has to build its own picture of the estate and keep it. This turns out to be an advantage rather than a constraint.
Nothing can phone home. Not telemetry, not licence validation, not crash reporting. Anything that reaches out is a finding waiting to be raised during accreditation.
The third point quietly disqualifies most products. It is easy to describe a deployment as on premises while retaining a licence check that requires egress. Ask the question directly and specifically.
The advantage nobody expects
Building for the disconnected case forces a discipline that improves the connected one. If the reasoning layer has to work with a local model and locally accumulated knowledge, the knowledge layer has to be genuinely good, because it cannot lean on scale to paper over gaps in context. The result is a system that gets better at your specific environment rather than better in general.
It also produces a cleaner answer to the question every regulated buyer is now asking, which is where the data goes. If the honest answer is nowhere, the conversation about model providers, jurisdictions and training data becomes a great deal shorter.
What to ask a vendor
Four questions, in order. Where does the model run, and can it run inside my boundary. What leaves the network during normal operation, including licensing and telemetry. What happens to the product when connectivity is removed entirely. And can you show me a deployment where that is already true.
The last one matters most. Disconnected operation is easy to claim on a slide and difficult to do. Ask for the deployment.