Claims

This page states what kLLM claims and what it does not claim. Each statement rests on the threat model in Threat model, the exposure tables in Exposure and the measurements in Attacks.

Design targets

kLLM states its security goals as design targets, separately from its claims. Without the key, recovering prompts or weights is meant to be an academic, high-cost attack outside the reach of commercial adversaries, with recovery cost far above generation cost. These targets are not guarantees of the current release. The claims below are what the current release supports; the measurements in Attacks show where it falls short of the targets.

Claims by profile

Each deployment profile makes one specific claim against one specific adversary. The table in Summary is the authoritative statement of what each profile claims and does not claim. In summary:

• Private Seal claims that the sealed checkpoint on the user’s machine is useless without the key, its tokenizer encrypted and its weights locked, and that cloud logs and relayed payloads hold token ids under the vocabulary permutation (LLMs) or ciphertext (Z-Image results). It does not claim protection against a cloud that reads GPU memory or analyses the weights. The cloud’s copy is uploaded unlocked, and for a public model, or a fine-tune of one, analysing it with the public checkpoint recovers the transforms and Π (see Weights of a public model, or of a fine-tune of one).

• Attested CPU claims that the key and the decrypted tokenizer stay in confidential-VM memory, and that users can check that TLS terminates in the attested VM. It does not claim GPU memory protection, and it has not yet been validated on TEE hardware.

Note

The Official catalog profile is part of the upcoming 0.2 line. It claims only that, without the model key, the published files compute nothing useful and cannot be matched to the public base; that engine logs, request captures and stored payloads hold permuted token ids, not text, and in client-keyed mode the cloud receives neither the key nor the tokenizer; and that a key holder can reproduce the published files from the public base with kllm verify. It claims no confidentiality between key holders, because the key of each catalog model is the same for every applicant approved for it, and no protection of the weights: the catalog models are public models, and wherever one is unlocked to run, its weights can be matched to the public base (Model keys). Confidential-GPU support is planned.

Not protected in client-keyed mode

The Private Seal profile claims only that what the cloud’s software records or relays holds no plaintext. The following are not protected and not claimed.

Token ids are a substitution cipher

Π is fixed per key, so anyone collecting token ids can attack them by frequency analysis (23.8% of tokens from unigram frequencies alone; see User tokens), and with the public base model the weights reveal Π (see Weights of a public model, or of a fine-tune of one). The cloud’s copy of the weights is unlocked, so locking does not prevent this. The second attack applies to a sealed copy of an unmodified public model as much as to a fine-tune of one: the measured recovery is 98.5% of Π on Qwen3-8B, and the remainder are unused tokens. For such models a cloud that holds the public checkpoint can read the token ids in its logs as text once it runs that analysis, so the log protection holds only against software and operators that do not. Logs of token ids are not readable at a glance, but they are not ciphertext.

Z-Image latents in GPU memory show the image

Convolutions and RoPE need the spatial layout, so no transform under which the DiT and the VAE can run hides it. The key’s patch basis mixes the 2×2×16 values of each patch, but every coordinate of the result is still a picture, and a principal component analysis without the key recovers a clear thumbnail.

From left: the user’s image; a channel of the plain latents; a channel of what the cloud holds; one coordinate of the cloud’s patch vectors; the top three principal components of the cloud’s patch vectors as RGB, computed without the key.

This is why the response is encrypted. The patch basis and the sealed text encoder keep the latent input and output and the prompt’s features out of a plain reading; they do not hide the picture. Nor do they hide the DiT’s activations: the client seal re-bases only five DiT tensors, and after the embedders the hidden states are in the same coordinates as in a plain run (see Exposure).

The serving process sees everything it computes

Attaching to the serving process, or changing its code, reveals what the GPU sees. Against that, use the Attested CPU profile, which protects the CPU side; GPU memory additionally requires confidential-computing GPUs, which kLLM does not yet support.

Transport and access control are not provided

kllm serve --client binds 0.0.0.0 by default and has no authentication, and the Z-Image reply encryption does not authenticate the server. Bind 127.0.0.1 or place the server behind a gateway, and use TLS or an SSH tunnel (see Threat model).

Development mode is not a profile

kllm serve --key outside a confidential VM decrypts the tokenizer into host /dev/shm and unlocks the weights into a cache directory on the host’s file system. It offers no protection from the host and is not covered by any claim on this page. kllm run with a sealed model, part of the upcoming 0.2 line, starts kllm serve --key in this mode and is covered by the same statement.

Performance and fidelity statements

Performance statements carry their conditions. On one NVIDIA A40 48 GB, with SGLang 0.5.21 or vLLM 0.31.0, bf16, 1024 input and 128 output tokens, on a GPU shared with another tenant’s light job, in single runs without reported variance, sealed throughput matched plain serving in every measured keyed configuration (never more than 0.3% lower at concurrency 16). Latency deltas are visible in some rows, for example median TTFT at concurrency 1 of 98.0 ms plain against 105.2 ms under perm (SGLang, Qwen3-1.7B), and median TPOT at concurrency 16 of 35.3 ms plain against 37.3 ms under orth (SGLang, Qwen3-8B). Client-keyed serving under vLLM cost 7% of output throughput at concurrency 16 (1036 against 963 tok/s). The full tables and the scripts that produce them are described in Benchmarking plain and sealed serving.

