Overview

This audit separates what NOIR’s placement protects from what remains exposed: local encoding and decoding reduce direct exposure of raw endpoints, while representations, output mappings, gradients, and client-held secrets define the unresolved boundary. It examines the honest-but-curious assumption, no-oracle and no-insider conditions, repeated observations, and cloud adaptation, then asks whether a defense preserves model utility. The result is a scoped claim, not a universal privacy number.

Learning outcomes

NOIR’s local endpoints reduce direct exposure, but cloud-visible representations can still support reconstruction.
A privacy claim depends on secret client state, no encoder oracle, no insider disclosure, and an honest-but-curious cloud.
A complete audit measures semantic, sensitive-token, and functionality leakage alongside the utility cost of defense.

Keywords

NOIRboundaryassumptionsrepresentationsgradientsleakage

A First Audit: What NOIR Protects—and What It Leaves Visible

NOIR has now been reduced to a concrete system boundary: the client keeps prompt preparation and code decoding, while the cloud runs the middle of an open-source language model. This chapter connects that boundary to the attack surface already established and asks what the architecture protects before any additional privacy transformation is counted. The practical judgment is simple but demanding: a design is only as private as the representations, mappings, gradients, and assumptions that remain visible after the raw prompt has been moved out of the cloud path.

Placement protects endpoints, not the interface

The first audit question is what the placement itself accomplishes. NOIR’s local encoder means that the client does not send the original prompt as readable text. Its local decoder means that the cloud does not receive the final code in the intended generation path. That is meaningful protection. It narrows direct exposure of the two most obvious assets: the request and the result. A provider cannot simply read the prompt it was given or store the source file it returned, because the design does not give those objects to the provider in that form.

But local endpoints do not make the middle interface empty. The encoder must send a representation that contains enough information for the cloud’s middle blocks to continue the computation. The cloud returns an enriched representation that contains enough information for the local decoder to finish it. Both objects are designed to carry model-relevant structure. That creates a basic systems paradox: the interface succeeds when it preserves useful information, while the privacy claim succeeds when that information is difficult to interpret.

The difference between “not present” and “not inferable” is the heart of the audit. Raw prompt text may be absent, yet the cloud can still receive a vector shaped by the prompt’s tokens and context. Final code may be absent, yet the cloud can try to reconstruct it by pairing the representation with its own model-side components or by observing the gradient path during tuning. Placement changes the route of exposure; it does not by itself answer what an observer can derive from the route.

The same distinction applies to ownership. The client retains the prompt, private examples, local model pieces, vocabulary, tokenizer, and generated code. The cloud retains its middle computation and its own model-side state. This division is useful because the client can keep the objects needed to interpret its data and output. It also means that client-held state is part of the security boundary. If the cloud learns the client’s token mapping or obtains a local model component, a message that was previously opaque may become much easier to interpret.

A useful audit therefore treats the pipeline as a set of transitions rather than as a single upload:

A private prompt is tokenized and prepared on the client.
An encoded representation crosses into cloud computation.
An enriched representation crosses back.
The client decodes it into code and keeps the result.
During tuning, gradients cross the boundary in the reverse direction.

The first and fourth transitions protect the visible endpoints. The second, third, and tuning path carry the unresolved privacy question. A boundary review that checks only where text is stored will miss the objects that make the model work.

The distinction becomes concrete in a coding scenario. A developer’s prompt might contain a private function specification and a test that names an internal behavior. NOIR can keep that wording on the client. If the encoded representation nevertheless lets the cloud recover the request’s gist, raw-data confidentiality has succeeded while encoded-information privacy has failed. If the local decoder keeps the output file private but the cloud can infer a functioning implementation from its own reconstruction route, code confidentiality or code functionality has failed. One privacy label cannot describe both outcomes.

This is also why the cloud’s return message matters.

Published by DeepMox

FAQ

Why is “not inferable” different from “not present” in NOIR?

“Not present” means the cloud does not receive raw prompt text or final code; “not inferable” asks whether it can derive their meaning from visible representations.

Which assumptions limit NOIR’s privacy claim?

NOIR’s claim assumes an honest-but-curious cloud, secret client-held state, no encoder oracle, and no compromised client insider. A malicious or better-informed observer changes the claim.

What should a NOIR privacy audit measure?

A NOIR privacy audit should measure prompt and code similarity, reconstructed tokens, sensitive information, shared functionality, repeated-pattern leakage, and utility under the same conditions.

Previous9 minNOIR: Local Encoder, Cloud Middle

Next8 minNOIR: INDVOCAB and Token Privacy

NOIR Privacy Audit: What Remains Visible

A First Audit: What NOIR Protects—and What It Leaves Visible

Placement protects endpoints, not the interface

FAQ