OperTraitors: How Kubernetes Operators Can Betray Your Security Posture

Kubernetes operators are designed to reduce operational work by automating tasks that would otherwise require manual intervention. They act through controllers that continuously compare the actual state of Kubernetes resources with the desired configuration.

But that automation also creates a security consideration: operators often rely on highly privileged Kubernetes service accounts.

Palo Alto Networks Unit 42 has released OperTraitor, an open-source, large language model (LLM)-powered analysis engine designed to examine the permissions granted to Kubernetes operators.

The tool compares an operator's documented functionality with the privileges actually granted through role-based access control (RBAC). Unit 42 says the analysis uncovered excessive permissions across components available through Kubernetes operator ecosystems, including cases involving cluster-wide access to sensitive resources.

The research also examines how these risks could become more significant as Kubernetes moves toward AI-enabled and agentic operators.

What Is a Kubernetes Operator?

A Kubernetes operator combines two core components:

• Custom Resource Definition (CRD): Extends the Kubernetes API with custom resources that allow organizations to represent specific operational requirements as Kubernetes objects.

• Controller: Continuously monitors those resources and reconciles the current state with the desired state.

The controller operates through a Kubernetes service account that is assigned permissions using Roles or ClusterRoles.

That service account determines what the operator can do inside the cluster.

If an attacker compromises an operator, the potential scope of that compromise is therefore tied directly to the permissions assigned to its service account.

An operator with unnecessarily broad RBAC permissions can become a high-impact entry point if its container image, dependencies, underlying node, or another component is compromised.

OperTraitor Analyzes Operator Permissions

Unit 42 developed OperTraitor to examine the difference between what an operator is documented to need and what it is actually allowed to access.

The tool can collect information from OperatorHub and locally installed operators. It extracts raw YAML manifests and analyzes the operators' RBAC configurations using an LLM configured for threat analysis.

OperTraitor then assigns a normalized risk score from 1 to 10, based on the difference between documented requirements and granted privileges.

OperatorHub and the Lifecycle Problem

Unit 42 says its research uncovered a broader supply chain concern involving outdated and abandoned operator components.

According to the research, some vendors publish newer versions of their operators through Helm charts, GitHub repositories or ArtifactHub while older versions remain available through the Operator Lifecycle Manager (OLM).

OperatorHub and OLM have historically been widely used in Kubernetes and OpenShift environments. Unit 42 argues that this can leave users with outdated components that may not reflect the vendor's current security posture.

The researchers also reported finding multiple operators requesting excessive privileges, including permissions that could provide paths toward cluster administrator access.

Unit 42 says slightly more than 5% of the operators it examined requested excessive privileges.

The researchers also noted that many operator owners did not respond to responsible disclosure attempts. Unit 42 says this may indicate that some of these operators are no longer actively maintained, although it does not establish that explanation for every case.

The research recommends independently verifying an operator's RBAC requirements and maintenance status before deployment.

Case Study: IBM Turbonomic Prometurbo Operator

One of the most significant findings involved IBM's Prometurbo operator.

During its OperatorHub analysis, OperTraitor identified wildcard permissions associated with the operator. Unit 42 then compared the older OperatorHub version, v8.6.0 from 2022, with a newer version, v8.17.6, available through IBM's GitHub repository.

The analysis found that the newer version still contained an RBAC issue.

The operator's service account was bound to a ClusterRole containing permissions to get, list and watch Kubernetes secrets across the cluster.

Unit 42 notes that most operators do not normally require cluster-wide read access to Secret resources. In typical deployments, access can instead be restricted to the namespace and resources an operator actually manages.

The researchers considered the configuration significant because a compromised operator with that level of access could potentially retrieve secrets belonging to unrelated namespaces.

Those secrets can contain sensitive information such as service account tokens, database credentials, API keys and TLS certificates.

Unit 42 reported the issue to IBM through its vulnerability disclosure process.

IBM subsequently identified the root cause and released a patch that scoped the operator's RBAC permissions according to the principle of least privilege.

The issue was assigned CVE-2026-6389 with a CVSS score of 8.8, categorized as High severity.

Disclosure Timeline

• November 5, 2025: Unit 42 reported the vulnerability to IBM.

• February 3, 2026: IBM confirmed that the issue had been resolved.

• April 24, 2026: IBM published its security bulletin for CVE-2026-6389.

Case Study: Datadog Operator Highlights the RBAC Trade-Off

A second case study involved the Datadog operator.

OperTraitor identified an overly privileged configuration that included cluster-wide access to secrets and permissions involving ClusterRoles and ClusterRoleBindings.

Datadog provided Unit 42 with an explanation for the broad permissions.

According to the research, the operator needs to access secrets whose names are based on user-defined values. Because those names cannot be known in advance, Datadog explained that explicitly defining individual secret permissions would not be straightforward within its architecture.

This illustrates a broader tension in Kubernetes security.

Restricting permissions as tightly as possible can improve security, but highly dynamic systems can make narrowly scoped permissions more difficult to implement without affecting deployment workflows.

Datadog responded by adding documentation explaining its RBAC configuration and the mitigations it had applied. This gives security teams additional information when evaluating the associated risk.

