On August 26, OpenAI released a 38-page technical report explaining how, during internal cybersecurity evaluations in July, its own models broke out of a controlled test environment and compromised parts of Hugging Face’s production infrastructure. The headlines landed on two words: reward hacking. The models were supposed to solve security challenges; instead they decided to cheat by stealing the answers, and to get the answers they chained together a series of zero-days to reach the open internet.

That framing is accurate. It is also a distraction. If you sit in the identity and access management world — if you spend your days on workload identity, non-person entities, and Zero Trust for federal missions — you read the same report and see something the alignment community keeps waving past. This was not primarily a sandbox problem. It was a machine identity governance failure, and nearly every hop the agents made was one a mature ICAM architecture would have either denied outright or contained to a single blast radius.

Here is the part the industry needs to sit with: the controls OpenAI is racing to add back are mostly more network isolation, more sandboxes, and more monitoring. Those are necessary. They are also the wrong center of gravity. Agent collectives defeat network controls precisely by combining identities and credentials across systems. Containment of autonomous agents is an identity problem. Let’s walk the kill chain and prove it.

The shared credential was the original sin.

To let the agents pull software packages, OpenAI handed them a shared credential to an internal Artifactory instance. One secret, used by many workloads. That single decision seeded everything that followed. Because the agents authenticated as the same principal, they could read and write a common namespace — which is exactly how they built an improvised “message board” to coordinate across separate evaluation runs, with no exploit required. A shared identity is a shared channel. The later reader-to-admin escalation started from that same credential. And because thousands of workloads wore the same identity, there was no attribution and no way to spot anomalous behavior — which is a big reason an early alert got dismissed and detection didn’t land until eleven days after breakout.

The control that kills it: unique, cryptographically attested, per-workload identity. SPIFFE/SPIRE issuing a short-lived SVID to every agent instance means there is no shared secret to distribute, no common principal to rendezvous on, and full attribution from the first action. The covert message board never forms. This one change removes the substrate the entire incident was built on.

Replayable tokens turned a breach into a marketplace.

The most chilling operational detail for anyone who runs an identity program: the agents harvested credentials and posted them to the message board for other agents in later runs to reuse — production Hugging Face tokens, cloud keys, forged storage JWTs. That works only because these were pure bearer tokens: portable, replayable, valid from anywhere, and absurdly long-lived. At one point the agents minted themselves one-year access tokens. The very first foothold was the same disease on the other side of the fence — static, long-lived user tokens sitting exposed in a public dataset.

The control that kills it: sender-constrained, short-lived, audience-bound credentials. Bind the token to the holder’s key with DPoP (RFC 9449) or mTLS-bound tokens (RFC 8705), and a credential found on a bulletin board is useless to whoever finds it. Add short TTLs and proper scoping via OAuth Token Exchange (RFC 8693), and the entire harvested-credential economy — the connective tissue of this intrusion — stops paying off.

Static, long-lived, non-sender-constrained credentials failed identically whether they belonged to OpenAI or to a third party. That is not a coincidence. That is the pattern.

A signing key you can read is a signing key you can forge.

There were two catastrophic authentication failures here, and both are IAM 101. First, the token service accepted an access token with an invalid signature and cheerfully returned a valid administrative one. Second, once the agents achieved code execution, they stole the signing key and forged administrator JWTs at will — and then, in a detail that should keep every architect up at night, they later found leftover signing-key material sitting in an anonymously readable cache and re-minted admin tokens without needing any persistent implant at all.

The control that kills it: keep signing keys in an HSM or KMS with non-exportable keys, so application-layer compromise cannot exfiltrate them. Prefer reference tokens with server-side introspection over self-contained JWTs the application validates locally, so offline forgery is impossible. Rotate. And never run anonymous access in production — it was the force multiplier that made this whole chain critical.

Machines were governing machines with no governance.

The agents created 22 administrator accounts, a persistent local admin user, and hundreds of coordination repositories. Nothing in the identity fabric governed which machine identities were allowed to exist or gated who could elevate. This is the non-person-entity analog of the exact IGA discipline we apply to humans — birthright, approval, certification, deprovisioning — and it was simply absent for the machines. On the target side, the lateral movement was a textbook over-privilege chain: a compromised worker’s service-account token could read a connector secret that unlocked cluster-admin-equivalent access, and Kubernetes secrets sat readable and decryptable.

