Why You Can't Put Missile Source Code in GitHub Copilot

Ask a defense-program engineering lead whether their team uses Copilot, and you get one of two answers. Either "no, it's blocked at the proxy," delivered with the flat certainty of someone who has had this argument before, or a pause, followed by "not on the classified repos." That second answer is the more interesting one, because it implies the tool is running somewhere adjacent to the work that matters. Neither answer is really about productivity. Both are about where the source code goes when the autocomplete fires.

This is not a hypothetical compliance worry. Guidance controlled code, the kind that describes seeker logic, propulsion control, or targeting algorithms, is squarely inside the categories that US export-control regimes were built to restrain. The same is true, at a lower but still serious register, for a wide swath of ITAR- and EAR-controlled defense source that never touches a missile at all: radar signal processing, secure comms stacks, platform integration code for controlled end items. None of it is exotic. It's ordinary software engineering, written by ordinary engineers, who increasingly expect the ordinary tooling: a model that reads their file, understands the function they're in, and suggests the next fifteen lines.

The problem is that "reads their file" is doing a lot of work in that sentence, and for a cloud coding assistant it usually means the file leaves the building.

What actually happens when Copilot autocompletes

A cloud code assistant works by sending context (the open file, nearby files, sometimes a repo-wide index) to a model running on infrastructure the vendor operates, not you. That is not a criticism of the architecture; it's the architecture, and it's why the product is good. The completion is well-informed because the model can see enough of your code to be well-informed. But "enough of your code to be useful" and "controlled technical data" are frequently the same bytes.

Export control law does not ask whether the transmission was well-intentioned, whether the vendor's data-handling policy is written down, or whether anyone actually looked at the payload. It asks whether controlled technical data crossed a boundary — to a foreign national, to a server outside the country, to any recipient not properly licensed to receive it. A SaaS API call from a contractor's IDE to a multi-tenant inference cluster is exactly the kind of event that framework was written to catch, regardless of how encrypted the transport was or how strong the vendor's contractual promises are. Deemed export doctrine — the principle that showing controlled technical data to a person, including your own cloud vendor's support engineer, can itself constitute a regulated export — makes the point sharply: the concern was never only about geography.

Contract language and vendor assurances are frequently offered as the fix here — a data processing addendum, a promise not to train on customer inputs, a claim of regional data residency. Read against what export control actually asks for, that's a category error. A DPA is a control: a statement about how the vendor intends to behave, revisable at the vendor's discretion, enforceable only after the fact and only if the breach is discovered. It is not the property a program security officer needs, which is a constraint — a statement about what the system is architecturally capable of, true regardless of anyone's intentions this quarter. No contract clause changes what a network call can carry.

The engineering cost of "just don't use it"

Blocking the SaaS assistant at the proxy is the easy half of the response, and most contractor security teams have already done it. It's also not free. The productivity delta between an engineer with a competent code assistant and one without is now large enough that "no tooling" is a real drag on schedule. Schedule on a defense program has its own downstream costs: cost overruns, missed milestones, engineers who leave for a shop where the tooling doesn't feel stuck in 2015.

The instinct that follows is to build something in-house: stand up an open-weights model on program infrastructure, wire it into the IDE, call it solved. This usually underestimates the problem. A coding assistant that's actually useful needs a maintained model, a repo-aware retrieval layer that stays current as the codebase changes, an update path for new model releases, and a security posture that can survive an accreditor's questions about all of the above — not just "is it on our network" but "what exactly is the trust boundary, and how do we know the running system matches what was approved." That's a sustained platform engineering commitment sitting next to the actual weapons-systems engineering the program exists to do. Most programs are not resourced to carry it, and the ones that try often end up with a bespoke stack nobody wants to own two years later.

What the constraint actually requires

Strip the problem to its architecture and the requirement is simple to state, even though it's hard to buy off the shelf: a code assistant whose model, retrieval index, and inference all run inside the boundary the source code is already governed by, with no network path by which a repository, a prompt, or a completion can leave that boundary. Not encrypted-in-transit-to-somewhere-else. Not logged-but-deleted-later. No path.

That requirement has a shape, and the shape has consequences for how the tool gets built and delivered. The model has to be provisioned and indexed against the actual repositories before the system goes live, because there's no "index on first use against a cloud service" step available. The software has to be verifiable as a fixed, known unit — the same code-scanning discipline a security review already applies to the program's own source ought to apply to the assistant reading it, which argues for a sealed, signed image over a general-purpose server an admin can quietly modify. And the deployment has to fit the program's actual connectivity, which for defense engineering is rarely a single steady-state office LAN — it's a fixed lab today, a field site next quarter, and sometimes a location where "reachback" is a scheduled event, not a background assumption.

Where this sits in the E31 line

This is the problem Forge is built for: a sealed, air-gapped appliance that runs a code model and repository index entirely inside your boundary, on the Substrate platform shared across Element 31's hardware. The repositories are provisioned before the unit ships, the software image is signed and sealed rather than freely modifiable, and the enclosure comes in tiers built for a fixed engineering floor, a relocating field team, or a site with no maintenance reachback at all. "Where the engineers actually sit" was never going to be one answer for a defense program.

Forge and the other two E31 tiers solve adjacent but distinct problems, and it's worth being clear about which is which. Forge answers coding questions against your codebase. It is not a general model-training environment; that is Czar's job, for programs that need to fine-tune or train custom models against sensitive internal data rather than get code completions. And Forge is a standard appliance tier, not the bespoke, built-to-order hardware Element 31 manufactures under Chassis for a specific customer's downstream resale deal. For the narrower, sharper question this article is actually about, where does the autocomplete's context window go, and can that be made structurally unable to leave the room, the honest answer is that convenience and export-control exposure are not a tradeoff you negotiate with a DPA. They're a tradeoff you resolve with a boundary, or you don't resolve it at all.