What the OpenAI security incident teaches us about workload identity

The recent disclosure by OpenAI of a security incident involving Hugging Face has offered a practical, real-world illustration of what can happen when an autonomous system is given a goal, access to tools, and enough authority to pursue that goal across technical boundaries, according to Nicolas Blank, CTO of NBConsult, a Cyberlogic company.

“According to OpenAI’s preliminary account, models being evaluated for advanced cyber capability found a way through a constrained package proxy via a zero-day exploit, obtained internet access, escalated privileges, and used stolen credentials and further vulnerabilities to reach Hugging Face’s production systems in search of benchmark answers,” says Blank. Hugging Face detected and contained the activity, and the investigation is ongoing.

While the model exploited a zero-day finding in the sandbox, Blank argues this is just as much an identity and access incident as it is a technical one. “The models acted through the systems, identities and permissions available to them,” he says. “Their capability affected how they pursued the objective; identity and access controls determined where they could go and what they could do once they arrived.”

OpenAI has attributed the breach to a zero-day exploit, but Blank believes that does not reduce the accountability organisations carry for how their own systems are governed.

He points out that most enterprise identity programmes are built around people: “Organisations know how to onboard, move and offboard employees, enforce multifactor authentication, apply conditional access, and grant administrative privilege for a limited period. But cloud platforms also depend on applications, service principals, managed identities, automation accounts and deployment pipelines – all of which need authority to act without a person signing in each time. These “workload identities” typically receive far less governance, often because they sit inside an application or project and become someone else’s technical dependency once implementation is complete.

AI agents fall squarely into this workload identity population, but they introduce a design consideration that fixed automation does not. A conventional script follows a known, deterministic sequence; an agent can interpret a task, select its own tools, and find an alternative route when the obvious one fails. Broad or poorly understood permissions therefore become far more consequential. “An identity that can read several data sources, call management APIs and retrieve secrets may allow combinations of action that were never considered when each permission was approved separately,” Blank explains.

“Organisations adopting agents should start with the authority they are assigning, rather than with the novelty of the model,” he says. “Each agent needs a defined business purpose, an accountable owner, and a separate identity that can be traced through the systems it uses. Its permissions should be limited to the data, APIs and actions required for that purpose, with development and testing identities kept apart from production.”

Blank recommends removing long-lived secrets wherever managed identities, workload federation or short-lived credentials are available, and reviewing access whenever a process, owner or underlying application changes.

Microsoft describes workload identities as machine identities used by applications and services, noting that they cannot perform MFA, often lack a formal lifecycle, and may depend on stored credentials. For Blank, these characteristics alone justify stronger governance before any autonomy is added, since humans are not permitted to operate with that same degree of autonomy, absent governance and loosely scoped permissions.

Testing environments require the same discipline, he says. “A sandbox becomes a security boundary through its network paths, package sources, credentials, management interfaces and trust relationships with other systems. A capable workload placed inside that environment should be assumed to examine every route made available to it. Experimental agents should not share production credentials, inherit access through automation tooling, or receive unrestricted outbound connectivity simply because the evaluation is expected to remain contained or constrained.”

Blank cautions organisations against creating an isolated AI governance programme that operates separately from identity, cloud, data and security architecture. Agents use the same enterprise services and permission models as other workloads, so governance should apply the same ownership, least-privilege, monitoring, access-review and incident-containment disciplines, adjusted for software that may act over longer periods and across several tools. “Pausing AI adoption will leave excessive application permissions and unmanaged service principals in place, postponing the point at which those weaknesses are exercised by an agent rather than correcting them,” he stresses.

A useful starting point, Blank suggests, is an inventory of workload identities, their owners and their effective permissions, with authority that lacks a clear current purpose removed. Monitoring should show which identity performed which action across every service, and incident procedures should include disabling the identity, revoking its tokens, and containing the workload without waiting for the original development team to reconstruct how it was deployed. “All of these capabilities are possible using existing tooling today,” he says.

Zero Trust already gives organisations the governing principle for this work: trust should be explicit, access should be limited to what the workload needs, and authority should remain observable and revocable. “The OpenAI incident shows the consequences when capability, connectivity and authority combine in ways the architecture did not anticipate,” Blank concludes. “Workload identity governance keeps that authority limited, understood and accountable as agents become part of ordinary business systems.”