Skip to main content

Enable enforcement for a workload

Enable enforcement only after you review the observation window, evidence gaps, and expected blast radius.

Self-managed installations only

Workload Trust is available only in private, self-managed AIControls installations, on premises or in a cloud cluster that you run. It needs a dedicated cluster that you run, with Kyverno, Kyverno Runtime, and cluster OIDC and RBAC access in place. Nirmata-hosted (SaaS) workspaces don't include it. See Feature availability.

Before you begin​

The workload must have a user-created registration, valid registered behavior, generated controls, and sufficient evidence for the review gate. Enabling enforcement records the authenticated operator and server time. You cannot supply either value.

Review enforcement​

In the admin console, open Inventory → Workloads. Select the Registered filter card, or find the row directly — its Status column shows Registered with a protection-progress count on the second line. Select the row to open its detail drawer. A collapsed panel whose status is already loaded, such as Details, AI runtime controls, or Activity, shows that status in its header. Security, which loads only when you expand it, shows just its name. Each header shows one tag; when a panel has more statuses, a +N tag lists them when you hover it. Overview shows the protection-progress count beside its name, for example · 5/8 steps. The panel that holds your next protection step shows a Next tag in place of its status when you need to act, for example Next: enable enforcement on AI runtime controls, or a Waiting tag while AIControls finishes the step. Expand AI runtime controls, and under Runtime policy, select Review and enforce…. The same review is also the Enforcement review tab on the workload's full detail page. The review shows:

  • activity that enforcement would deny;
  • rules that were exercised within the registered behavior;
  • unexercised rules and missing evidence;
  • affected workloads, pods, and policies; and
  • controls that remain observation-only.

AIControls checks the current RuntimePolicy application status without changing it. If the saved rendered-policy hash is missing (for example, from an upgrade), differs from the live policy, or the live policy was changed, the review reports an application evidence gap and is not ready for enforcement. Wait for the next reconciliation to refresh the generated controls; reviewing never repairs or applies a policy.

You can retrieve the same review through the API:

curl https://<your-host>/api/v1/workload-protection/prod/Deployment/rag-indexer/enforcement-review \
  -H "Authorization: Bearer $TOKEN"

Enable enforcement​

Select Enable enforcement, or call:

curl -X PUT https://<your-host>/api/v1/workload-protection/enforcement \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"namespace":"prod","kind":"Deployment","name":"rag-indexer","reviewedWorkloadUid":"<workloadUid from the review>","reviewedPolicyGeneration":"<policyGeneration from the review>"}'

Copy workloadUid and policyGeneration from the enforcement-review response. AIControls rejects the request if the workload instance or generated controls changed after review, so retrieve and review the current response again.

The console includes these values from the review you loaded. If enablement returns a stale-review error (409), the console reloads the review and keeps it open. Read the updated evidence before selecting Enable enforcement again; the console does not retry enablement automatically. Disable requests do not require review values.

The request does not immediately verify the workload. The row's summary stays Registered, with the Status column's second line reading "Enable pending…" and the row marked as needing attention, until AIControls confirms that every available enforcement plane applied the controls and they are holding. Only then do the statuses become Enforcing · Verified, and the row's summary becomes Protected.

After you enable enforcement​

Loss of verification​

Verification is not sticky. If a plane stops confirming that controls are active — an unavailable plane, a failed application, or activity outside the registered behavior — the workload's Enforcement status becomes Degraded, Verification returns to Not verified, and its summary drops from Protected back to Registered, marked as needing attention with the reason shown. Open the row and read the reason before re-reviewing.

Recreation​

If the underlying Kubernetes workload is recreated after you enabled enforcement — a new controller instance, not just a new pod — the earlier enablement no longer applies to it. Enforcement returns to Observing with the reason "recreated since enablement." The row's summary drops to Registered, marked as needing attention. Review the workload again and select Enable enforcement to re-enable it for the new instance.

Disable enforcement​

Select Disable enforcement, or call the same resource with DELETE:

curl -X DELETE https://<your-host>/api/v1/workload-protection/enforcement \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"namespace":"prod","kind":"Deployment","name":"rag-indexer"}'

Disabling is idempotent. The controls return to Observing after reconciliation, Verification reports Not verified, and the row's summary returns to Registered.

Last updated on