While humans can make mistakes, AI agents can make the same mistakes thousands of times faster. CIOs need to understand who is liable when those mistakes cause real-world harm. 

In July 2026, OpenAI models escaped a controlled testing environment and hacked into another company's systems. While the incident involved a frontier lab testing its models, it raises broader questions for enterprise CIOs deploying AI systems of their own. As organizations grant AI agents access to critical systems and customer interactions, they must consider who is liable when those systems cause harm and how to reduce that risk. 

The incident is unlikely to be the last of its kind. In fact, just weeks later, Anthropic and Meta disclosed similar cases in which their models accessed external systems during testing.  

Organizations -- both AI frontier labs and regular enterprises -- are adopting AI faster than they are building the engineering practices and oversight needed to manage it. That approach worries some CIOs, who believe many organizations are prioritizing speed over governance. 

"There's a volcano about to go off, and a lot of the AI that's been implemented by a lot of different companies is going to have to get ripped back up because it's not going to meet any kind of security controls," said Doug Gilbert, CIO and chief digital officer at Sutherland, a global digital transformation consulting firm. 

To avoid ending up in the headlines -- or in a courtroom -- for some kind of AI incident, CIOs need to vet vendors, understand contracts, review insurance coverage, limit what AI systems can access, test models before deployment and continuously monitor them after they go live.  

The OpenAI and Hugging Face incident 

The incident occurred during a controlled cybersecurity evaluation conducted by OpenAI. The test measured how well OpenAI models could perform offensive security tasks, including finding and exploiting vulnerabilities. 

To run the test, OpenAI removed some of the safety controls that normally prevent models from responding to high-risk cybersecurity requests. During the evaluation, the models exploited a previously unknown vulnerability, known as a zero-day, in a third-party software component. They then used that access to move beyond the intended testing environment and access Hugging Face's systems. 

"It was an air-gapped network, and it was able to somehow escape through a proxy that somebody messed up, then harvest credentials and get in using a zero-day exploit that nobody was aware of. That is like science fiction-level stuff right there," Gilbert said. 

The failure was engineering, not rogue AI 

OpenAI's most advanced models, along with other frontier models like Claude Mythos, have become incredibly capable. These systems can find previously unknown vulnerabilities and take actions that surprise even experienced security professionals. However, experts believe the takeaway from this incident is that OpenAI failed to follow sound engineering practices during the test -- not that AI simply went rogue.  

They put it in a contained environment to see whether it could break out … and then, what? They walked away and had lunch?

"The truth is, OpenAI was testing whether a particular LLM could identify cybersecurity vulnerabilities. Great, they should absolutely do that. They put it in a contained environment to see whether it could break out. Excellent. That's a great idea. And then, what? They walked away and had lunch and let it do whatever it wanted?" said Suresh Venkatasubramanian, co-chair of ACM's USTPC AI & Algorithms Subcommittee and professor at Brown University. 

Chalking up the incident to mere rogue AI shifts attention away from the people and processes responsible for building and testing these systems. For CIOs, the more useful lesson is that increasingly capable AI requires stronger engineering practices, continuous monitoring and better containment.  

"In any other industry, if the tools you're building cause problems like this, you don't say, 'Whoa, our tools are alive, and they did weird stuff. Isn't that cool?' It's more like, 'Oh, we made a bad mistake, and we should be ashamed of ourselves,'" Venkatasubramanian said.  

Is there a marketing angle? 

Publicizing AI security incidents can serve legitimate purposes. Companies may disclose these events to promote transparency, warn the industry about emerging risks and demonstrate the importance of AI safety work. However, these disclosures can also generate significant attention for the companies involved. 

Many observers across social media questioned whether OpenAI's public disclosure was, at least in part, a marketing exercise. Dramatic demonstrations of AI capabilities generate headlines, and highlighting a model that can exploit a zero-day vulnerability reinforces the narrative that frontier models are becoming increasingly capable. 

"I agree that they are using it to drum up attention," said Valence Howden, advisory fellow and distinguished analyst at Info-Tech Research Group. 

Who's liable when AI systems cause harm? 

Even if parts of this incident are being hyped for marketing purposes, the risks posed by autonomous AI systems are still very real for enterprises deploying the technology. CIOs must know who could be held liable when their AI systems cause damage to another party. 

Liability will likely depend on who built the system, who deployed it and what controls were in place. CIOs should not assume their AI vendor will automatically bear responsibility. Organizations using AI systems can be held accountable for how they configure, govern and monitor those systems. 

"The liability always comes down into the company that's actually implementing the AI or the end user of the AI, and usually then it falls back into what kind of controls, governance mechanisms and accuracy rates are in place to govern or protect the company," Gilbert said.  