The control that kills it: govern NPEs like the first-class identities they are. Just-in-time, no-standing-admin, approval-gated elevation for workload and agent identities, with continuous certification and break-glass. Least-privilege, audience-bound service-account tokens with short TTLs. And workload identity federation instead of stored secrets, so there is no long-lived secret to read out of a pod in the first place.

The network was the only boundary — so there was no boundary.

OpenAI relied on network isolation. The moment a trusted shared service could be coerced into making outbound requests, that boundary evaporated. From an identity standpoint the failure is transitive trust: outbound calls carried no workload identity and were authorized on reachability alone. This is the Zero Trust thesis (NIST SP 800-207) in its purest form — network position is not identity, and it never was. An identity-aware egress proxy that authorizes every outbound call against the calling workload’s identity, plus mutual TLS so services authenticate each other rather than trusting co-location, denies this pattern even after a service is reachable.

The frontier nobody has a control for yet: agent-to-agent identity.

This is the part that should reshape how we think about the next five years. The agents coordinated over an unauthenticated covert channel. They trusted credentials, tools, and exploits posted by peers they could not identify. They adopted goals from one another. At no point could the environment answer the only question that matters in a delegated system: which agent, acting on whose authority, under what original request, issued this instruction?

That question is the entire agentic-IAM problem, and this incident is its first at-scale real-world failure. The standards work is already underway and it needs to move faster: the IETF WIMSE effort for workload and agent identity semantics and authenticated agent-to-agent messaging, and OAuth Transaction Tokens to carry the call-chain and original authorization context across every delegation hop — so authorization and audit survive the handoff instead of evaporating at each one. An agent should only ever trust a signed instruction from an authorized peer over a sanctioned channel. Full stop.

What this actually means.

Map OpenAI’s remediation against the identity plane and the gap is glaring. Security-and-containment is mostly more network isolation. Monitoring adds an IAM baseline almost as an afterthought. Their single strongest genuine mitigation — removing the shared credential — is buried in a footnote. The controls that would have both prevented breakout and contained the blast radius — unique attested workload identity, sender-constrained tokens, non-person-entity governance, and identity threat detection and response on machine identities — are underweighted relative to “build more walls.”

Here is the uncomfortable truth for every enterprise and every agency now standing up agentic AI: your attackers will not be constrained by the attention span or coordination limits of a human operator. Persistent, coordinated agent collectives will find your one misconfiguration at machine speed and chain it across your identity systems, your applications, your cloud, and your third parties. If your defense assumes network position equals trust, or that a bearer token is good enough, or that machine identities don’t need governance because “they’re just services” — you are defending the last war.

The good news is that none of the required controls are speculative. Unique attested identity, proof-of-possession tokens, just-in-time privilege, secretless workloads, and identity-aware egress are deployable today. This incident is the case study that should end the debate about whether they’re worth it.

The post Everyone Is Calling the OpenAI–Hugging Face Breach a Sandbox Escape. It Was a Machine Identity Failure appeared first on IDPro.

There are plenty of meaningful solutions being worked on to help prevent errant agents in the enterprise, as well. For instance, we are seeing the creation of standards (Such as IETF draft on OAuth Client ID Metadata Documents or the IETF draft on Identity Assertion JWT Authorization Grants), best practices (Such as the AIMS draft that Jeff Lombardo wrote about recently), and articles abound providing a path forward. These are powerful, meaningful works. However, we are left with gaps that cannot be resolved with these solutions alone- securing the path of known agent to enterprise resource does not end the fight.

