Declared routes and default-deny egress
Substrate has no default path to the public internet. Every connection out of the appliance is a route someone declared, with a policy attached, and anything undeclared is refused.
· 4 min read
IN SHORT
Substrate starts from default-deny egress. The appliance has no built-in path to the public internet and no outbound connection it makes on its own. The only connectivity is a set of declared routes in Local Bridge, each naming a specific on-premise system and the policy that governs the traffic. Anything that is not declared is refused, and the refusal is recorded.
Most software assumes it can reach the internet and asks forgiveness later. A library checks for a new version. A telemetry client posts a heartbeat. A model runtime pulls weights from a registry. Each of these is a small decision made by someone who never saw the building the software ended up in.
Substrate is built the other way around. The appliance has no default route out. The platform makes no outbound connection on its own behalf, and no service inside it is permitted to assume one exists. If the site wants the appliance to talk to a system, the site says so, by name, in Local Bridge.
What a declared route is
A declared route is a statement by the site that the appliance may exchange traffic with one specific on-premise system. The route names the system and the direction of traffic. It carries a policy that says what kind of exchange is allowed over it, and the whole thing is written into the platform's configuration where it can be read back later.
The point of the declaration is that it is legible. An operator can list every route on the appliance and know, without inspecting packets, exactly which systems it can reach. A new engineer inheriting the site can read the same list. An auditor can read it too. There is no second list of implicit connections hiding behind the explicit one.
Routes point at systems the site already runs and already secures: the warehouse system, a historian, a document store, a message bus on the plant segment. Substrate does not add a new class of system to protect. It joins the ones that are already inside the fence, and only the ones it is told to join.
What default-deny means in practice
Default-deny is a posture, not a filter bolted on after the fact. When something inside the appliance attempts a connection that does not match a declared route, the attempt fails. It is not queued, it is not retried on a backoff schedule, and it is not allowed through with a warning. It is refused.
The refusal is also recorded. Evaluation keeps a trace of AI operations, and Local Bridge contributes to the same body of records when it turns something away. That matters more than it sounds. A connection that fails silently tells you nothing. A connection that fails and leaves a line in the record tells you that some component wanted a path it was never given, which is exactly the kind of thing a site wants to know about.
For the people who run the floor, default-deny removes a category of question. Nobody has to wonder whether the serving platform is quietly reporting usage somewhere, because it has no path on which to do so. The question of what leaves the building has a short answer, and the answer is enforced by the absence of a route rather than by a promise.
The same mechanism on every posture
Sites run Substrate in one of two postures. An air-gapped site has no path out at all. A connected site reaches only the systems it already secures and has declared. These are not two different products and they do not use two different mechanisms. The air-gapped site has declared no routes; the connected site has declared some.
That uniformity is useful for estates with more than one kind of building. A company might run one plant fully isolated and another with a route to a shared document store. Both run the same Substrate. Both can be described with the same sentence: the appliance reaches what the site declared and nothing else. The difference between them is a configuration the site owns, not a product decision Element 31 made for them.
It also means posture can change without a migration. A site that begins air-gapped and later decides to connect a single on-premise system adds a route. A site that decides to withdraw a connection removes one. The platform underneath does not change.
Why a connection is a decision
The sentence Element 31 uses for this is that a connection is a decision, not a default. The decision is made by the site, in writing, in a place that can be read back. It can be reviewed. It can be reversed. It is never made for the site by a component that happened to want a path.
For a serving platform that handles camera feeds, floor documents, and the models adapted on them, this is the right default. The data on the appliance is the building's data. The routes out of the appliance should be the building's choice. Default-deny egress with declared routes is how Substrate keeps that choice where it belongs. The security overview at /security describes how it fits with the rest of the integrity model.
Questions this raises
- Who declares a route in Local Bridge?
- The site does, through the platform's administrative surface. Declaring a route is a deliberate configuration act by someone with authority on that site, not something a model, an agent, or an application can do for itself at runtime.
- Can an application on the facility network bypass Local Bridge?
- Applications talk to Substrate through the one API on the facility network, and the appliance itself only reaches other systems through declared routes. An application may have its own network paths, but nothing it asks Substrate to do will cause the appliance to open an undeclared connection.
- Does default-deny mean the appliance cannot be updated?
- No. Updates are signed bundles that the customer downloads from the portal on a connected site or carries in on media on an air-gapped site. The appliance never fetches them itself, so no outbound route is needed for updating.
KEEP READING