What Leaves the IDE

This lesson goes beyond the design

The chapter states the concern precisely — "code context sent to the backend may contain proprietary source code" — and answers it with TLS, encryption at rest, and retention controls. It also requires that "generated code should pass security and license checks" without describing a mechanism.

Those are the right concerns and the wrong altitude. The specific exposures are that the context extractor grabs whatever is open, that the telemetry estimate prices the payload, and that a model trained on public code can reproduce it. This lesson covers all three.

The exposure

Three copies of customer code exist on your infrastructure, and the design accounts for one

Trace where the code actually lands:

1. In the request. Necessary — inference cannot happen otherwise. This is the copy the design addresses, with TLS and encryption at rest.

2. In the telemetry store. Lesson 5 established that 4 KB per event is exactly the 3 KB request plus 1 KB response, so the telemetry is the prompt and the completion. That is 1.46 PB/year of customer source code, retained, in a columnar store built for analytical scans.

3. In the vector index. Lesson 4's retrieval layer holds "repository embeddings." An embedding index over a private repository is a derived copy of that repository — and embeddings are not anonymization. Retrieval returns the snippets, so the index stores or references the design text.

The request:      transient, unavoidable    -> the design addresses it
The telemetry:    1.46 PB/year, retained    -> unaddressed
The vector index: a copy of the repo        -> unaddressed

And the stated requirement is "options for enterprise customers to restrict data retention entirely." You cannot offer that while defaulting to storing every prompt and indexing every repository.

The resolution is tenant policy enforced at the write path, not at query time:

ALL tenants:           metadata only — completion_id, action, language, latency
OPTED-IN tenants:      full prompt + completion, for fine-tuning
NO-RETENTION tenants:  payload DROPPED AT THE INGESTION CONSUMER
                       vector index kept in the tenant's own VPC, or not built

The enforcement point matters: a payload written and later excluded from queries has still been retained. Drop it before the write.

Count every place the data comes to rest, not just the one where it is used.

Secrets in open tabs

The context extractor grabs open files, and developers have secrets open

The design says context includes "the current file, cursor position, open files, project structure." That is exactly right for suggestion quality and it is an uncontrolled channel.

What is routinely open in a developer's editor:

.env                      API keys, database URLs, tokens
config/secrets.yaml       credentials
terraform.tfvars          cloud access keys
a test file               hardcoded fixtures with real tokens
a notebook                an API key pasted while debugging

The extractor has no notion of sensitivity. A ranked snippet from .env is a snippet like any other — and it will be sent, prefilled into a prompt, possibly logged as telemetry, and possibly embedded into an index.

Worse, it can come back out: a model given a .env file in context may complete the next line of it, reproducing a credential into a suggestion.

The mitigations are all client-side, which is where they must be, because the only reliable control is not sending it:

PATH DENYLIST    never include .env, *.pem, *.key, credentials.*, .git/
                 respect .gitignore as a strong signal
ENTROPY SCAN     detect high-entropy strings and long hex/base64 runs
                 before they enter the prompt — cheap, runs locally
PATTERN MATCH    known credential formats (cloud keys, tokens, connection strings)
REDACT           replace detected secrets with a placeholder rather than
                 dropping the snippet — preserves structural context

The last is the elegant one: API_KEY = "<redacted>" gives the model the shape of the code without the secret.

This belongs in the context extractor, alongside the Jaccard ranking from Lesson 4 — the same component, the same pass, negligible cost. And it reinforces that lesson's observation: client-side ranking is a privacy mechanism, because the filtering happens before anything leaves the machine.

A context extractor without a secret filter is an exfiltration path with good intentions.

Generated code you may not be allowed to ship

'Should pass security and license checks' names the requirement and no mechanism

Safety and compliance: Generated code should pass security and license checks to avoid introducing vulnerabilities or incompatible code into repositories.

Correct, and it is the only place the chapter mentions it. Two distinct problems hide in that sentence.

