API Endpoints on the Edge: Interfacing with a Sealed Element 31 Appliance

An air-gapped appliance is defined by what it refuses to do: no outbound call to a model provider, no telemetry leaving the building, no dependency on a network path the buyer doesn't fully own. But refusal to talk to the outside world is not the same as refusal to talk at all. Inside the boundary, the appliance has to be a working participant in an engineering organization's existing toolchain: an IDE plugin issuing completion requests, a CI pipeline calling out during a build, a dashboard polling for status, a retrieval service querying an index. That traffic has to arrive somewhere, get authenticated, get routed to the right internal service, and return an answer, without the appliance ever needing, or being able, to reach past its own sealed boundary to do it. That's a narrower design problem than "build an API," and it's easy to underestimate, because the interface can look identical to a cloud API from the caller's side. The difference is entirely in what sits behind the endpoint.

The interface has to feel unremarkable

The strongest adoption argument for a sealed appliance is also the trap it can fall into. If calling it requires a bespoke protocol, a proprietary SDK, or a different mental model than what a team already uses to call a cloud model, the appliance becomes friction rather than infrastructure. Engineers do not want to relearn how they issue a completion request just because the model behind it now lives in a rack down the hall instead of somewhere on the internet.

The practical answer is to keep the request and response shape close to what tooling already expects: structured requests, streaming responses, the kind of interface an IDE plugin or an existing internal client can point at with minimal rewiring. The appliance's job is to be a drop-in destination for calls that already exist in a team's workflow, not to demand the workflow be redesigned around it. Where it genuinely diverges from a cloud endpoint is not in shape but in scope: authentication, routing, and reachability are all designed around a boundary a cloud API was never built to have.

Every endpoint is a boundary decision

A cloud-hosted API has one hard boundary question to answer: who's allowed to call it. A sealed appliance's API surface has to answer that question and a second one just as important: what is this endpoint allowed to reach, and where does that reach stop. Every endpoint the appliance exposes is, in effect, a small decision about the shape of the sealed boundary itself. Does this call touch the model, the retrieval index, the audit log, a configuration setting, and is any of that, even indirectly, a path that could be extended outward.

That second question is why appliance API design can't simply borrow a cloud service's endpoint taxonomy wholesale. A cloud provider's API might legitimately proxy a request onward to a third-party integration or a logging pipeline that leaves its own infrastructure. None of that is available by default inside a sealed appliance, and the API layer has to be built with that unavailability as a first-class constraint, not something enforced only by network policy elsewhere in the stack. An endpoint that looks contained on paper but quietly depends on DNS resolution or an update check reaching outward isn't actually contained. It's an air gap with an asterisk.

Authentication without a cloud identity provider to lean on

Cloud APIs typically outsource the hard parts of authentication to an identity provider that lives outside the service itself: a managed OAuth flow, a third-party single sign-on integration, a centrally hosted key management service. A sealed appliance generally can't assume any of that is reachable, because reaching it would mean reaching outside the boundary the appliance exists to maintain.

That pushes authentication and access control inward. Credential issuance, key rotation, and session validation have to be handled by systems inside the sealed environment, integrated with whatever identity infrastructure the customer already runs on-premises: a directory service, a locally hosted certificate authority, an enterprise identity system that never needs external reachability to function. The appliance can't assume a hosted identity provider is one call away; it has to integrate with an on-prem equivalent or provide its own self-contained mechanism, and either path has to hold up under the same scrutiny as the rest of the sealed boundary. An endpoint with weak local authentication is a far easier way in than breaching the physical enclosure.

Internal routing: many services, one sealed surface

Behind a single external-facing endpoint, a modern appliance is rarely one monolithic model server. It's a set of internal services, the inference layer, a retrieval or memory component, logging and audit capture, configuration and health endpoints, coordinating over an internal network that never crosses the appliance's boundary. The API surface a caller sees has to present as a coherent, predictable interface even though several distinct services may be handing the request off to one another underneath it.

That internal routing has to be as deliberate as networking elsewhere in the enclosure: a request touching multiple internal services accumulates latency and failure surface at each hop, and a routing layer not designed for the appliance's actual traffic pattern can turn a fast model into a slow-feeling API regardless of how capable the model itself is. Getting this right means the API layer has to know, for every endpoint it exposes, exactly which internal services that request will touch and why, not just that a response eventually comes back.

Governed connectivity is not the same as no connectivity

It's tempting to describe a sealed appliance's API surface purely in terms of what it blocks, but the more accurate description is that connectivity is governed rather than absent. An appliance still needs to serve requests from many callers across a facility's internal network, still needs to expose health and observability endpoints an operations team can monitor, and, depending on how a deployment is scoped, may need to integrate with specific internal enterprise systems the customer has explicitly approved, such as a ticketing system or a version-control server that never itself leaves the facility.

That's the substrate-level distinction underneath every product in the lineup: connectivity that's explicit, auditable, and scoped to specific, named internal systems is categorically different from connectivity that's implicit, unbounded, or reaching toward infrastructure the operator doesn't control. An endpoint that talks to a source-control server in the same facility is not a compromise of the air gap. An endpoint with an undocumented dependency on resolving an external hostname is. The engineering discipline is in knowing, and being able to demonstrate, which category every endpoint falls into.

Where this plays out differently across the lineup

The shape of the API surface differs by what the appliance is built to do. Forge's endpoints are built around the request pattern of a coding assistant embedded in daily engineering work: completion requests, retrieval queries against an indexed codebase, session state for an ongoing interaction, reachable from IDE plugins and CI integrations a development team already runs internally. Czar's endpoints skew toward job submission, run management, and status and metrics reporting for long-running R&D workloads, called by internal tooling rather than an editor in the moment. In both cases the endpoint surface is scoped to the workload the device runs, not offered as a general-purpose API that happens to also do the job.

Chassis builds inherit the same governed-connectivity discipline but apply it to whatever API surface the underlying software already exposes. An ISV shipping its own product as a sealed, on-premises unit typically arrives with an existing API its cloud customers already call. The work is reproducing that interface behavior inside the sealed boundary, so a customer moving to the on-prem appliance sees the endpoints it already integrates against, not a redesigned surface to re-onboard onto. The API contract stays the ISV's; what changes is everything behind it.

The endpoint is the boundary, restated

An appliance can get every other part of its sealed design right, enclosure integrity, hardware-level network isolation, tamper detection, and still leak trust through a poorly considered API. The endpoint is where the inside-the-facility world actually touches the machine, which makes it the part of the system most exposed to whatever assumptions a caller brings with them. Designing that surface to feel unremarkable to a developer while remaining rigorously scoped to what the sealed boundary allows is not a secondary concern layered on top of air-gapped hardware. It's one of the places where a sealed appliance either holds together as a coherent system, or doesn't.