How leaky is your inference API?

Run a scenario (in order)

Customize the secret & prompt

Secret (fake credentials)

Input prompt

1Encode: the server's reply (what a client sees)

An ordinary-looking answer. The highlighted words are the ones secretly carrying bits, each colour-matched to the character it spells on the right.

2Decode: the secret the attacker recovers

The attacker recovers the secret from the reply alone. For each token it reads the model's ranked list of likely next words from the server's response and finds which rank the server actually emitted, and that rank is the hidden bits. This works whenever the API returns that ranking, as per-token logprobs or a sorted top-n list of tokens.

0 / 0 bits

3Detect: the verifier's live monitor

This score tracks how often the server picks a token the secret seed did not predict. Even honest servers do this a little, because the same model on a different GPU rounds numbers slightly differently, so the detector allows a small baseline and only reacts above it. Once the score passes the alarm line, the server is flagged.

How a secret gets packed into ordinary word choices (tokens) · live worked example

At most steps, several different next words (really tokens, which are not always whole words) would all read naturally. The attacker exploits that freedom: it emits the acceptable word whose position in the ranked list spells the next chunk of the secret, so the reply still reads normally, but which words were chosen secretly carries the data. Every row below is the real attack running on this reply.

Show details (word probabilities + how it works)

The % next to each word is how sure the model was about it: when the top few are close, swapping one word for another is invisible; when one word clearly wins, there is little room to hide. Word #0 (underlined) is the word the model would have said on its own, and when the secret happens to land on it, the reply is completely unchanged. The more words the model is genuinely unsure between, the more secret data a single choice can carry (a menu of n words carries log₂ n bits).

Here the secret rides in the value of each reported logprob, not in which token was chosen. On a compromised server, an adversary hides the secret in the last bytes of each returned number. To read it back: take the returned value to its 6 decimal places as a whole number, and read off its last bytes — each byte (8 bits) is one character. In the first row below, the model's real logprob −0.000311 is returned as −0.034014; as a whole number that is −34014, whose last two bytes are 01111011 = { and 00100010 = " — the start of the secret. The reply's text is completely unchanged; only the reported numbers carry the payload, and the token verifier never inspects them — it only re-derives which token was emitted. Each logprob carries two characters and a token returns twenty of them, so one token spills a long run of the secret at once. (How many bytes each value can hold is a modeling choice — the returned numbers carry more precision than the demo uses.)

builds	secret bits	the model's menu (chosen word boxed)	bits this step

Run a scenario to fill this in — the token menu for 1, 2, 3, or the logprob before → after for 4.

Scoreboard

Run 1, 2, 3, 4 in order. Each row records the outcome.

scenario	secret leaked?	live monitor	bits/token
1 · no defense	—	—	—
2 · attacker unaware of it	—	—	—
3 · attacker adapts to it	—	—	—
4 · logprob-value channel	—	—	—