The expectation is that a root-level key in an existing object for a mustonlyhave ConfigurationPolicy would be deleted/nullified if it's not defined in the ConfigurationPolicy objectDefinition.

However, in the case of something like a RoleBinding where subjects is not defined in the policy and the expectation is to wipe out that field, for example an objectDefinition with:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata: 
  name: self-provisioners
  annotations: 
    rbac.authorization.kubernetes.io/autoupdate: "false"
roleRef: 
  name: self-provisioner
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole

The mustonlyhave, when comparing with a RoleBinding that does have a subjects defined, does not become NonCompliant because the controller is only looking at the root fields that have been defined. For example, this RoleBinding would be Compliant even though it should be NonCompliant for mustonlyhave:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
. . .
subjects: 
- name: my-group
  apiGroup: rbac.authorization.k8s.io
  kind: Group