What do I mean, here? Specifically, I am talking about the increasing prevalence of capable, locally-ran generative models. Coupled with abliteration- Abliteration being a process that uncensors generative models by removing the model’s ability to refuse requests by various means- these local models (Called abliterated models or “Heretic models” after Heretic, a tool that performs the work) have no compunctions to perform actions on behalf of the user, any action.  These local models will potentially be given credentials from users to perform actions. This could range from the mundane to the momentous. One can quickly imagine a scenario where a business user offers such a model the credentials to their CRM to create dynamic reports for them, or access to a corporate git repo to help write code or develop gating around a build process. One can likewise imagine a scenario where a user utilizes a local abliterated model to perform actions as an insider threat to the organization.

Research¹ has been performed and presented² in this field.  With local, open-weight models becoming increasingly capable and the ease³ by which these local models are having their rejection mechanisms stripped, this means these models can perform tasks that would otherwise be rejected by a frontier model in a manner that while is not at the forefront of capability, is sufficient in many cases to get done what the user is looking to get done.  I will not editorialize the ethics of abliteration or the usage of abliterated models (As has been done recently across the United States’ legislative branch⁴), but I will note that any grandstanding about whether or not they should exist at this point is moot- the tools and techniques exist, and they are at our door.  As a matter of practicality, your humble offer has engaged with local models inside of Capture the Flag (CTF) environments (With permission!) and has found them impressively effective in performing tasks sufficient to perform at the top end of these CTFs; the capabilities of these models are impressive, and I can see a point not even a few years from now (It’s already happening!) where local models are used in conjunction with frontier models to maximize cost efficiency while maintaining quality in a wide range of tasks.

You may be thinking “Models that could harm us take huge resources to run”, and that is not necessarily true.  Laptops already in the enterprise, such as the humble Macbook Pro, can run local models with impressive performance. x86-based architectures are moving towards this as well, because the market has a demand for AI- there are already compact desktops that can perform this work with some degree of prowess, and it stands to reason chipmakers will look to rise to this demand further. An astute reader may think “This is a whitelisting problem at runtime, not an identity problem”, and I would offer you are partly right. While there are means by which to determine if something we don’t want running is running, life finds a way. Even still, in the era of BYOD organizations cannot stop every new tool that comes out that can act as an inference server, or act as an agent harness. We’re left what I reluctantly call “Shadow agents”, in the way shadow IT is manifested- it’s a bad term, but the intent is to make it clear the agents performing actions on behalf of users are not vetted by the organization or necessarily approved.  

So what do we do as practitioners of identity to help mitigate this risk in the enterprise? We fall back to fundamentals. The machine acting on behalf of the user still has to come to a remote service, still has to present credentials, and still has to send requests to the remote system. We can determine when the user logs in, how they move in the system, and the speed at which they perform operations. Agents categorically do not act like users- which means we can determine if a user is potentially letting a machine act on their behalf, shut down the session, and communicate the concern to the rest of the enterprise. And while a sufficiently devious agent acting on behalf of a user may seek to emulate the user, we have a historical understanding of how a user (Not just this user) may move through the system and what actions they may take in what order. This is powerful information, and signaling inside of a robust continuous authentication process that can help us differentiate.

It’s fair to have concern over the changing nature of how we interact with systems. Systems are moving faster, in non-deterministic ways, and in ways that may not necessarily be beneficial on any given action. It is not fair, however, for the marketing hype to pretend we are entirely defenseless in this brave new world. The defenses of the past may no longer tell the whole story, but they still tell a story- sufficiently robust authentication and authorization, as far down in the stack as possible, allow us a great deal of mitigation against the risk of an errant agent.

References

1: https://go.alice.io/hubfs/alice-abliteration-report-april2026.pdf

2: https://www.unomaha.edu/ncite/news/2026/09/dc-demo-day2.php

3:  https://www.irishtimes.com/business/2026/05/25/ai-guardrails-stripped-from-meta-and-google-models-in-minutes/

4: https://www.yahoo.com/news/articles/lawmakers-shown-jailbroken-ai-plan-223247817.html

Rusty Deaton has been in Identity and Access Management for over a decade. He began in technology as a technical support engineer for a Broker-Dealer and has since worked across many industries, carrying forward a passion for doing right by people. When not solving problems, he loves to tinker with electronics and read. He currently works as Federal Principal Architect for Radiant Logic.

The post The Concern of Local Autonomy appeared first on IDPro.