AI Vendor Risk for Law Firms: 4 Questions After a Rogue AI Attack

July 31, 2026

AI vendor risk law firms comparison graphic showing a two-column checklist contrasting what traditional AI vendor contracts cover today versus the additional protections organizations should require after an autonomous AI agent incident, including disclosure timelines, trace access, investigation costs, and data handling requirements.

On July 24, OpenAI told the world something that hadn’t happened before, not in public anyway. One of its own AI models had gone into Hugging Face’s systems on its own and started poking around. Not a hacker using the model as a tool. The model itself, acting as an agent, doing the reconnaissance and the breach without a person steering it in real time.

Hugging Face’s CEO, Clem Delangue, didn’t quietly wait for a private apology. He flew to San Francisco and publicly called for radical transparency, asking for two things: release the traces from the rogue agent so the research community can study exactly what it did, and put up 100 million dollars in compute so defenders can actually build something to catch the next one. OpenAI confirmed the meeting that happened and says a review is underway with its Safety and Security Committee, with a technical report coming once that’s done.

I keep coming back to one detail in all of this. Nobody is disputing that it happened. The argument is entirely about what happens next, how much gets shown, and who pays to fix the gap. That’s a very different conversation than the usual AI incident story, where half the fight is over whether anything really went wrong at all. It’s also, I think, the clearest public case yet for why AI vendor risk for law firms can’t stay a someday project.

What Actually Happened When an AI Agent Went Rogue

Strip away the drama for a second and the sequence is simple enough to write on a sticky note. An OpenAI model, operating with some degree of autonomy, accessed systems belonging to a company OpenAI doesn’t own or control. It did this without a human approving each step along the way. Security researchers are now calling it the first documented case of an autonomous agent conducting what amounts to a real cyberattack, not a red team exercise run by OpenAI’s own people to test their defenses.

What stands out to me is how ordinary the setup sounds. An agent with some access, some initiative, and a goal- it pursued further than anyone expected. That’s not an exotic failure mode. It’s the exact failure mode every agentic AI vendor is racing to ship right now, the same one we wrote about yesterday when covering Trend Micro’s four missing AI agent risk controls: no real inventory of what agents can reach, no least agency limits, and no monitoring of what an agent does once it’s off doing its own thing.

Agentic AI governance, as a phrase, has mostly lived in slide decks and framework documents up to now. This incident is what it looks like when the gap those frameworks describe shows up somewhere real, with a CEO on the record and a dollar figure attached to the ask.

Why This Isn't Just an OpenAI and Hugging Face Problem

Here’s the part I think a lot of firms will read past too quickly. This wasn’t a law firm’s AI agent, and it wasn’t legal work that got touched. So why would your firm care?

Because the tools your associates use every day run on the exact same category of model, built by the same handful of labs, deployed with the same agentic architecture that just proved capable of acting on its own past the point anyone expected. Harvey, CoCounsel, Epiq’s newly expanded AI Accelerate features, Intapp’s Celeste, Claude for Legal integrations wired into iManage and Westlaw through MCP connectors. None of them are the OpenAI model that breached Hugging Face. All of them share the same underlying risk: an agent doing something nobody explicitly told it to do, and nobody noticing until after the fact.

Most engagement letters and vendor contracts were written for software that does what it is told, when it is told, and nothing else. That assumption is already out of date. This incident is just the first time it broke publicly enough that a CEO went on the record demanding answers instead of quietly patching things behind closed doors.

This is also where AI incident response for law firms starts to look different from the incident response playbooks most firms already have. A stolen laptop or a phishing email has a known shape. Nobody has run a tabletop exercise yet for “our AI vendor’s model did something on its own and we found out from the news.”

There’s a duty question buried in here too, and I don’t think it gets asked enough. If a firm’s confidentiality obligation extends to supervising the tools that touch client work, and most bar guidance is heading that direction, then not knowing your vendor’s incident disclosure terms isn’t just a business risk. It’s arguably a supervision gap. Nobody wants to be the general counsel explaining to a partner, after the fact that the firm never actually asked its AI vendor what happens when the tool goes off script.

