Model keys

Note

Part of the upcoming 0.2 line. The application flow and the catalog of official sealed models are rolling out. The commands this page uses are present on the main branch and are not part of a tagged release, and no catalog model has been confirmed as published yet.

A model key unlocks one official sealed model of the catalog. Each catalog model is sealed under its own key, and the kLLM team issues that key to every applicant approved for the model. One application can cover several catalog models; an approved applicant receives one key file per granted model. Model keys let anyone try the complete workflow, from downloading a sealed model to running it with kLLM, without sealing a model first. They demonstrate the workflow. They are not a confidentiality boundary.

What a model key is

  • One key per model. Every catalog model has its own key. The keys are derived from one master key that the kLLM team keeps offline (Keys); a key issued for one model reveals nothing about the master key or about the key of any other model.

  • The same key for every holder of that model. A model key belongs to the model, not to the applicant. Every applicant approved for a model receives the same key, each in a key file of its own, protected by a passphrase.

  • An ordinary key file. The file has the same format as a key written by kllm keygen or kllm key new. It is imported into the key ring with kllm key import and found by fingerprint when the model is run, or passed to the core commands with --key FILE.

  • For catalog models only. A model key unlocks the catalog model it was issued for, and nothing else. It is not suitable for sealing other models; create a private key for that (Seal a model under a private key).

The key file name follows the catalog name of the model, for example Qwen3-8B-kllm.key for Qwen3-8B-kllm.

What a model key is not

A model key provides no confidentiality, for two independent reasons:

  1. It is shared. Every applicant approved for the model holds the same key, and can decrypt the model’s tokenizer, unlock its weights, read token ids as text and run the model as its owner would. The kLLM team can derive every model key from its master key.

  2. The catalog models are public models. Their bases are public checkpoints. Once the weights are unlocked to run, a holder of the public checkpoint recovers the transforms and the vocabulary permutation from them (Weights of a public model, or of a fine-tune of one). Locking keeps the published files from being matched to the base without the key; it does not protect a model that is running (Locked weights).

Treat every prompt and every output processed under a model key as readable by any party that observes it and holds that key, or holds the public weights together with the unlocked sealed weights. For data or weights that must stay confidential, create a private key and choose a deployment profile that matches the adversary (Deployment profiles, Claims).

Applying for model keys

  1. Apply on the application page of the kLLM website. The form asks for the applicant’s name, email address, organization, role, country and intended use, the catalog models applied for, and agreement to the terms of use. A confirmation link is sent to the email address given.

  2. The kLLM team reviews the application and decides which of the requested models to grant. It may ask for more information.

  3. After approval, the applicant receives an email with a one-time, expiring download link. The page behind it states what a model key is and is not, and offers one archive with the key file of each granted model and instructions. Key files are never sent as email attachments. The key files are protected by a passphrase, which the download page states or the kLLM team provides separately.

What the application form collects, and how long it is kept, is described on the privacy page of the website. The service that receives applications is described in The key-application service. Questions about an application can be sent to hi@anet0.com.

Using a model key

With the commands of the 0.2 line:

$ kllm key import qwen3-8b-kllm Qwen3-8B-kllm.key
$ kllm run hf://ANetResearch/Qwen3-8B-kllm

Key names in the key ring consist of lowercase letters, digits, ., _ and -. kllm key import copies the file into the key ring with mode 0600. When a sealed model is run without --key, kllm run uses the key whose fingerprint matches the model, so the model key is found automatically. To name it explicitly, use --key qwen3-8b-kllm. See Quickstart.

With the core commands, the key file is passed directly:

$ kllm serve Qwen3-8B-kllm --key Qwen3-8B-kllm.key

The first start unlocks the weights into a cache directory (Locked weights). The catalog page describes the other ways to run a catalog model, including client-keyed serving, and how to check a published model against its public base (Checking a published model).

Limits

  • A model key unlocks only the model it was issued for. Every other catalog model needs its own key, and a model sealed under any other key needs that key.

  • A key does not change what kLLM claims in any profile. In particular, kllm run and kllm serve --key decrypt the permuted tokenizer into /dev/shm and unlock the weights into a cache directory on the local machine, and protect nothing from that machine (kllm run).

  • When the kLLM team rotates the key of a model, the next build of that model is sealed under a new key, and keys issued earlier do not open it. Copies downloaded earlier still open with the earlier key.

  • Models remain subject to their upstream licenses; a model key grants no rights to a model (Licenses).

  • Availability depends on the rollout of the catalog. kllm search lists the models in the current library.

See also