The news
Palo Alto Networks (PANW) research unit Unit 42 released OperTraitor on September 29, 2026, an open-source tool that audits Kubernetes operator permissions. Unit 42 says operators often hold far more access than their jobs require, including implicit paths to cluster administrator access.
Operators are software extensions that use custom resources to manage applications running on Kubernetes, the open-source platform for running containerized software. They work through service accounts, non-human identities whose rights are set by Kubernetes role-based access control (RBAC). Unit 42 called these highly privileged service accounts an often overlooked weak spot.
According to Unit 42, OperTraitor collects RBAC configurations from operators installed in a cluster and from the OperatorHub public catalog, sends them to a large language model (LLM), and gives each operator a risk score from 1 to 10. The score reflects the gap between what an operator is documented to do and the privileges it is actually granted. The project's GitHub page says the rating step uses Azure OpenAI and that results appear in a local web dashboard.
Unit 42 said it found multiple operators, slightly over 5%, that request excessive privileges, including implicit paths to cluster admin access. The researchers said OperatorHub contains abandoned, overly permissive components, and that many operator owners they contacted did not respond to disclosure attempts. The write-up does not say how many operators were analyzed in total.
The most serious case study involved the Turbonomic Prometurbo operator from IBM (IBM). Unit 42 said the operator could read secrets in every namespace of a cluster, access that could let an attacker extract administrative tokens, database credentials, API keys and TLS certificates. The public CVE record for the flaw, CVE-2026-6389, covers Prometurbo agent versions 8.16.0 through 8.17.6 and lists a CVSS score of 8.8, rated high. Unit 42 said it reported the issue on November 5, 2025, IBM confirmed a fix on February 3, 2026, and IBM published a security bulletin on April 24, 2026.
Unit 42 also examined the Datadog (DDOG) operator, which it said had cluster-wide secret access and permissions over RBAC resources. According to Unit 42, Datadog explained that secret names depend on values users define, so access cannot be narrowed in advance. Datadog responded by documenting its RBAC settings and mitigations so customers can make informed risk decisions, Unit 42 said.
The numbers
- Operators Unit 42 found requesting excessive privileges
- Slightly over 5%
- OperTraitor risk score scale
- 1 to 10
- CVE-2026-6389 CVSS score (IBM Prometurbo)
- 8.8 (High)
- Affected Prometurbo agent versions
- 8.16.0 through 8.17.6
Why CEOs should care
For CISOs, the research is a reminder that some of the most powerful identities in a cloud environment are not people. Operators arrive with vendor-supplied permission files that teams often accept as delivered. Security leaders should ask platform teams for an inventory of every operator in production, the cluster-wide roles each one holds, and which of them can read secrets outside their own namespace. Unit 42 advises restricting operators to the namespaces they manage and avoiding cluster-wide roles unless strictly necessary.
For technology buyers, the Datadog case shows a real trade-off: broad permissions make installation simpler but shift risk onto the customer. Vendor-risk reviews for any product shipped as an operator should ask what RBAC permissions it requests, why it needs them, and whether a narrower setup is documented. Unit 42 also recommends against trusting default OperatorHub versions, favoring maintained Helm charts, Artifact Hub listings or official GitHub repositories.
Boards and CIOs approving AI agents in production should note Unit 42's warning about operators that call LLMs or act as bridges for external agents through Model Context Protocol (MCP), a standard for connecting AI agents to tools. Unit 42 said an over-privileged operator in that role could give an outside AI unchecked control over cluster resources. Its suggested guardrails include network policies that block such operators from the public internet and limits on the context and permissions passed to the model.
The bigger picture
The research adds to a broader concern about non-human identities: the service accounts, tokens and agents that run much of the automation in cloud environments. Unit 42 described three patterns that raise the stakes: operators that use LLMs for remediation, operators that bridge to external agents, and operators that run AI agents natively inside a cluster. Unit 42 wrote that "an overly privileged operator today is the autonomous, uncontrolled agent of tomorrow."
Palo Alto Networks sells products in this area, and the post promotes its Cortex Cloud platform and Unit 42 services alongside the free tool. OperTraitor is published on GitHub under an ISC license. Because its analysis step sends RBAC data to Azure OpenAI, security teams will want to confirm that fits their own policies on sharing configuration data with AI services.
What’s next
Unit 42 said many operator maintainers did not respond to its outreach, so more over-privileged operators may remain in public catalogs. Teams running IBM Turbonomic should confirm their Prometurbo agents are not on versions 8.16.0 through 8.17.6. Others can audit operator RBAC, with OperTraitor or existing tools, and follow Unit 42's advice to enable Kubernetes audit logs and alert on unexpected secret access by operator service accounts.
What “Fact-checked” means
Fact-checking means testing a story’s facts against the evidence before it is published. This story went through at least two separate checks before this version was published.
- What we checked
- Its names, figures, dates, job titles, quotes and who said what were checked against the story’s sources, including its main source where it could be opened. The headline was checked for accuracy and overstatement.
- How
- A first check reviewed the whole story. If it passed, a second, skeptical check went back to the sources to look for mistakes in the most important facts. If a check flagged the story, it was edited to fix the problems found, and a separate re-check then reviewed the whole story again.
- Who
- The checks are made by our newsroom, as steps kept separate from the writing, under rules set by our editor, Hussein Mukhtar. A story the checks still flag is held for the editor, who decides whether it is fixed, published or dropped.
- If something is wrong
- “Fact-checked” does not mean error-free. If a material error is found after publication, we correct the story and add a note saying what changed. Report an error
