Security
Security model
kLLM states its security as design targets and publishes the measured limits of the current release. Deployment profiles are trust boundaries, not scores. Each profile makes one specific claim against one specific adversary.
Design targets
What sealing is designed to achieve
Without the key, recovering prompts or weights is intended to require an academic, high-cost attack beyond the reach of commercial adversaries, with a recovery cost far above the cost of generation.
These are design targets. The current release does not yet meet all of them in every profile; its measured limits are listed below and in the documentation, and they are not hidden.
Deployment profiles
Profiles are trust boundaries, not scores
Each profile is defined by where the key and the decrypted tokenizer live. Choose a profile by the adversary it addresses.
| Profile | Implemented as | Claims | Does not claim |
|---|---|---|---|
| Official catalogRolling out | Public base models sealed under perm and locked, each under its own model key derived from an offline master key. Keys are issued per model to approved applicants. | Without the model key, the published files compute nothing useful and cannot be matched to the public base. A key holder can reproduce the published weights from the public base with kllm verify. Engine logs, request captures and stored payloads hold permuted token ids, not text. | Confidentiality between key holders: every holder of a model's key holds the same key, and the team can derive it. Protection of the weights once unlocked to run: the base models are public. |
| Private SealOpen source | kllm keygen and kllm seal, served with --client and no TEE. The key and the tokenizer stay on the user's machine. | Without the key, the locked checkpoint computes nothing useful and cannot be matched to the public model it derives from. Cloud logs and relayed payloads hold token ids under the vocabulary permutation (language models) or ciphertext (Z-Image results). | Protection of the copy the cloud runs, which is unlocked, against a cloud that reads GPU memory or analyses the weights. |
| Attested CPUEnterprise | kllm serve --key-source cdh --production in a confidential VM (TDX, SEV-SNP, Hygon CSV). The key source and the gateway are part of kLLM Enterprise. | The key and the decrypted tokenizer stay in confidential-VM memory. Users can check that TLS terminates in the attested VM. | GPU memory protection, since the GPU is an ordinary passthrough device. Not yet validated on TEE hardware. |
| Confidential GPURoadmap | Not implemented. | None. | Not applicable. |
Outside a confidential VM, kllm serve --key unlocks the weights into its cache and decrypts the tokenizer into host /dev/shm. It then offers no protection from the host. Use it as a development mode only.
Measured limits
Known limits of the current release
Measured on Qwen3-8B unless stated otherwise. Each limit is documented in full, with the measurement behind it.
- 01
Token ids form a substitution cipher
Against an operator who reads GPU memory, user text reduces to a substitution cipher over tokens. On Qwen3-8B, 23.8% of tokens were decoded by unigram frequency alone, and activations cluster by token (1-NN same-token rate 99.4% at layer 1). The argmax of the logits is a substitution cipher on the outputs.
Documentation - 02
Locking protects the files, not a running model
Locked weights cannot be matched to a public base without the key.
Documentationkllm serve --keyunlocks them on the serving machine, and the keyless copy for client-keyed serving is unlocked before it reaches the cloud, so whoever runs the model holds the unlocked weights. Each tensor's largest binary exponent is stored in the clear. - 03
Fine-tunes of public models are recoverable once unlocked
A fine-tune of a public base model is recoverable from the unlocked sealed weights under both transforms, and under perm at any fine-tune size. A holder of the public checkpoint recovers the transforms and 98.5% of the vocabulary permutation. Weights with no public relative have no known attack under orth, and no proof either.
Documentation - 04
MiniMax H3 output is in GPU memory in the clear
Decoded video and audio are present in GPU memory without protection.
Documentation - 05
Z-Image latents show the image
In client-keyed Z-Image, latents in GPU memory show the image: a principal component analysis recovers a thumbnail without the key. The response is encrypted to a one-off X25519 key. Only five DiT tensors are re-based, so the DiT's activations are not hidden.
Documentation - 06
The serving process sees what it computes
A serving process that is attached to or modified sees everything it computes.
Documentation - 07
The client-keyed server has no authentication
Documentationkllm serve --clientbinds 0.0.0.0 by default and has no authentication. Place it behind a gateway or bind it to 127.0.0.1.
Model keys
What a model key is, and is not
Each official sealed model has its own model key, derived from an offline master key held by the team. Approved applicants receive the keys of the models they apply for. Every holder of one model's key holds the same key, and the team can derive it.
The official models derive from public base models, so sealing does not protect their weights: anyone can download the original. What an official model provides is locked files, permuted token ids instead of text in engine logs, request captures and stored payloads, and reproducibility with kllm verify. For a key known to no one else, seal the model under a private key, or obtain models sealed under a customer key through kLLM Enterprise.
Disclosure
Report a vulnerability
Report vulnerabilities privately through a GitHub security advisory. Do not open a public issue for a suspected vulnerability, and do not include key files, passphrases or decrypted tokenizers in a report.
A result beyond the published limits is in scope, for example a recovery of weights with no public relative under orth, a match of locked weights to their public base without the key, or a recovery of key material from a sealed checkpoint. A limit that is already documented is not a vulnerability in itself. The maintainers acknowledge a report within five working days and agree a disclosure timeline with the reporter.