The Missing Map: Tokenizer, Gradients, and Split Tuning

NOIR’s protection has a second boundary problem after the prompt embedding is randomized. The client may prevent the cloud from identifying an input token, yet the cloud can still try to infer output tokens from decoder indices or from the gradients used during fine-tuning. This chapter follows that output and training lifecycle: how LTOKENIZER hides the client’s token map, how STUNING adapts the split model to the altered representation, and why keeping the map and local parameters secret is part of the security claim rather than an implementation detail.

The output needs a different identity

An LLM does not produce a source file in one indivisible operation. It repeatedly selects the next token from a vocabulary. Internally, that selection is represented by a one-hot vector: one position corresponds to the chosen token, and the remaining positions are zero. In an ordinary deployment, the vocabulary and tokenizer are shared. If a cloud sees the relevant index, it can look up the token and read the output sequence.

INDVOCAB changes the embeddings used at the input, but that change does not automatically hide the output index. The client still needs a coherent vocabulary for local encoding and generation. During fine-tuning, the cloud may also see gradients associated with the output labels as the loss travels through the hosted middle blocks. If those labels are tied to the ordinary public tokenizer, a cloud-side reconstruction method can use them to infer the client’s code even when the input embeddings were made indistinguishable.

This is the gap that LTOKENIZER addresses. The client takes every token and its INDVOCAB embedding and assigns it a random, unique index in a private tokenizer. The client uses that index when representing output tokens and when computing the training loss. The mapping is data-independent: it is not chosen afresh for each prompt or each code sample. It is a secret rearrangement of the vocabulary that the client can reuse consistently.

Suppose the client’s intended next token is function. Its private tokenizer may assign that token an index that the cloud’s ordinary vocabulary associates with an unrelated word such as jump. The cloud can observe the index that appears in the gradient path, but without the private map it is led to reconstruct the ordinary token at that position rather than the client’s token. The client, using its own map, interprets the same index as function and generates the correct code locally. The defense changes the meaning of the cloud-visible index, not the meaning of the client’s output.

That distinction is important because LTOKENIZER is not another layer of numerical noise. It does not perturb the generated code or replace the client’s prompt with random text. It changes the dictionary by which an output position is interpreted. A cloud can still see that a token position was active, and it can still run its reconstruction procedure. What it lacks is the client’s association between that position and the ground-truth token.

The security benefit depends on the map remaining secret. NOIR’s paper describes the cloud’s chance of inferring a client token index without the map as negligible in proportion to the vocabulary size. The exact protection is not supplied by randomness alone; it comes from the cloud not receiving an auxiliary signal that reveals the permutation. If the client sends the map, exposes the local tokenizer, or lets the cloud query the client’s mapping, the same observed one-hot vector becomes interpretable.

Keeping the mapping fixed across prompts may seem counterintuitive.