Skip to content

Licensing

Kysira agents are gated by a license. Before an agent can pull and decrypt a protected model, it must present two credentials, which you create and manage yourself in the app.kysira.ai console:

Credential What it is Where to get it
License key A signed license token — proves what you're entitled to (which models, expiry). Verified offline by the agent. License keys tab
Agent certificate An mTLS client certificate + private key — proves who is connecting when the agent fetches a model's decryption key. Agent certificates tab

They protect different layers, so the agent needs both: a license token alone can't open the key-delivery connection, and a certificate alone has no entitlement. Both tabs appear once your company is licensed — if you don't see them, contact support@kysira.ai.

The agent also verifies your license token's signature offline against the Kysira license-signing public key — this is baked into every kysira-inference image at build time, so you don't need to obtain or supply it yourself.


License keys

A license key is the signed token your agent presents. You can create several (for example, one per environment) and give each a name.

  1. Go to License keys → New key.
  2. Give it a name (e.g. production) and create it.
  3. Copy the license token now — it is shown only once. Afterwards the console shows only a masked value and a fingerprint.

To revoke a key, use the trash icon on its row. Revocation is immediate: any agent still using that token will be denied at its next key fetch.


Agent certificates

An agent certificate is your agent's network identity for the key-delivery API. It behaves like an SSH or EC2 key pair: you download the certificate and private key once at creation, and Kysira never stores the private key.

  1. Go to Agent certificates → New certificate.
  2. Give it a name (e.g. prod-cluster) and create it.
  3. Download the bundle now. The download is a single JSON file (kysira-agent-cert-<name>.json) with three fields:
  4. client_cert_pem — the client certificate
  5. client_key_pem — the private key (shown once, never recoverable)
  6. chain_pem — the issuing CA chain

Extract each field into its own .pem file with jq (its -r/raw-output flag is what un-escapes the embedded \n line breaks back into real newlines — the console emits standard JSON-escaped strings, so this is the correct extraction for the format it actually produces. Copying the field's value out any other way, e.g. selecting text from the console's copy buttons by hand or a naive string substitution, is a common way to end up with a single-line PEM that openssl/most TLS libraries reject):

jq -r .client_cert_pem kysira-agent-cert-prod-cluster.json > client-cert.pem
jq -r .client_key_pem  kysira-agent-cert-prod-cluster.json > client-key.pem
jq -r .chain_pem       kysira-agent-cert-prod-cluster.json > chain.pem
chmod 600 client-key.pem

If you lose the private key, you can't get it back — just issue a new certificate and revoke the old one.

Multiple certificates & rotation

A company can hold many active certificates at once. The key-delivery API accepts any active certificate from your company paired with a valid license, so you can:

  • Rotate with zero downtime — issue a new certificate, roll it out to your agents, then revoke the old one. Both work during the overlap.
  • Isolate per cluster — issue one certificate per cluster so you can revoke a single cluster without affecting the others.

Revoking a certificate (trash icon) is immediate and independent of your license keys.


Giving the credentials to the agent

Supply the license token, client certificate, private key, and CA chain to the agent as a Kubernetes Secret (or, on Cloud Run, as Secret Manager secrets), then point your deployment at it.

  1. Combine your certificate with its CA chain into one file — the agent presents both together:
cat client-cert.pem chain.pem > client-cert-chain.pem
  1. Create the secret:
kubectl create secret generic kysira-license \
  --from-literal=token="<your license token>" \
  --from-file=client-cert-chain.pem \
  --from-file=client-key.pem \
  -n kysira
  1. Enable licensing in your Helm values (see Kubernetes deployment or the Client deployment guide for the exact keys), or set the equivalent Secret Manager + env vars on Cloud Run (see GCP Cloud Run deployment).

Treat these as secrets

The license token and the certificate private key are sensitive. Store them in a secrets manager, never commit them to git or bake them into an image, and rotate them if you suspect exposure.


Enforcement modes & rollout

Set LICENSE_ENFORCEMENT to control what a denied or missing license does:

Mode Behavior
off (default) No license checks at all — the agent needs no credentials.
permissive Verifies the license and logs the result, but always boots, even on a denial. Use this to confirm your license is valid without risking an outage from a misconfigured token.
enforce A denial fails closed — the container refuses to serve.

How it fits together

When an agent starts, it:

  1. Verifies the license token offline against its embedded public key — checking the signature, expiry, and that the requested model is entitled.
  2. Opens a mutually-authenticated (mTLS) connection to the Kysira key-delivery service, presenting the agent certificate.
  3. Fetches the model's decryption key, which the service only releases after re-checking the certificate, the license, and a single-use challenge.

Revoke either credential and the next key fetch fails closed.

client certificate not bound to this license's tenant

Your license and your agent certificate must come from the same company account — the key-delivery service checks that they match before releasing a decryption key. If you see a key-grant stage failed log line, you're most likely mixing a license/certificate pair issued for two different companies or environments — reissue both from the same account.