Outputs move by bf16 rounding and accumulation order only: mean |Δ log-prob| of 0.03 to 0.10 against plain serving, comparable to the 0.053 of switching between fp16 and bf16.

What kLLM claims

• The sealed checkpoint is useless without the key: the tokenizer is encrypted under it, kllm serve refuses a key with the wrong fingerprint, and the weights are encrypted in place (locked), so they cannot be matched to a public base either (Locked weights). Once unlocked to run, they can. A party that holds the unlocked weights and the public model from which they derive, whether an unmodified public model or a fine-tune of one, recovers the transforms and Π without the key (measured: 98.5% of Π on Qwen3-8B, under perm at any fine-tune size including zero, under orth for weight changes up to 3% of the weight standard deviation; see Weights of a public model, or of a fine-tune of one). The key itself is not recovered and trusted.kllm stays encrypted, but Π, which is what the blob protects, is read from the weights. Only weights with no public relative are outside this attack. A checkpoint sealed with --no-lock is in the unlocked case on disk as well.

• The transforms are exact in exact arithmetic. The engine runs the sealed model with its own model classes and kernels, and outputs move by bf16 rounding only; measured throughput was close to plain serving under the conditions stated above.

• In the Attested CPU profile, the model key and the decrypted tokenizer stay in confidential-VM memory, and users can check that TLS terminates in the attested VM by combining the binding check with quote verification by an existing verifier (see Threat model). This profile has not yet been validated on TEE hardware.

• Against a cloud that reads GPU memory, the claim is limited to this: user text is reduced to a substitution cipher over tokens, not to ciphertext, and the generated media of MiniMax H3 are visible.

• A fine-tune of a public model is recoverable from the GPU weights under both transforms, and a sealed copy of an unmodified public model, once unlocked to run, reveals its transforms and Π to any holder of the public weights. Locking protects the files, not a running model: whoever runs the model holds the unlocked weights. Closing that gap requires weights that are not a static transform of the plaintext while they run, or confidential-computing GPUs.

• In client-keyed mode, the cloud’s logs and relayed or stored payloads hold no plaintext: token ids for text, ciphertext for images. That is the whole claim; it does not make content untraceable for a cloud that inspects it deliberately.

What kLLM does not claim

• Confidentiality of GPU memory in any profile. The GPU is an ordinary passthrough device, and no current profile is equivalent to a deployment on confidential-computing GPUs.

• That token ids, activations or logits are ciphertext. They are a substitution cipher over tokens.

• Protection of the weights, the transforms or Π of a public model, or of a fine-tune of one, against a party that holds the public checkpoint and the unlocked weights, under orth or under perm. Every party that runs the model holds the unlocked weights: the server with the key, and the cloud in client-keyed mode. This includes the catalog models, whatever key seals them.

• That locking hides the layout of a checkpoint (tensor names, shapes, dtypes and the configuration) or the largest binary exponent of each tensor, which is stored in the clear.

• Protection of the unlocked weights in the cache directory (~/.cache/kllm/unlocked or KLLM_UNLOCKED_DIR). It is an ordinary 0700 directory on the machine that runs the model, and kLLM does not remove it.

• Confidentiality under a model key of the catalog. Every applicant approved for a catalog model holds the same key, and the kLLM team can derive every model key from its master key.

• Security of weights with no public relative. No attack is known under orth, and no proof exists.

• Confidentiality of MiniMax H3 decoded video and audio, which are in GPU memory in the clear.

• That client-keyed Z-Image hides the image in GPU memory, or the DiT’s activations.

• Any protection from the host when kllm serve --key runs outside a confidential VM.

• Authentication, access control or transport security for kllm serve --client and the kllm client commands.

• Confidentiality of request metadata in client-keyed mode: sampling and generation parameters, token counts, timing and the Z-Image latent shape travel in the clear, and the proxy’s /generate endpoint forwards sampling_params and other fields unchanged.

• That the binding check python -m kllm.keyed.attest verifies a quote. It checks only that the evidence names the TLS key, and it exits with status 0 when the gateway reports "source": "none".

• Protection against a serving process that is attached to or modified.

• Validation of the Attested CPU profile on Intel TDX, AMD SEV-SNP or Hygon CSV hardware.

• That the INT8 DiT kernels (--int8) are part of sealing or speed up sealed serving as such. They are a separate kernel optimization with measured numerical drift, and only the attention kernel is verified to commute with perm.

• That serving a sealed model has no cost in every configuration, or that its outputs are identical to plain serving.

• That any model can be sealed. Sealing supports the architectures listed in Supported models.

See also

• Threat model, Exposure and Attacks for the basis of each statement.

• Deployment profiles for the deployment profiles.

• Benchmarking plain and sealed serving for the measured performance tables.