Can Private Code Generation Hide Prompt Semantics from the Cloud?

Yes—but only in a qualified engineering sense. NOIR can substantially reduce a cloud’s ability to reconstruct the meaning of prompts and generated code when the cloud is honest-but-curious, the client keeps the private tokenizer and local model pieces secret, and the workload resembles the paper’s evaluated code-generation settings. It does not make the cloud blind, protect against every adaptive strategy, or turn a benchmark result into an absolute guarantee. The final judgment depends on what must be hidden, what crosses the boundary, what counts as a harmful inference, and which costs the client can accept.

What NOIR can hide—and under what conditions

The strongest case for NOIR comes from following the whole path rather than focusing on one privacy feature. The client prepares the prompt locally, uses an IND-preserving vocabulary to make token embeddings difficult for the cloud to identify, sends an encoded representation to the cloud’s middle model, receives an enriched representation, and decodes the code locally. The local tokenizer adds a secret map for output indices, and split tuning adapts the encoder, middle computation, and decoder to work together despite the altered representation. Each part closes a different gap.

Local placement protects the endpoints. The cloud does not receive the prompt as readable text and does not receive the final code through the intended generation path. That is already better than an ordinary cloud coding assistant for a client concerned about proprietary instructions or output files. But placement alone cannot hide the meaning carried by an intermediate representation. The cloud must process a representation rich enough to support generation, and it retains its own model-side state and the messages exchanged during tuning. NOIR’s privacy mechanisms matter because the representation is useful.

INDVOCAB addresses the forward direction. It changes the numerical values associated with token embeddings while preserving the client’s token sequence and the relationships among instructions, prompts, templates, and code. Adaptive randomized response favors feature values that are similar to the original, which aims to reduce the utility damage of indiscriminate noise. The formal ε-INDVOCAB condition bounds how much a protected outcome can favor one ground-truth vocabulary token over another under the specified token-level game. Smaller ε means a stronger indistinguishability constraint, but also a harder generation problem.

LTOKENIZER addresses the reverse direction. Even if the cloud cannot identify an input embedding, it may see one-hot output indices or gradients connected to the decoder. A shared ordinary vocabulary could translate those indices back into readable tokens. A secret, randomly assigned client-side tokenizer changes that interpretation. The client sees the intended token; the cloud’s ordinary dictionary points to an unrelated one. The output remains useful to the client without giving the cloud a direct token lookup.

STUNING addresses the interface between privacy and model utility. The privacy transformation changes the distribution that enters the cloud’s middle blocks and the distribution returned to the local decoder. The client therefore tunes the encoder and decoder around the protected representation, while the cloud may tune a lightweight LoRA adaptation. The training signal remains a privacy surface, but the system avoids the simpler failure in which stronger privacy makes the model unable to generate relevant code.

The combination is more important than any component considered alone. INDVOCAB without LTOKENIZER leaves an output mapping to attack. LTOKENIZER without a protected embedding leaves the prompt representation open to inversion. Either defense without the tuning loop can preserve a formal boundary while producing poor code. NOIR’s claim is a systems claim about several transitions: token identity into embedding, embedding into cloud computation, cloud output into local decoding, and loss into gradients.

The paper’s results support a substantial reduction in the reconstruction methods it evaluates. In the highlighted MBPP experiments, correctly reconstructed prompt tokens fall to 0.028 under NOIR from 0.28 for the defense-free mechanism, and correctly reconstructed code tokens fall to 0.108 from 1.00. Sensitive-information leakage falls to 0.038 from 0.98. The reported protected experiments also show zero attack success for the measured code privacy and confidentiality outcomes and zero functionality attack success in the highlighted settings. Frequency-analysis attacks recover a few common instruction-template tokens but not client-specific prompt or code tokens after those common items are excluded.

These measurements answer meaningful questions. They suggest that a cloud using the paper’s PromptRA, CodeRA, and frequency-analysis procedures is much less likely to recover a clear prompt gist, sensitive code information, or functioning code when the combined defenses are enabled. The functionality measure is particularly important: a code reconstruction that passes the client’s tests can leak behavior even when it does not match the original wording. A reduction in token overlap is not enough if the attacker still obtains a working implementation.

The evidence does not answer every privacy question. “Zero attack success” means that the tested procedure did not reach the paper’s threshold in the stated condition.