OpenAI’s Hacking Debacle Was a Human Mistake

The age of rogue AI hacker agents has arrived—but it didn’t have to happen this way.

After an OpenAI agent breached the Hugging Face platform earlier this month, the two companies said this week that the hacking spree was more extensive than previously thought and also involved intrusions into multiple third-party accounts and services as part of the attack on Hugging Face. The incident has made waves in the cybersecurity community amid broader discussions about how evolving AI capabilities are changing both offensive hacking and digital defense. But as more information emerges, many researchers have concluded that rather than elucidating AI’s next frontier, the episode simply highlighted long-standing cybersecurity problems that are more consequential than ever in the AI age.

“People are YOLO-ing really hard. It’s shocking how little people have really thought about a scenario like this,” says Alex Zenla, co-founder and chief technology officer of the cloud security firm Edera. “I consider all AI and anything AI touches to be fully untrusted—which is fine, you just need to build against that. And this situation proves the point. The fact that OpenAI wasn’t more paranoid about this seems kind of reckless.”

OpenAI did not provide comment for this story ahead of publication.

The company said in its original disclosure about the Hugging Face hack that one of the two models that broke containment and made its way to the open internet for days was an experimental prototype that was never meant for release. OpenAI also noted that the situation occurred partly because “deployment safeguards were intentionally not enabled” on both the models for testing purposes. “This incident points to the need to further strengthen our model’s alignment, cyber protections during evaluation time, and monitoring during internal testing,” the company wrote.

OpenAI also said in an update this week that, following the Hugging Face breach, it “deactivated, encrypted, and restricted [the unreleased model] from research access.” Though there is always room for improvement on security posture at any company, OpenAI’s existing safeguards alone may have prevented or minimized the incident if they had been in place.

“A simple analysis of the actual risk has an actual simple answer,” says longtime security and compliance consultant Davi Ottenheimer. “The OpenAI mistakes were dead simple.”

Multiple sources emphasized to WIRED that OpenAI’s models also seem to have escaped containment because of lapses in implementing foundational security best practices—including “zero trust” and “defense in depth”—that imbue digital systems with layers of protections and failsafes to minimize damage when something does go wrong. While there’s no such thing as perfect security, researchers and practitioners have spent the past two decades developing and promoting defensive strategies that have proved durable but require consistent investment of time and money to implement.

It can be difficult for small businesses, poorly funded public interest groups, or fledgling organizations to devote the resources to prioritizing investment in foundational security. But with an $850 billion valuation and veteran hires from across the tech industry, OpenAI is not at a disadvantage on implementing security best practices.

The foundational protections that may have prevented the company’s models going on a hacking spree are well known within the industry. Speaking about Chrome vulnerability discovery on Wednesday, before news of OpenAI models’ additional breaches had come to light, Chrome director of engineering Doug Turner told WIRED that AI-driven bug hunting and remediation requires a pipeline that’s built “with serious guardrails in mind.”

For internal AI services that evaluate Chrome, “everything runs in a container, it’s all isolated from the internet. Any outward-bound network activity for a bug tracking system is highly regulated, and we are monitoring for suspicious activity,” Turner says. “This is a must-have thing when you’re doing this type of work, because we want to make sure that models can’t execute system commands or they can’t establish egress outside of the sandbox. And we hope that others will take a similar approach.”