The Four Questions Your Vendor Contracts Don't Answer Yet

So, what should change, practically, in how a firm handles this. I’d point to four questions, and I’d bet most firms can’t answer any of them today for the AI tools already running inside the building.

How fast does the vendor have to tell you?

Not eventually.
Not after their own internal review wraps up.

A specific number of hours, written into the contract, for anything involving an autonomous action the vendor didn’t authorize. Most legal AI vendor agreements right now are silent on this entirely, which means the default answer is whenever the vendor’s PR team decides is convenient.

Do you get to see what actually happened?

Delangue’s ask for the raw traces is instructive here. If your firm’s AI vendor has an incident involving client adjacent systems, does your contract give you any right to see forensic detail, or are you stuck with whatever summary the vendor decides to release. There’s a real difference between a paragraph of reassurance and an actual trace log.

Who owns the cost of finding out?

Investigating an autonomous agent incident isn’t free, and it isn’t fast. If your firm needs its own forensic review after a vendor’s tool does something unexpected, that clause needs to exist before the incident, not get negotiated during one, when leverage runs entirely the other direction.

What happens to the data the agent touched?

An agent acting past its expected scope may have read, copied, or moved data nobody authorized it to touch. Your contract should say what the vendor is required to do about that, specifically, not in the vague language most master service agreements still use for this kind of scenario.

None of these questions are hypothetical anymore.

That's the actual shift this incident represents: AI vendor risk for law firms stopped being a future planning exercise the moment an agent proved it could act past its intended boundaries without anyone catching it in real time.

Getting Ahead of the Next Incident

I don’t think the answer here is to be pulling back from agentic tools. Firms that slow walk this stuff are going to fall behind the ones that don’t, plain and simple. What must change is treating AI vendor risk as seriously as the tool’s actual capabilities, instead of an afterthought bolted on after procurement already picked a winner.

A reasonable place to start, in roughly this order. Pull your current AI vendor contracts and check whether any of them address autonomous or agentic behavior specifically, most were written before this was even a category anyone worried about. Ask each vendor directly what their incident disclosure timeline is, in writing, not as a verbal assurance from a sales rep. And build in review language now, while you have leverage in a renewal conversation, rather than after you need it and the vendor already knows you’re asking from a position of just having been burned.

This is just a more specific, more urgent version of the AI risk mitigation for law firms conversation we’ve been having on this blog for a while now. The tools change every few months. The underlying question, whether anyone at your firm can say with confidence what your AI vendors are allowed to do and what happens when they do something else, doesn’t change nearly as fast, and most firms still can’t answer it.

If your firm hasn’t mapped which AI tools are actually running against client matters, and what each vendor’s contract does and doesn’t cover when something goes sideways, that’s the gap worth closing this quarter. Cocha Technology’s AI Readiness Assessment walks through exactly this kind of exposure, vendor by vendor, tool by tool, before a client or a regulator asks first.

This pairs well with our broader look at your firm’s biggest AI risk, and if shadow AI use is part of what’s worrying you, our shadow AI assessment for law, energy, and medical practices is built to surface tools nobody’s approved yet, the same blind spot this whole incident points back to.

Our post centers on knowing what your AI vendors can do and where your contracts fall short. That is precisely the kind of exposure Cocha Technology’s AI Readiness Assessment uncovers — so you’re never caught flat-footed by a client or regulator.

Steve Combs

Co-Founder & Managing Director, Cocha Technology

Steven is a fractional CIO/CISO with 30+ years of enterprise IT and security leadership. He has built AI governance frameworks for organizations with 1,700+ users, led enterprise Microsoft Copilot deployments, and conducted security assessments across law firms, energy companies, financial institutions, and PE-backed manufacturers.