Skip to main content

License management

AIControls requires a valid license before it will process AI traffic — MCP tool calls and LLM requests. Without one, the Admin UI stays fully accessible, but a banner is shown and AI requests are blocked until a license is loaded.

Need a license or an upgrade?

Contact support@nirmata.com for a new license, or to upgrade an existing one.

License types

  • Free — a free, no-signup tier for self-hosted (Kubernetes) installs, described below.
  • Trial — a time-limited license for evaluation.
  • Enterprise — a full production license, issued for your organization (SaaS) or your cluster (Kubernetes Self-Hosted).

Free tier

A self-hosted Kubernetes install with no license loaded processes AI traffic immediately, no signup required — up to a fixed, lifetime limit of 5 identities and 1000 requests. This is meant for evaluation: trying AIControls against real traffic before requesting a trial or enterprise license.

Once either limit is reached, AI request processing (MCP tool calls and LLM requests) is blocked with the same "load a license to continue" behavior described below — the Admin UI stays fully accessible throughout, and nothing about your existing setup needs to change once you activate a real license.

The free tier does not apply to Nirmata-managed SaaS deployments, which require a license (trial or enterprise) from the start.

Managing your license

Go to Setup → System → License in the Admin UI to:

  • View your current plan and expiry date
  • Request a trial extension or an enterprise upgrade
  • Upload a new .lic file you received from Nirmata

Grace period

Licenses are normally issued with a grace period after their expiry date — 14 days unless Nirmata set a different length for yours — during which AI traffic keeps flowing normally while you renew. Your license's actual grace period is shown on the License page.

While a trial is inside that window, the License page badge changes to Active (Grace Period) with a countdown to the date service will actually be blocked — hover the badge, or check the Service blocked on row, for the exact date. The expiry date shown on the page is not the date AI traffic stops; the grace period countdown is.

A license issued with a zero-length grace period is blocked as soon as it expires, with no grace window at all.

Kubernetes Self-Hosted

Self-hosted Kubernetes licenses are bound to your cluster rather than to a Nirmata account — a license issued for one cluster will not activate on another.

1. Get your cluster ID

kubectl get namespace kube-system -o jsonpath='{.metadata.uid}'

2. Request a license

Email the ID above to support@nirmata.com with your organization name and whether you'd like a trial or enterprise license. Nirmata will send you a signed .lic file.

3. Activate the license

Point your Helm values at the license file path:

# values.yaml
proxy:
licenseFile: /etc/aicontrols/license.lic

Then create a Secret from the file and mount it into the pod:

# Replace RELEASE and NAMESPACE with your `helm install` release name and target namespace
kubectl create secret generic aicontrols-license \
--from-file=license.lic=./path/to/license.lic \
-n NAMESPACE

kubectl patch deployment RELEASE-aicontrols -n NAMESPACE -p '{"spec":{"template":{"spec":{
"containers":[{"name":"proxy",
"volumeMounts":[{"name":"license","mountPath":"/etc/aicontrols","readOnly":true}]}],
"volumes":[{"name":"license","secret":{"secretName":"aicontrols-license"}}]
}}}}'

Once loaded, you can also upload a renewed license directly from Setup → System → License in the Admin UI — no restart or redeploy required.

Rebuilding or migrating your cluster?

Your license stops working if the cluster is rebuilt or you move to a new cluster. Email support@nirmata.com for a reissued license.

Upload rejected: tenant/cluster mismatch

When you upload a license through the Admin UI, it is validated against your cluster's identity — the kube-system namespace UID from step 1 — before it is accepted. A license whose tenant_id does not match that UID (including a license issued without any cluster binding, or one issued for a different cluster) is rejected with a 422 tenant-binding validation error (for example license rejected: license: issued for tenant "…", this instance is "…") instead of appearing to activate and then reverting to No License.

This check depends on the proxy having discovered the cluster's identity at startup. If that lookup fails — typically missing RBAC (the proxy needs get on the kube-system namespace) or an unreachable API server — the proxy logs a cluster identity warning and skips tenant binding for that run, so a mismatched license may be accepted. If you see that warning, fix the underlying RBAC/connectivity error and restart the proxy before relying on this validation.

If an upload is rejected:

  1. Re-run the command from step 1 and compare the UID with the one you sent to Nirmata when requesting the license.
  2. If they differ (for example, the cluster was rebuilt since the license was issued), email support@nirmata.com with the current UID for a reissued license.
  3. If the upload succeeds but the response reports the license did not activate, check the proxy logs for the revalidation failure reason (expiry, cluster binding, or storage errors).