Workload RBAC Evidence
AIControls can read the RBAC bindings of each workload's ServiceAccount and the NetworkPolicies in its namespace. It uses them to classify the ServiceAccount's privilege, flag a high-privilege agent, and suggest the Kubernetes tier when you register a workload. The reader is on by default, and its output is evidence only: it never changes a Workload Protection state. The RBAC privilege, NetworkPolicy exposure, and Intent mismatch signals of the deployment risk band need it.
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.
What it reads
The chart renders a separate ClusterRole named <release>-workload-posture. It grants list, and only list, cluster-wide on:
| API group | Resources |
|---|---|
core ("") | serviceaccounts |
networking.k8s.io | networkpolicies |
rbac.authorization.k8s.io | roles, clusterroles, rolebindings, clusterrolebindings |
There is no get, no watch, and no write verb. Secrets and pods are never in this grant. The grant also has no create on subjectaccessreviews: AIControls classifies privilege from the bindings it lists, and never asks the API server about another subject.
This role is separate from the <release>-posture role that reads Kyverno policy reports (Kubernetes posture). You can grant either one without the other.
AIControls keeps only the fields it evaluates: role rules, binding subjects and role references, ServiceAccount names, and NetworkPolicy selectors and policy types. It reuses one list pass for five minutes per replica.
Turn it off
The reader and its ClusterRole are on by default. At startup, AIControls runs a SelfSubjectAccessReview for each of the six grants, and a missing grant logs one warning that names the missing verb and resource.
To decline the grant, set workloadTrust.workloadPosture.enabled to false and upgrade the release. Then disable the RBAC privilege, NetworkPolicy exposure, and Intent mismatch signals in Risk band signals on the Workloads page, or every workload's band is Critical for a missing signal.
workloadTrust:
workloadPosture:
enabled: false
If the grant is missing, for example because your cluster admin declined the ClusterRole, AIControls reports Needs cluster posture access with the missing grants. It never reports an empty or clean result in place of a missing grant.
How privilege is classified
AIControls evaluates every RoleBinding and ClusterRoleBinding that names the ServiceAccount directly, by its system:serviceaccount:<namespace>:<name> username, or through the system:serviceaccounts, system:serviceaccounts:<namespace>, or system:authenticated groups. It reports the highest level any binding grants:
| Level | Meaning |
|---|---|
none | No binding grants access to API objects. The self-review endpoints every subject has, such as selfsubjectaccessreviews, do not count. |
read | Only get, list, and watch. |
write | At least one other verb. An explicit verb list caps here, even one that names every standard verb plus escalate, bind, or impersonate. A verbs: ["*"] rule through a RoleBinding is also write, with the namespace-admin capability. |
cluster-admin | A rule with verbs: ["*"], apiGroups: ["*"], and resources: ["*"], bound cluster-wide. |
Wildcards match independently on verbs, API groups, and resources. A subresource such as pods/exec matches pods/exec, pods/*, and *. A rule limited by resourceNames still counts, so the classification errs toward reporting privilege. Separate rules or bindings are never combined into cluster-admin: only a literal verbs: ["*"] rule reaches the top level. If the workload's ServiceAccount does not exist in the cluster, AIControls reports the evidence as unavailable instead of none.
A ServiceAccount is a high-privilege agent when it is cluster-admin, or when any binding grants one of these capabilities: cluster-wide secrets read, pods/exec, RBAC writes, escalate, bind, impersonate, nodes/proxy, ServiceAccount token creation, admission webhook writes, or every verb in a namespace.
The NetworkPolicy summary is namespace-level: how many policies exist, and whether one selects every pod with a default deny for ingress or egress. AIControls does not verify that your CNI enforces NetworkPolicies.
Where the evidence appears
- Register a workload: the wizard pre-fills the Kubernetes tier from the bindings. See Register a workload.
- Workloads table: the privilege, the high-privilege flag, the NetworkPolicy summary, and any intent mismatch feed the RBAC privilege, NetworkPolicy exposure, and Intent mismatch signals of the Risk band column. While the reader is off, those signals are missing, so every band is Critical with the reason Signal missing: RBAC privilege (needs-posture-access). Turn the reader on, or have an admin turn those signals off. See A missing signal is Critical.
- Workload detail: the Posture tab and the drawer show a Kubernetes RBAC card with the privilege, the High-privilege agent tag, the bindings, the NetworkPolicy summary, and any intent mismatch. See Workload protection.
None of this evidence is a Workload Protection status, and none of it changes one.