Most security tools assume a lookup. A version is matched against a database over the internet, a hash is checked against a service, a model is called over an API. Remove the network and most of the product's knowledge disappears with it.
Industrial networks are where that assumption breaks most often, and where breaking it matters most. The plants that most need testing are the ones least able to let a tool phone home.
The constraint, stated plainly
Whatever is not compiled into the binary does not exist for that customer. And whatever is wrong in the binary is acted on as if it were true, in front of live equipment, with no correction available until the next release reaches them.
That second half is the one people underestimate. On a connected product a bad fact is a bug you fix on Tuesday. On an air-gapped product it is a bad fact that ships, sits in a cabinet, and gets acted on for a year.
What it changes about research
It turns documentation harvesting into an engineering discipline rather than a content task. Every fact needs a source, and the source's host decides how much the fact is trusted: the vendor's own domain, an advisory, or anything else, and the third category ships labelled as what it is.
It also makes "not documented" a first-class result. Most industrial products have no unauthenticated version endpoint and no shipped default account. Recording that, with what was searched, is more valuable than an invented plausible answer, because the next pass does not repeat the work and nobody later closes the gap by guessing.
And it makes a negative fragile in a specific way worth knowing about. A summarising fetcher reporting "not present" is not evidence of absence. On one of our own passes a fetcher declared nine key sentences missing from a vendor workbook, and extracting the text layer locally found all nine verbatim. A failed fetch is not a failed fact, and on an air-gapped product that distinction decides what a customer will and will not be told.
What it changes about the model
The same constraint applies to the reasoning half. An air-gapped deployment means a local model, and a local model means the autonomy has to be gated on capability rather than on a vendor name, because the operator's model is whatever they can run on the hardware they have.
It also removes an entire class of exposure that connected tools carry quietly. In an autonomous run the model sees the operation's observed state: captured HTTP bodies, share contents, directory records, harvested credentials, files read off a target. If that model is remote, all of it leaves the building.
We treat a remote model as an egress boundary for exactly that reason. Secrets are tokenised before the payload leaves and rehydrated locally on the way back, so tools run with real values and the remote model never sees one. A local model sees them verbatim, because on an on-prem engine the leaked credential is the engagement evidence and masking it there would be theatre.
Worth noting where that hole was found: the redactor existed and was wired into the advisory and analysis paths, and not into the agent client, which is the one component that sees the most. Being air-gapped by default is what kept that from being a live exposure for most deployments, and it is not a reason to leave it unfixed.
What it changes about claims
An air-gapped tool cannot quietly improve after the sale. There is no service updating a model behind the scenes, no catalogue silently getting better. What is in the box is what the customer has.
That makes stated coverage a contract rather than a marketing position. It is why we publish the ceilings alongside the counts: how many advisory bands can actually gate a finding, how many products are version-readable end to end, which protocols we speak and which we have catalogued but do not yet speak. A customer running us on an isolated network cannot verify a vague claim by watching the product improve. They can only read what we said and check it.
The part that is simply nicer to sell
Everything above is a constraint. One consequence of it is not.
When the answer to "what leaves our network" is nothing, the conversation with the plant's own security team is short. There is no data processing agreement to negotiate for topology and credentials, no exception to file for a cloud dependency, no question about where the findings are stored. The engine, the model, the exploit and the loot are all inside the perimeter, and the network diagram of the deployment has no arrow pointing out.
Frequently asked questions
What does running air-gapped actually require of a security tool?
It means whatever is not compiled into the binary does not exist for that customer, since there is no network left to look anything up over. It also means a wrong fact ships baked into the product and gets acted on against live equipment for up to a year, until the next release corrects it.
Why does Nexich treat 'not documented' as a valid research result?
Because most industrial products have no unauthenticated version endpoint and no shipped default account, and recording that fact, along with what was searched, stops the next research pass repeating the same work and stops anyone later closing the gap by guessing. An invented, plausible sounding answer is worse than an honest, documented negative.
Can a document fetcher be trusted when it says a fact is not present?
Not automatically. On one pass a summarising fetcher declared nine key sentences missing from a vendor workbook, yet extracting the text layer locally found all nine verbatim. A failed fetch is not the same thing as a failed fact, and on an air-gapped product that distinction decides what a customer will and will not be told.
Does a remote AI model see customer credentials during a Nexich run?
It should not. Nexich treats a remote model as an egress boundary: secrets captured during an operation are tokenised before the payload leaves and rehydrated locally on the way back, so tools run with real values while the remote model never sees one. A local model sees them verbatim, because it stays on-prem.
Where did Nexich find a gap in its own secrets-masking design?
The redactor was wired into the advisory and analysis paths but not into the agent client, the one component that sees the most captured data during a run. Running air-gapped by default kept this from being a live exposure for most deployments, though the post treats that as no reason to leave the gap unfixed.
Why does being air-gapped make Nexich's coverage numbers more trustworthy?
Because an air-gapped tool cannot quietly improve after the sale, there is no service updating a model or catalogue behind the scenes. What is in the box is what the customer has, so published ceilings, such as how many advisory bands can gate a finding, become a contract the customer can check rather than a marketing position.