Approving AI tooling on classified networks

On these networks the blocker is the approval path

Teams on classified and segmented networks are not asking whether local AI can work. They have usually satisfied themselves that it can. They are asking how a new binary gets onto the network at all, and who signs for it.

That is a different question from the technical one, and it is the reason perfectly good tooling never arrives: the evaluation is straightforward, the paperwork is not, and nobody has written down what the paperwork needs.

The path, stage by stage

Names differ between organisations and regimes. The shape rarely does.

• 1. Justify the need. Usually the easiest stage and the one people over-prepare. The honest framing is that developers on closed networks have been working without assistance that everyone outside has, and the alternative to approving a local tool is people using an unapproved one on a phone.
• 2. Software assurance. What is in the artefact: what it is built from, what it bundles, what it links against, and whether the supply chain can be described. Expect this to be the longest stage.
• 3. Network behaviour review. What it talks to, when, and what happens when it cannot. This is where a tool that fails gracefully offline beats one that merely claims to.
• 4. Transfer approval. Getting the installer, the model files and any extensions across the boundary by whatever route your procedure allows, with hashes recorded on both sides.
• 5. Configuration baseline. What settings the approval is conditional on, written down so it can be checked later rather than remembered.
• 6. Ongoing. How updates happen, what triggers a re-review, and who notices when a version drifts.

The questions a review board asks about a binary

These are the ones specific to bringing software onto a closed network, as opposed to the generic vendor questions. Answers stated factually so they can be checked rather than believed.

Getting it across the boundary

Four artefacts, all ordinary files, all transferable by whatever route your procedure allows.

• The installer. Download on a connected machine, verify the signature, record the hash, transfer, verify the hash again on arrival.
• A model. Language models are GGUF files. Fetch one on the connected side and carry it across, or fetch it before Air-Gap Mode goes on. Model choice is a decision your side can make from the hardware you have rather than something the vendor controls.
• Extensions. VSIX files, installed from disk, exactly as any disconnected editor installation works.
• A licence, if you want Pro. Generate an offline activation file on the connected side and copy it over. The Free tier needs no activation at all, and it is the tier that already contains every control on this page.

A configuration baseline worth writing into the approval

Approvals are easier to keep than to get, and they are kept by being specific about the state that was approved.

• Air-Gap Mode on, with the status-bar indicator visible so the state is observable rather than assumed.
• An .onyxnoai committed to each repository, so exclusions are change-controlled and reviewable in a merge request rather than living in a personal settings file.
• Sanitizer patterns extended for identifier formats specific to your systems, on top of the built-in credential patterns.
• Bring-your-own-key left off, which is the default. With Air-Gap Mode on it is blocked regardless, so this is belt and braces.
• An activity-log export taken during acceptance testing, so the evidence format is on file before anybody needs it in anger.
• The engine binary hash recorded, from the SHA-256 sidecar, so drift is detectable at the next check.

Updates, and the trade you are accepting

With Air-Gap Mode on, update checks are blocked along with everything else. That is the correct behaviour for these environments and it has a consequence worth naming in the approval rather than discovering later: nothing will tell you a new version exists. Updating becomes a deliberate transfer on your schedule, which is usually what the environment wanted, but it means somebody has to own checking.

A workable arrangement is to nominate one person on the connected side to check releases at a fixed interval, transfer the installer through the same route as the original with hashes recorded, and treat a model swap as a data transfer rather than a software change. Because the configuration baseline lives in the repository and the user profile rather than in the bundle, an upgrade does not disturb the approved settings.

What you can put in front of the board

An approval turns on artefacts a reviewer can inspect without taking a vendor's word for anything.

Whatever the framework, a review comes down to the same two questions: what did the tool touch, and can you show it. Onyx Code answers both from the machine rather than from a vendor policy page.

• AI Activity Log. Every prompt, every file the AI read, every edit it proposed, with timestamps, recorded locally.
• Audit PDF export. The same record as a document you can hand to somebody who is never going to open your editor. This is usually the artefact that ends the conversation.
• .onyxnoai exclusion patterns. Gitignore-style paths no AI surface may read: not chat, not the index, not autocomplete, not agents. It lives in the repository, so it is reviewable in a pull request and it travels with the code.
• Prompt sanitizer. Every send and attachment is scanned locally for credentials, keys, tokens and certificates, with redaction offered before the prompt is built.
• Air-Gap Mode. A switch that blocks outbound traffic, enforced in three independent layers, with blocked attempts written to the log.
• No telemetry by default. Nothing to disable and nothing to negotiate.

All of the above are on the Free tier. Privacy and audit features are never behind the paywall, which also means a reviewer can evaluate every one of them before anybody spends money. The air-gapped development page covers the enforcement mechanisms in more depth, and the documentation gives the commands to verify them independently.

Questions

Can we run this on a network with no internet at all?

Yes. The engine and the editor are one artefact, models are files you transfer, and every AI feature runs on the workstation. The air-gapped development page covers the enforcement detail.

Do you have an accreditation or an authority to operate?

No, and any vendor claiming one for your environment should be treated with suspicion, because those are granted to a system in a context rather than to a product. What we can provide is a precise description of what the software does on the wire and on disk, and checks your own engineers can run.

Can we evaluate it before starting the paperwork?

That is the recommended order. The Free tier needs no account and contains every control described here, so an evaluation on a standalone machine can be done before anybody is asked to sign anything.

What if our procedure forbids bundled binaries?

Then the conversation is about the engine and the embedding model, which are the bundled components. Raise it early: it is a real constraint, and it is better established at stage two than discovered at stage four.

Who do we talk to about a written submission?

Write to us. We would rather answer a review board’s questionnaire directly, including the questions where the answer is that we do not have the thing being asked for.