Sovereign by Default, Federated by Opt-In

A commercial AI platform has one central brain — one console, one login, one shared control plane across every deployment. A tactical AI deployment has none — just a ruggedized box somewhere in the field, running a model, disconnected.

A government mission AI has to be both, at the same time, and the two halves have to cooperate without merging.

That’s the problem. Most platforms don’t solve it. They pick one or the other.

The thing you’re trying to avoid

Imagine a platform where an installation inside the continental US and an installation in the Indo-Pacific end up sharing a control plane — because one service, somewhere, needed to read from both. That setup cannot pass a federal security review. It creates a path between two different sensitivity levels, and that path is exactly what a cross-domain security review is designed to forbid.

Hyperscalers and big commercial platforms build this way on purpose. Their business depends on a single shared plane — one console, one billing surface, one place you manage everything. You can’t split it off without breaking the product.

That’s fine for a regular company. It’s disqualifying for a government mission.

The thing you’re trying to enable

A coalition query: a partner in one country asks a question that has to be answered by systems in another country. The query hops between sites, runs across both, and produces an audit record in each place. No data crosses a boundary it shouldn’t. No shared credentials. No shared brain.

That is the useful behavior. You want it possible. You want it off by default.

How Writ handles it

Writ treats each site (we call them enclaves) as its own self-contained installation — its own cluster, its own identity system, its own secrets, its own security accreditation. If one enclave dies, every other enclave keeps running. If one enclave is compromised, the damage stops at that enclave. The US installation’s security approval does not automatically transfer to the Indo-Pacific installation. They’re separate things.

That’s the default. A platform that works that way is sovereign — each site stands on its own.

Federation — making two enclaves cooperate — is a deliberate, opt-in connection on top. It’s built from four layers, each of which can be turned off independently:

1. Identity. Every workload, at every enclave, gets a signed ID that says which enclave it came from. When a request crosses between enclaves, that enclave-of-origin comes along with it, and the receiving enclave’s policy decides whether to allow the call. Partner identity systems (federal smart cards, an allied government’s login service) can be brought in without merging anyone’s user database.

2. Network. A direct, encrypted link between enclaves, using post-quantum encryption from the start. The path exists; whether a specific call gets to use it is a policy decision, not a network one.

3. Data. Analytics and search queries can span enclaves without moving the underlying data. A policy engine runs at every query and blocks access that the caller isn’t cleared for — even if the network path is open, the data stays protected.

4. Models. A query can hop from one enclave to another and come back with an answer. Separately, model training can share statistical updates across enclaves without shipping the training data itself.

Each layer produces its own audit trail. Each layer has an off switch. None of them assume the others are on.

The trust root

The piece that’s easy to get wrong is the top.

You need a single authority that signs all the enclave identities — so that enclave A can verify enclave B’s identity without calling anybody. But that single authority is a single point of failure if it’s online and reachable.

So we keep it offline. On a hardened piece of hardware, disconnected from the network, signed using a quantum-resistant algorithm that doesn’t expire when computers get faster. That root signs regional authorities (US, Indo-Pacific, Africa Command, and so on) on a fixed rotation. Those regional authorities sign individual enclaves.

To forge an enclave identity, an attacker needs to compromise a regional authority. To forge a regional authority, they need physical access to the offline root and a multi-person signing ceremony. If they can do both, the problem is larger than any software platform.

The rule that makes accreditation tractable

The federal accreditation process does not like systems where information can accidentally flow between two different sensitivity levels. Not even by accident. Not even briefly.

So the cast-iron rule: information at one sensitivity level never flows to another sensitivity level without going through a formally approved crossing. The federation layer never creates a shortcut for this. Every cross-level channel is explicit, logged, and off by default.

This is the thing that makes a new enclave a small review rather than a full re-accreditation. The review asks “how is this enclave different from the signed baseline?” — and the answer is short because the baseline forbids the shortcut that would otherwise explode the scope.

If you’re evaluating a federated AI claim

Three questions, in order:

1. “Show me the trust root.” If the vendor can’t describe where it lives, how it signs, and what it signs — they don’t have one. They have a marketing slide.

2. “Show me the cross-level guarantee.” If the answer is “we have firewall rules,” they’ve built a firewall, not a trust boundary. Firewalls can be misconfigured. Identity-level boundaries can’t.

3. “Show me two deployments with two separate security approvals that share no central console.” If every site in their demo reports to the same dashboard, it is one system, not a federation. Its security approval inherits the whole system, not the site — and that’s the opposite of what sovereignty means.

Writ was built this way because real missions need federation. It is off by default because real security reviews can’t afford for it to be anywhere else.