A paid text-embedding endpoint returns only vectors — what does its reply metadata leak?

## The vantage this question describes The adversary here is an ordinary paying customer of a hosted text-embedding service: text goes in, a fixed-length float vector comes back, billed per thousand inputs. They are not reading the answers more cleverly — that is a different attack. They are reading everything *around* the answers: how long a call took, what shape came back, and what the service says when a request is rejected. This is **incidental behaviour**, and the reason it matters is that the customer is entitled to all of it. It arrives with traffic they were buying anyway. ## The three signals, and what each one actually pins down **Output shape.** The returned array has a length and a numeric type. That is not an estimate — it is exact, and it is disclosed on the first call. It fixes the dimensionality of the embedding space the product is built on, and the precision the service is willing to hand out. Dimensionality is a strong hint at the family and rough scale of the encoder behind it, because published encoder families cluster on a small number of conventional widths. **Error text.** Requests that are too long, empty, wrongly typed, or in an unexpected encoding produce error strings, and error strings are documentation nobody meant to write. A message that names a maximum token count discloses the tokenizer's input ceiling. A message that distinguishes "too many tokens" from "too many characters" discloses that tokenisation happens before the length check. A message that behaves differently across scripts or languages discloses something about how the text is normalised and segmented. None of this is secret in any deliberate sense; it is simply informative. **Timing.** Latency per call varies with input length. Averaged over many calls, the *shape* of that relationship carries information: roughly linear growth in tokens versus something steeper, a step at a particular length, or a flat region up to some point followed by a rise. That tells an attacker something about compute scale and about batching or truncation behaviour. It is the noisiest of the three signals by a wide margin, and how much of it survives measurement noise is a separate question in its own right. ## What the attacker walks away with A **prior**. Concretely: an output dimension known exactly, an input ceiling known nearly exactly, a preprocessing story partly constrained, and an architecture family narrowed from "anything" to "one of a few plausible ones at roughly this scale". Hypotheses have been eliminated. That is genuinely useful to someone assembling a functional copy — it saves them from sizing their own model absurdly or from wasting paid calls on inputs the endpoint will truncate — but it is a head start, not the thing itself. ## What it is not It is not parameter recovery. No number of latency measurements yields a weight. It is not a specification: layer counts, hidden widths, attention configuration, training corpus, objective and hyperparameters are not recoverable this way, and claiming otherwise is the standard overstatement in a report of this kind. It is also not the expensive part of copying an endpoint — the fidelity of a copy is set by which inputs get bought and how well the replies are fitted, not by whether the copy shares the target's blueprint. ## Where the line sits Two neighbouring subjects look identical and are not. Timing as a *cryptographic* concern — a comparison whose duration depends on a secret, and the constant-time discipline that answers it — is application-security material about secrets, not about model shape. And latency, batching and autoscaling as *serving* behaviour to be tuned against a service objective is a capacity subject; here the same numbers are being read by somebody who does not own the service and cannot see inside it. The distinguishing feature of this leaf is the actor: someone outside, inferring the shape of a model they do not own, from replies they paid for. ## How to talk about it in an interview Say what each signal pins down and how precisely, and then say what it does not reach. The honest summary is that this channel is cheap, always present, hard to remove without degrading the product's usability, and worth a bounded amount — a prior on the model's shape, not the model.