Most of the work that would benefit from Super Intelligence (SI) in a defense program sits on networks that cannot reach the internet. The manuals, the orders, the technical data, the reports. That is where the reading and drafting load is heaviest, and it is exactly where a commercial cloud service cannot go.
So the question program teams ask us is practical. What does it actually take to run SI inside the boundary? Here is how we answer it with SAIN Edge, what changes for the people responsible for the network, and what to have ready for the first conversation.
Start with the machine
The models have to run on hardware inside the boundary. There is no way around that on a disconnected network.
SAIN Edge is private SI in a box: SAIN OS on a machine you own, installed in your facility. It is new commercial hardware, sized to the team and the workload, and it belongs to the program once it is delivered. It comes in three sizes, Edge-1, Edge-2, and Edge-3, and we quote each customer on its users, its use case, and its environment.
Before a machine ships, we do the work that would otherwise land on your staff:
- The language models are installed and tested on your kind of documents
- SAIN OS is installed and ready
- Staff access is set up
- Outbound traffic is blocked
- A restore is tested
When it arrives, it comes with network setup and a documented IT handoff. The first 90 days of Launch Care are included.
Outbound blocked from day one
Each machine ships with outbound traffic blocked and is built to run in facilities with no internet connection at all. Files, prompts, and answers stay on the machine in your facility.
For a security officer, the default matters more than the option. A system that can reach out and has been configured not to is a different review from a system that arrives with the path already closed. SAIN Edge arrives closed.
SAIN keeps no copy of your data or your backups. The backups are yours, and the restore is tested before the machine leaves us.
No standing remote access
SAIN has no standing remote access to the machine. If support is needed, any support session is one your IT team opens.
That one rule removes a large category of questions from the security review. There is no vendor account sitting on the network, no persistent tunnel, and no access that exists when nobody is using it. Your team decides when a session happens and who is present for it.
Updates, including model refreshes, are delivered on a schedule your IT team approves. How an update crosses into the boundary follows the program's own transfer process, the same as any other software you bring in.
Accreditation stays with the program
We are careful about this one. SAIN Edge is a machine you place inside your own security boundary. Scoping, accreditation, and authorization stay with your program and your security officer. We supply documentation to support that process. We do not claim to accredit anything on your behalf.
I think this is the right split. The program knows its boundary, its data, and its mission. The people who sign the authorization should be the people who own the risk. Our job is to make the machine easy to describe, easy to inspect, and easy to keep closed.
What changes for the security officer
When SI runs inside the boundary on owned hardware, the security officer's questions get more familiar. They look like the questions asked about any other system on the network:
- Where does the data go? Nowhere outside the machine. Outbound traffic is blocked.
- Who can reach it from outside? Nobody by default. Support sessions are opened by your IT team.
- Who can use it inside? Staff sign-in and access rules that your team controls.
- How is it recovered? From backups you hold, with a restore already tested.
- How does it change over time? Through updates on a schedule your IT team approves.
There is one new question: what is the SI doing for the people who use it? That is where the rest of SAIN OS comes in. Anchor'd keeps a tamper-evident record of what was asked, what the SI produced, and who approved it. Guardian watches your agents and lets a named person stop them. A person always decides. Here is the kind of record a reviewer can walk through.
I wrote about why that record matters in Why AI in a program office needs a record.
And anything that enters the boundary, including the files and software that come in with the work, deserves a look before it lands. That is the subject of screening what enters the boundary.
What it does once it is running
The work is the first pass. Search technical manuals, orders, and procedures in plain language. Summarize reports and after-action reviews. Draft briefings, deliverable reports, and correspondence for review. Your staff review every answer, and final judgment stays with the people responsible for the work.
If your program already runs its own servers or a government cloud tenant, ask about SAIN OS as software on infrastructure you operate. We scope that option with you, and the same principles apply.
What to have ready for the first conversation
The first conversation is about your boundary. You will get more from it if you bring answers to these:
- The network. Which network the machine will sit on, and whether it has any path to the internet today.
- The work. Two or three recurring tasks you want the SI to carry, such as manual search, report summaries, or correspondence drafts.
- The people. Roughly how many staff will use it, and who approves its output.
- The transfer process. How software and updates cross into the boundary today, and who signs off.
- Your security officer's questions. Ask them in advance what they will need to see, and bring the list.
From there we size the machine, Edge-1, Edge-2, or Edge-3, and write a custom quote.
There is more on our SAIN Edge page and our defense page. If you are trying to bring SI onto a network that cannot reach the internet, we would like to hear what you are working with.