In the case of OpenAI and Hugging Face, the companies have publicly treated the incident as a collaborative security matter rather than a dispute, said Katie Nadro, partner at Levenfeld Pearlstein, a Chicago-based business law firm. However, there could be questions about responsibility if one party wanted to pursue them. 

"Were [Hugging Face] so inclined, there might be some case for some form of liability," Nadro said. 

AI regulation will involve old and new laws 

Despite growing calls for AI-specific regulation, many legal questions surrounding AI systems will likely be evaluated through existing legal frameworks. Lawyers and regulators are applying established areas of law, including negligence, product liability, consumer protection and data privacy laws, to new AI-related scenarios. 

Negligence is always a winner.

"If you talk to lawyers or regulators in the space, they're using existing law to evaluate these kinds of risks. You're talking about product liability law, consumer protection laws, data privacy and security laws. Negligence is always a winner," Nadro said. 

However, existing laws may not address every risk associated with increasingly capable AI systems. New regulations could be needed for frontier AI systems, particularly around safety requirements and accountability measures, Nadro said. 

The result will likely be a combination of new AI rules and existing legal theories being applied to emerging technologies. Nadro compared the approach to privacy regulation, where new technologies have been addressed through existing laws while lawmakers also created new rules governing how companies handle personal data. 

6 steps CIOs can take to reduce AI liability exposure 

CIOs cannot eliminate every risk associated with AI systems, but they can take steps to reduce their exposure. Those steps begin before deployment and continue throughout the system's life. 

1. Vet AI vendors and understand contracts 

CIOs should not assume an AI vendor will automatically take responsibility if an AI system causes damage. Contracts between an organization and its AI providers can determine where liability falls. Before deploying AI systems, CIOs should review terms around liability limits, indemnification and each party's responsibilities if something goes wrong. 

AI providers and customers may both face liability after an incident. Contract terms can determine whether an organization can recover damages from a provider or whether it must absorb the costs itself. Liability limits and indemnification provisions can significantly shape that outcome. 

"If you are bound by your existing liability limits or indemnification provisions, which foreclose that area to recover, then you could be left with significant exposure for the CIO's company itself," Nadro said. 

2. Don't assume insurance covers AI failures 

AI-related risks are creating new questions around insurance coverage. CIOs should not assume that existing cyber liability policies automatically cover losses associated with AI systems, especially as insurers adapt their policies to address emerging risks. Organizations should review their coverage with insurers and legal teams to determine whether AI-related incidents are covered and identify any gaps. 

"Even if you have something like cyber liability insurance, that is also rapidly changing right now to account for AI incidents, and so you might not have the amount of coverage -- or even any coverage -- for this particular scenario," Nadro said. 

3. Give agents only the access they need 

AI agents can pose new security risks when organizations grant them more access than necessary. CIOs should define what data and systems an agent requires for a specific task and limit permissions accordingly. 

"You can find yourself in trouble if you're just opening it up and letting agents have access to more data than it needs," said Eric Johnson, CIO at PagerDuty, a digital operations management and incident response software company. 

Organizations should approach agent access the same way they manage employee permissions.  

"If this were a human, and they were doing this job, what data access should they have? Why should it be any different?," Johnson said. 

4. Build AI on reliable data 

AI systems can only produce reliable results if they are built on quality data. Before deploying AI, organizations should evaluate the data they use to train and fine-tune models and look for bias that could affect outputs. 

"We'll leverage things like AI Fairness 360 to remove bias from the data," Gilbert said. 

5. Test AI performance before scaling 

Organizations should not assume AI models are ready for production out of the box. Before deploying AI at scale, CIOs should test systems for accuracy and reliability and continue refining them until they consistently produce acceptable results. 

"We will ensure we get an accurate outcome and keep training the model to get accurate outcomes until we're satisfied. Typically, we go to about 97 or 98% [accuracy] before we release it to production," Gilbert said. 

6. Monitor AI systems after deployment 

Deploying an AI system is not the end of the process. CIOs should continuously monitor AI systems to understand how models make decisions, identify unexpected behavior and investigate problems if something goes wrong. 

"Not having observability in place is risky. How did they make the decision? What data did they make the decision on? What actions has it taken? Not being able to do the forensics on it is nerve-wracking," Gilbert said. 

Organizations can also establish expected operating thresholds for AI agents and automatically flag behavior that falls outside those parameters for further review. 

"If one of the agents starts to do something outside of a tolerance you expected, then you need the ability to flag that there's something wrong," Johnson said. 

Tim Murphy is a site editor and writer for the IT Strategy team at TechTarget.