A security review of any AI tool starts with one question. Where does our data go when the tool reads it?
For an IBM i shop the answer has to cover a specific asset. Not the customer table. The RPG source itself, sitting in libraries that have absorbed forty years of decisions about how the business actually works.
Air gapped AI is the deployment shape that answers that question with a single word. This post covers what the install requires on your side and what crosses the boundary. It also covers the evidence your security team can put in front of an auditor afterward. Our page on air-gapped AI deployment for enterprise covers the general case for data that cannot leave your network.
Source code is a different asset class from data
Most air gapped conversations start with records. Patient rows, claims, account balances, anything a regulation names directly. The controls follow from the regulation, and the security team already owns them.
Source code sits outside that frame, and it is usually the larger exposure. A leaked record exposes one customer. Leaked RPG source exposes the pricing logic, the credit rules, the discount thresholds nobody publishes and every workaround the business has quietly depended on since 1996. It also exposes the credentials sitting in plain text inside CL members that drive nightly transfers.
There is a contractual layer under the technical one. Many enterprise agreements forbid source code from leaving the customer network at all, and some carry that clause into the vendor's own subprocessor list. A tool that ships a program to a cloud endpoint for analysis breaks that clause on the first call, whether or not anything goes wrong.
Why AS400 and IBM i source is the harder case
Four properties make a 40-year AS/400 library more sensitive than a modern repository.
- Comments carry history. Members hold names, dates, ticket numbers and the occasional sentence about why a customer got an exception in 2004.
- Credentials sit in the clear. FTP scripts and remote command calls hold user IDs and passwords as literal text, because they had to run unattended and nobody revisited them.
- Test data lives in source-adjacent libraries. Copies of production records were current on the day somebody took them, and the copy never expired.
- Copy members widen the blast radius. A single program pulls in members from other libraries, so shipping one program can ship a dozen files nobody listed.
That last property breaks the usual mitigation. A team that plans to send one anonymized program to a cloud service discovers that the program will not resolve without three copy members it did not plan to send.
What "runs air gapped" has to mean before your security team signs
The phrase gets used loosely. Four conditions turn it into something a reviewer can verify.
- No egress from the host during operation. That covers telemetry, crash reporting, license activation and model weight downloads. A tool that phones home once a day for a license check is not air gapped.
- Model weights arrive out of band. Your team brings them in on media or through your own internal artifact repository, and the host completes its install with the network policy already closed.
- The reading layer runs beside the model. Ingestion and inference both sit inside the boundary, and so does every artifact either one produces. A design that parses locally and reasons remotely leaves the source on somebody else's disk.
- Updates arrive the same way the weights did. If a patch requires opening the firewall, the boundary was temporary.
Ask a vendor to state which of the four its product meets today. A product that meets three is still a real product, and your team should learn which one is missing before anybody signs a contract.
The install: what your team provides
An air gapped install is mostly ordinary infrastructure work. Five items cover it.
Compute comes first. The host needs enough memory to hold the model your team selected at the precision your team selected. That number follows from the model itself, and your team derives it before anybody quotes hardware.
Storage comes second. The ingestion pass produces artifacts: the interconnection graph, the generated program descriptions, the warning list. Those files stay on your side permanently, so size the volume for growth across repeated passes.
A read path to the source comes third. Your team supplies a copy of the AS400 source libraries, usually as a save file or a directory in the integrated file system. Nothing has to run on the production partition, and the ingestion host never needs a session into production.
Identity comes fourth. Somebody has to decide who opens the dashboard and sees the generated descriptions. Those descriptions summarize the business logic in plain English, which makes them easier to read than the source and worth the same protection.
Placement comes fifth. Put the host in a segment your network team already governs. An existing restricted subnet with a documented policy beats a new one built for this project, because the policy has already survived a review.
What crosses the boundary, and what does not
Your source libraries go in from the production side. The software and the model weights go in once at install, and nothing else crosses in either direction after that.
Nothing comes out. The graph and the descriptions stay on the host, and so do the warning list and the readiness status. Every artifact belongs to your organization and sits on storage your team controls.
The artifact list is worth reading closely, because it is what your team keeps. The graph names every program, file, copy member and display file the pass found, along with the edges between them. The descriptions explain each program in plain English, and a developer can check any sentence against the member it came from. The warning list names every copy member that failed to resolve and every dependency the pass could not find. A readiness status shows how confident the ingestion layer is in each program it read, which tells your team where to send a person.
The direction that surprises people is the second one. In a hosted arrangement, artifacts often live in the vendor's tenant and reach you through an export. An air gapped install inverts that. The vendor sees your results only if your team shows them, on a screen, in a room, at a time your team picks.
The evidence your security team can actually collect
A design claim is not evidence. These four artifacts are, and your team can gather all of them without the vendor's help.
- Egress logs for the host across a full ingestion run, showing zero outbound connections beyond the boundary. Run the pass on your largest library and capture the window end to end.
- A firewall export of the network policy itself, showing the deny rule and its change ticket.
- A host inventory captured on the day the install finished. It names the software version and the model version resident on the machine.
- A record of how the weights arrived, including the media, the checksum and the person who carried it.
Those four answer the auditor's questions in the order the auditor asks them: what we installed, where it came from, what it could reach, and what it actually did. Keep the pass date with them, because the answer expires the next time somebody updates the host.
One more piece of evidence costs nothing and carries weight. Run the ingestion with the outbound rule already logging denials. A clean run that produces zero denied attempts proves the software never tried, which is stronger than proving the firewall stopped it.
Where the model sits in the pipeline
The exposure of an AI tool depends on how much of the work the model does. AS/Forward puts a reading layer in front of the model, and that ordering changes the security profile.
The first stage involves no model at all. AS/Forward reads six RPG dialects through a proprietary ingestion layer and builds an interconnection graph across every program, file, copy member and display file in the library. That stage is structural work on your source, done locally, with no inference of any kind.
The second stage feeds the model two inputs: the source of one program and the plain-English description the ingestion layer generated from that same source. The model works on one program at a time with the structure already attached. Model backends include Claude, OpenAI, Gemini and local models running on customer hardware, and an air gapped install uses the local option for every call.
The practical effect is that a smaller local model does useful work, because the structure carries the context that a larger model would otherwise have to infer. Your team gets to fit the model to the hardware in the room. AS/Forward carries one US patent pending on the approach, and Golden Path Digital tested the ingestion layer against roughly 5,000 programs drawn from PUB400 and public code repositories.
What the air gap costs you
Two things get harder, and both are worth naming before your team commits.
Model updates stop being automatic. A hosted service upgrades its model behind the API and you inherit the improvement. An air gapped host runs the weights your team carried in, until your team carries in new ones. Put that on the maintenance calendar at install time.
Support gets slower in one specific way. A vendor debugging a hosted deployment reads the logs directly. A vendor debugging your air gapped host reads what your team exports and sanitizes. Agree on that export format during the install, while everybody is still in the room.
Neither cost changes the arithmetic for a regulated shop. A slower support loop is a scheduling problem. Source code on somebody else's infrastructure is a contract problem, and contract problems arrive with lawyers.
Questions to ask before the security review
Bring these to the vendor call, and write the answers down.
- During a full ingestion run, how many outbound connections does the product open, and to which hosts?
- How do model weights reach the host, and how do updated weights reach it later?
- Which stages run locally, and does any stage call a remote endpoint for inference?
- Where do the generated artifacts live, and who besides our team can read them?
- What does your support team need from us to debug a problem on an isolated host?
A vendor who answers all five from memory has done this before. A vendor who needs to check has not, and your team will be the first customer through that door.
Start with the pass, then the boundary
Most teams get this in the wrong order. They design the network segment first, then discover what the tool needs. Run it the other way. Scope the source libraries you want read, pick the deployment shape, then let your network team build the boundary around a known workload.
Our IBM i modernization assessment page walks through what the pass produces, and the AS/Forward page covers the product. Call Golden Path Digital at 501-232-7188 and tell us what your security team requires. We will size the install around the requirement.