Eliminating Prompt Leaks in Proprietary Software Engineering

A coding assistant's suggestion has to come from somewhere. When it completes a function, proposes a fix, or answers "what does this module do," it is not reasoning from nothing. It is reasoning from context assembled out of the surrounding repository: the function signature, the imports, the neighboring files, sometimes a much wider slice of the codebase pulled in by a retrieval step the engineer never sees happen. That context is the product. It is also, for a cloud-connected tool, the payload of a network request to infrastructure the organization does not operate. Engineering teams evaluating a coding assistant tend to ask whether the tool is good. The question with more consequence is what, exactly, gets bundled into the request that makes it good.

This is a narrower problem than general prompt leakage, and it deserves its own accounting, because software engineering context has properties that make it a worse thing to lose than an ordinary document. Source code is often the whole of a company's competitive position rather than a description of it. It compiles into a working system a competitor could run. It frequently sits under contractual or regulatory restriction that has nothing to do with the company's own confidentiality preferences: export control, a prime contractor's flow-down clause, a customer's data residency requirement. And unlike a document an employee might pause before pasting, code context leaves the boundary continuously, automatically, and largely without anyone deciding to send it in the moment.

The completion is the tip of a much larger request

An autocomplete suggestion looks like a small, local event: a few lines appear in the editor a second after a keystroke. What actually happens is that the assistant assembles a context window and ships it to wherever inference runs. For a cloud-hosted tool, that means the current file, frequently several neighboring files chosen by a relevance heuristic, sometimes a summarized index of the broader repository, and the raw text of whatever the engineer just typed, all of it serialized into a request and sent to the vendor's inference endpoint before a single token of the completion comes back.

Engineers rarely see this assembly step, which is precisely what makes it a governance blind spot rather than a deliberate risk anyone signed off on. Nobody reviewed the decision to include a neighboring file in the context window. A retrieval heuristic made that call, silently, to make the completion better. Multiply that by every keystroke, in every file, across every engineer on a team, for the life of an editor session, and the resulting outbound volume dwarfs anything a manual paste-into-chat workflow would produce. The chat-window leak is a discrete, occasional event a security team can at least imagine auditing. The autocomplete leak is ambient, running continuously in the background of ordinary work, invisible unless someone goes looking for the network calls a plugin is quietly making.

Where the exposure compounds beyond the prompt itself

Prompt content is the most obvious channel, but a modern AI-assisted toolchain has several more, each carrying its own slice of proprietary context out of the boundary.

Telemetry is the least examined of these. Coding-assistant plugins typically report usage analytics back to the vendor, which suggestions were accepted, which were dismissed, latency, error rates, framed as product-improvement data rather than as source disclosure. But acceptance and dismissal events are frequently logged with enough surrounding text to be reconstructible, and "product analytics" is exactly the kind of pipeline built for high-volume ingestion and long retention, not for handling the sensitivity of the material riding along inside it. A team that carefully reviewed the vendor's prompt-handling policy and never asked the same questions about the telemetry pipeline has audited half the problem.

Embeddings are the subtler channel. Repository-aware assistants often build a vector index over the codebase to support retrieval, turning source into embeddings so a query can pull back the most relevant chunks. Where that indexing runs matters as much as where prompts go: an index built by shipping the repository to a vendor's embedding service is a full-codebase disclosure that happens once, during onboarding, and is easy to overlook precisely because it doesn't repeat on every keystroke the way prompt traffic does. A team can lock down prompt-level leakage completely and still have handed over an embedded copy of the entire repository months earlier, during setup.

Plugin chains add a third path that has nothing to do with the primary vendor at all. An IDE extension pulling in language-server updates, a linter phoning home for rule definitions, an AI plugin's own dependency tree reaching out to package registries: each is a legitimate piece of developer tooling, and each is also a process running inside the same environment as the source tree, with its own network behavior that a security review focused on "the AI vendor" will not think to trace.

Why the fix has to be architectural, not procedural

The natural first response to this picture is policy: restrict which tools engineers can install, require a data processing addendum from the vendor, add an approved-extensions list to onboarding. These measures are worth having, and none of them close the actual gap, for the same reason contractual assurances never resolve a leakage problem anywhere else. They govern behavior after the fact and only for the tools that were disclosed and evaluated in the first place.

An approved-tools list assumes visibility the organization does not have. Engineers install extensions the way engineers always have, to solve an immediate problem, based on what a colleague recommended or what showed up first in a search, and an AI-assisted plugin that makes them measurably faster will get installed and used regardless of whether procurement ever reviewed it, because nothing about the editor stops it and nothing about the workflow makes the installation visible to anyone else. A policy that depends on catching every such installation is a policy that will be violated quietly, by capable engineers doing exactly what they're paid to do, faster.

A no-training clause in a vendor contract addresses one narrow fate for the data among several. It says nothing about the telemetry pipeline, nothing about where the onboarding-time embedding step ran, nothing about the plugin dependency chain, and nothing about a vendor's infrastructure being breached regardless of what the contract promised. Each of these is a separate outbound path, and a security review that closes one while leaving the others unexamined has not solved the problem. It has produced a false sense that the problem was solved, which is a worse position than starting.

The only structural fix is removing the outbound path itself. If the model, the retrieval index, and the inference all run inside the same boundary the source code already lives in, the question "could this context have left the enclave" has one answer regardless of how careful any individual engineer was that day: no, because there was never a route by which it could.

What that looks like in practice

This is the reasoning behind Forge's architecture. The code model, the repository index, and the retrieval layer run on the sealed appliance, inside the enclave, so that context assembly (the step where a completion pulls in neighboring files, prior commits, or a wider slice of the codebase to improve its answer) happens entirely on hardware the organization controls. Indexing runs locally, once, at onboarding, rather than by shipping the repository to a vendor's embedding service; the index is rebuilt as commits land, but it is rebuilt inside the boundary each time, not reconstructed by round-tripping code out and an index back. There is no telemetry pipeline reporting acceptance and dismissal events to outside infrastructure, because there is no outside infrastructure in the loop to report to.

This does not eliminate the need for judgment about tooling. A plugin's dependency chain still deserves scrutiny, and an engineer can still misconfigure a network boundary the way any tool can be misused. What it removes is the structural inevitability of leakage that a cloud-connected assistant carries by design, where the tool being good at its job and the tool sending your code somewhere else are, architecturally, the same fact. With Forge, being good at its job means indexing and reasoning over the repository more thoroughly than a rate-limited API call would allow, precisely because there is no rate limit, no metering, and no outbound connection shaping how much of the codebase the assistant is willing to consider at once.

The question worth asking in evaluation

Most coding-assistant evaluations center on suggestion quality: acceptance rate, latency, how well it handles the team's particular stack. Those are reasonable things to measure, and they miss the question that actually determines whether the tool is usable at all for teams whose source code cannot leave a defined boundary: not how good is the completion, but where was the context that produced it, for one full second, between the keystroke and the response. For a cloud-hosted assistant, the honest answer to that question is a vendor's infrastructure, a request log, and a set of contractual promises about what happens next. For a sealed, repository-aware assistant, the honest answer is the same rack the source code was already sitting in, and no request log anywhere else exists to ask about.