Why Agentic Kubernetes Operators Raise the Stakes

The underlying issue identified by Unit 42 is not new: excessive RBAC permissions increase the potential impact of a compromised operator.

However, the researchers argue that the transition toward AI-driven operators introduces another layer of risk.

The research identifies three emerging patterns.

LLM-Enhanced Operators

Some operators use LLMs to enhance traditional remediation and operational workflows.

Unit 42 gives K8sGPT as an example of an operator that can incorporate LLM-based logic.

If an LLM-enhanced operator has broad RBAC permissions, its ability to access Kubernetes resources may extend beyond what is necessary for its intended function.

External Agent Bridges

Some operators can act as bridges between Kubernetes and external AI agents, including systems using protocols such as the Model Context Protocol (MCP).

In this architecture, an overly privileged operator could provide an external agent with access to Kubernetes resources beyond what is required.

Full Agent Runtimes

Other systems are designed to manage AI agent lifecycles directly within Kubernetes.

Unit 42 says the capabilities of these agents can make infrastructure management more difficult to evaluate using traditional assumptions about deterministic software behavior.

Despite these differences, the security recommendation remains consistent: protect the service account and carefully control the permissions assigned to it.

Securing the Non-Human Identity

Unit 42 recommends treating Kubernetes operators as non-human identities that require the same level of scrutiny applied to other privileged identities.

The research highlights several defensive measures.

Verify Operator Sources

Security teams should not automatically trust the version of an operator available through a default registry.

Unit 42 recommends verifying the vendor's current documentation and considering maintained Helm charts, ArtifactHub entries or official GitHub repositories when deploying operators.

Prefer Namespace-Scoped Permissions

Where the architecture allows it, operators should be restricted to the namespaces and resources they actually manage.

Cluster-scoped permissions should be used only when operationally necessary.

Audit and Downscope RBAC

Security teams should review vendor-provided YAML manifests and examine the RBAC permissions assigned to operator service accounts.

OperTraitor is one open-source option for supporting this analysis.

Monitor Service Account Activity

Kubernetes Audit Logs can help establish normal service account behavior and identify unusual activity.

Examples highlighted by Unit 42 include an operator attempting to list secrets in an unrelated namespace or accessing the Kubernetes API server from an unexpected IP address.

Add Guardrails to AI-Enabled Operators

Organizations experimenting with LLM-enhanced operators or agentic frameworks should also consider network and context restrictions.

Unit 42 recommends:

• Preventing AI-enabled operator pods from reaching the public internet where that access is not required.

• Restricting access to unauthorized internal endpoints.

• Limiting the context and permissions provided to underlying LLMs.

What the Research Shows About Operator Security

The OperTraitor research highlights a specific security problem within Kubernetes automation: an operator's usefulness can depend on permissions that also determine the potential impact of its compromise.

The IBM case demonstrates how a service account with cluster-wide Secret read access can create exposure beyond the namespace an operator is intended to manage.

The Datadog case demonstrates another side of the problem. Dynamic deployments can make tightly scoped permissions difficult to implement, creating a trade-off between least privilege and operational flexibility.

The research also connects this issue to the development of agentic infrastructure.

Traditional operators already have the ability to make changes automatically. Adding LLM-based reasoning or external AI agents can introduce additional complexity into how those permissions are exercised.

That does not change the fundamental security control identified by Unit 42: RBAC permissions remain the boundary that determines what an operator can access and modify.

The Broader Security Lesson

Kubernetes operators are increasingly becoming important non-human identities inside cloud-native environments.

The research suggests that security teams should evaluate these identities based not only on what an operator is designed to do, but also on what its service account is actually permitted to do.

That distinction is particularly important when operators come from third-party registries or have not been actively maintained.

For organizations adopting AI-driven infrastructure automation, the same principle becomes even more relevant.

An AI-enabled operator with unnecessary privileges does not automatically become malicious. But if that operator is compromised or misused, excessive permissions can expand the resources within reach.

The announcement highlights a broader industry shift toward treating machine identities, service accounts and AI agents as part of the organization's security perimeter.

Palo Alto Networks' Security Offerings

Palo Alto Networks says its customers can use Cortex Cloud for cloud posture and runtime security, including identity-related security monitoring.

Unit 42 also points to its AI Security Assessment and Frontier AI Defense services for identifying and mitigating AI-enabled risks.

These are vendor-provided security offerings and are separate from the open-source OperTraitor research tool.

Conclusion

The OperTraitor research puts Kubernetes RBAC permissions at the center of a growing security discussion around automated infrastructure.

Operators can reduce operational effort, but their service accounts can also carry permissions that extend well beyond the resources an operator actually needs.

Unit 42's research identified excessive permissions in multiple operators and documented two different examples of the underlying challenge.

The IBM Prometurbo case resulted in CVE-2026-6389 and a subsequent RBAC fix. The Datadog case showed how dynamic configuration requirements can make least-privilege implementation more complicated.

As Kubernetes automation increasingly incorporates LLMs and agentic systems, the importance of controlling these non-human identities is likely to receive greater attention.

For security teams, the practical starting point is straightforward: understand what each operator needs to access, compare that requirement with its actual RBAC configuration, and reduce permissions wherever the architecture allows.