Workloads Table Reference
Lookup material for the Inventory → Workloads table — each column, each filter, the URL parameters that deep-link to a filtered view, and the rules behind the deployment risk band. For what the protection states mean, see Workload Protection.
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.
Columns
Every column that sorts, sorts on the server, so the order covers the whole inventory rather than the current page.
To choose the columns you see, select the gear icon at the top right of the table. Workload and Status are always shown. Access and Behavior are hidden by default. Your choice is saved in this browser; select Reset to default to restore it. Hiding a column does not clear a filter set on it.
| Column | What it shows | Sort | Filter |
|---|---|---|---|
| Workload | The workload name, its namespace, a Running, Pending, or Gone runtime chip, and a Shared identity chip when another workload uses the same ServiceAccount, and a Multiple identities chip when the workload uses two or more ServiceAccounts at the same time. A red chip is an open High finding. A gray chip marked (acknowledged) means an administrator acknowledged it. See Workload identity rules. | Name | Search box |
| Type | The workload kind, for example Deployment or StatefulSet. | Kind | — |
| Status | The Discovered, Registered, or Protected summary and a second line with the reason, progress, or coverage. | Summary | State cards, Needs attention switch |
| Risk band | The workload's deployment risk band: Critical, High, Medium, or Low. A Signal missing tag marks a band that is Critical because an enabled signal is missing. Hover the tag to read why. | Critical, High, Medium, Low | Column filter, Critical and High risk bands switch, Missing signals chip |
| Readiness | Whether the workload is ready to register: Ready, Fix N (N failing readiness rules), or Review (nothing fails, but a rule is unknown). A workload that automatic registration registered or refused also shows a tag: Auto-registered, Auto-registration refused, or Auto-registration inactive. The drawer also shows Will auto-register and Not eligible for auto-registration. | Ready, Fix, Review | Column filter |
| Team | A registered workload's owning team. A registration made before the team was required shows a gold No team flag; hover it for what that affects. See Set the team on a registration that has none. | — | — |
| Access | The unmatched rate over the last 7 days: Has unmatched calls with a percentage, All calls matched, or No traffic. An Outlier chip marks a workload well above its peers. See Workload access. | — | Column filter |
| Behavior | How many of the workload's containers have a registered behavior declaration bound, for example 1/2. | Share of containers | — |
| Last seen | When AIControls last evaluated the workload. | Time | — |
Filters and URL parameters
Filters combine with AND across filters and with OR within one filter. Each filter reads a URL parameter, so you can share a filtered view as a link. Clear filters removes every parameter in this table.
| Parameter | Values | Set by |
|---|---|---|
search | Free text, 256 characters or fewer | The search box |
status | discovered, registered, protected, comma-separated | The state cards |
attention | 1 | The Needs attention switch |
riskBand | critical, high, medium, low, comma-separated | The Risk band column filter, and the Critical and High risk bands switch, which sets critical,high |
readiness | ready, fix, review, comma-separated | The Readiness column filter |
missingSignals | 1 | The Missing signals chip |
access | unmatched, clean, no-traffic, audit, enforce, or contained | The Access column filter |
registration, enforcement, verification | A status value, comma-separated | Links from other pages |
The audit, enforce, and contained values select workloads by access mode and containment, and the workload list API, GET /api/v1/workload-trust, returns server-side totals for them. See Workload access.
The Critical and High risk bands switch includes workloads that are Critical because a signal is missing. Select the Missing signals chip to see only those.
Sorting or filtering by risk band covers up to 10,000 workloads that match the other filters. Above that, narrow the list with search or another filter first.
Risk band rules
When any enabled signal is missing, the band is Critical (rule S1). Otherwise AIControls evaluates these rules from top to bottom, and the first rule that matches sets the band. A rule matches only when every signal it reads is enabled and available. For how the signals are read, see Deployment risk band.
| Rule | Band | Condition |
|---|---|---|
| S1 | Critical | An enabled signal is missing. |
| C1 | Critical | The ServiceAccount has cluster-admin privilege. |
| C2 | Critical | The pod template is at the Privileged Pod Security level. |
| C3 | Critical | The ServiceAccount is high-privilege, and the namespace has no default-deny egress NetworkPolicy. |
| H1 | High | The ServiceAccount is high-privilege. |
| H2 | High | The pod template is at the Baseline Pod Security level, and the ServiceAccount has write privilege. |
| H3 | High | An intent mismatch where the RBAC grants write or cluster-admin. |
| H5 | High | The ServiceAccount has write privilege, and the namespace has no NetworkPolicy. |
| M1 | Medium | The ServiceAccount has write privilege. |
| M3 | Medium | An intent mismatch where the RBAC grants read. |
| M4 | Medium | The namespace has no default-deny egress NetworkPolicy. |
| L1 | Low | Every enabled signal is available, and no rule above matches. |
The risk band doesn't read Kyverno results. Kyverno policy results feed the registration readiness verdict instead.
Risk band signals setting
Risk band signals is a cluster-scoped setting. Anyone can read it; only an admin can change it, and every change is recorded in the configuration audit log.
| Field | Default | Meaning |
|---|---|---|
| Pod Security | On | Counts the Pod Security level that discovery computes from the pod template. |
| RBAC privilege | On | Counts the ServiceAccount's privilege. |
| NetworkPolicy exposure | On | Counts the namespace's NetworkPolicy coverage. |
| Intent mismatch | On | Counts a registration that declares less Kubernetes access than the RBAC grants. |
| Missing after this many failed refreshes in a row | 3 | A failing signal keeps its source's last good value until this many background refreshes of that source have failed in a row. Between 1 and 100. |
| Or this many minutes after the last successful refresh | 15 | A failing signal is missing once this long has passed since its source's last successful refresh, even with fewer failed refreshes. Between 1 and 1,440. |