Licence contamination. A model trained on public repositories has seen GPL, AGPL, and other copyleft code. Under some conditions it can emit long verbatim spans of it. Accepting such a suggestion into a proprietary codebase creates a licensing exposure that no one notices until an audit.

The production mechanism is public-code filtering: index the training corpus, and at generation time check whether the output matches a long span of known public code.

Generate the completion
  -> hash sliding windows of N tokens (say 150 characters)
  -> look them up in an index of public code
  -> MATCH -> suppress the suggestion, or surface the licence and attribution

That is a real feature in shipped assistants, offered as a policy toggle — and it is exactly Lesson 3's problem in reverse: it must run inside the streaming path, so it works on a sliding window rather than the completed output.

Vulnerable patterns. Models trained on public code reproduce public code's mistakes — SQL string concatenation, disabled certificate verification, weak hashing, hardcoded credentials. The model has no notion that a pattern is dangerous; it has seen it often.

The mitigation is cheap and the design already has the components: run static analysis on the suggestion before display. The IDE has a linter and a language server, and per Lesson 4 the same symbol table can already filter suggestions referencing symbols that do not exist.

Generated suggestion
  -> lint / SAST rules  -> flag or suppress
  -> language server    -> does every symbol resolve?
  -> public-code index  -> is this a verbatim span?
  -> display

Every one of these checks runs on the client, on a few lines of text, in milliseconds — and none of them requires a model.

The output path deserves the same scrutiny as the input path, and in this system it is cheaper to secure because the artifact is small and the tooling already exists in the editor.

Prompt injection, in a lower key

Present but much less severe than in the support bot, and the reason is instructive

that building block's assistant could issue refunds, which made injection an authorization problem. This one generates text into an editor, and the difference in stakes is large.

The vector still exists — a comment in a file or a dependency is text that enters the prompt:

A model may follow it. The damage is a bad suggestion the developer can decline, which is precisely the low-cost failure mode Lesson 1 identified.

But the severity scales with what the assistant can do, and that is the transferable point:

COMPLETION ONLY:  injection -> a bad suggestion -> the developer rejects it
+ FILE EDITS:     injection -> unreviewed changes across the repository
+ TERMINAL:       injection -> arbitrary command execution
+ AUTONOMOUS:     injection -> a compromised commit, pushed

This design sits on the first row, so the correct posture is static analysis on the output (above) rather than the authorization machinery that building block needed.

But the same rule applies the moment capabilities grow: the model proposes; a deterministic layer disposes. An assistant that edits files needs a diff the developer approves; one that runs commands needs an allowlist and a confirmation step — neither of which can live in the prompt.

Injection severity is a function of capability, not of model quality — which is why the security posture must be revisited every time a capability is added.

The strongest privacy answer is an architectural one the design half-implies

Everything above is mitigation. The structural answer is to change where inference happens.

SAAS (this design):   code leaves the machine -> mitigate exposure
IN-VPC / ON-PREM:     inference runs in the customer's own environment
                      -> code never crosses a trust boundary
LOCAL MODEL:          a small model runs on the developer's machine
                      -> nothing leaves at all

The third is more viable than it sounds for this specific product, because Lesson 6 identified the tiering opportunity: single-line completions are the most frequent request and the least demanding, and a small quantized model can serve them locally in tens of milliseconds — no network, no exposure, no GPU cost.

LOCAL small model:  single-line completions        -> zero exposure, zero latency
REMOTE large model: multi-line generation, explain -> opt-in, policy-controlled

That is a hybrid posture, and it resolves three problems at once: the network round trip from Lesson 3, the GPU cost from Lesson 2, and the exposure in this lesson.

The design's own requirement gestures at it — "options for enterprise customers to restrict data retention entirely" — but treats deployment topology as a retention setting rather than as an architectural choice.

When the data is the customer's most sensitive asset, the strongest control is not encrypting the transfer but avoiding it.

Next: telemetry, metrics, and the perception gap.