OpenAI’s research agent spent a week inside Hugging Face’s systems before anyone noticed. The agent was designed to autonomously browse repositories, read code, and test models. It worked exactly as intended. The problem wasn’t a bug. The agent had too much access, and no one was watching what it did with that access.

For law firms deploying AI agents to handle document review, legal research, or client intake, this breach is a warning shot. Your agents will do what you tell them to do. They’ll open files, query databases, and pull information from connected systems. If you haven’t audited what those systems are, or built monitoring around what the agent touches, you won’t know when something goes wrong until a client calls asking why their privileged communication showed up in a vendor’s support ticket.

The firms I work with are already running agents for first-pass contract review, matter triage, and after-hours intake. The efficiency gain is real. One mid-sized litigation practice cut 18 hours per week of associate time on discovery review. But the same partner who signed off on that deployment had no visibility into which cloud storage buckets the agent could read, or whether it logged every document it touched. That’s the gap this article addresses.

What Happened in the OpenAI Breach

OpenAI’s research agent was built to explore machine learning models hosted on Hugging Face. It navigated the platform autonomously, tested code, and documented findings. For a week, it operated without triggering any alerts. The breach wasn’t malicious. The agent was doing research. But it accessed internal repositories, read private model weights, and moved through systems that should have been segmented.

The takeaway isn’t that AI agents are inherently unsafe. It’s that autonomy without boundaries creates exposure. The agent had credentials, it had a task, and it had no one checking its work in real time. Law firms deploying similar agents for legal research, document summarisation, or client communication face the same risk profile. Your agent might pull a confidential memo, attach it to an email summary, and route it to a paralegal’s personal inbox because that’s where the workflow pointed.

Client data in a law firm isn’t just sensitive. It’s privileged. A breach doesn’t need to be malicious to destroy a client relationship or trigger a bar complaint. If your Document Review Agent can access every matter file in your DMS, and it’s also connected to a third-party transcription service for deposition summaries, you’ve created a path for privileged material to leave your control. The agent won’t know the difference between a public filing and a sealed settlement agreement unless you’ve taught it that distinction and built guardrails around what it can touch.

The Manual Work Law Firms Are Automating

Most firms deploying AI agents start with three workflows: intake, document review, and matter triage. These are high-volume, time-sensitive, and expensive when handled manually. They’re also the workflows most likely to connect an agent to multiple systems without anyone mapping the access chain.

Intake is the obvious starting point. A potential client calls at 7 p.m. No one picks up. They leave a voicemail, or they don’t. By morning, they’ve called two other firms. The Intake Voice Agent we build for firms answers every call, asks conflict-check questions, captures the matter details, and books a consultation. It’s connected to your calendar, your CRM, and often your billing system to check for existing client records. That’s three systems with different permission models. If the agent can read your entire client list to run a conflict check, it can also pull that list into a summary email or a training log.

Document review is where the efficiency gain gets serious. A junior associate bills $250 per hour to read through discovery documents, flag relevant clauses, and summarise positions. It takes days. A Document Review Agent does the first pass in hours, produces a memo, and routes it to the associate for final review. The associate bills two hours instead of twenty. But that agent is reading contracts, emails, depositions, and internal memos. If it’s connected to your document management system without read restrictions, it can access every file in every matter. If it’s logging those reads to an external analytics platform to improve its accuracy, you’ve just created a data flow you probably didn’t document in your client engagement letters.

Matter triage is the third common use case. Form submissions and emails come in, and someone has to decide whether it’s a good fit, which practice area it belongs to, and who should take the call. A Matter Triage Agent reads the submission, scores it against your intake criteria, classifies the practice area, and routes it to the right partner with a brief attached. It’s pulling data from your CRM, your email, and sometimes your billing history to check whether the lead has contacted you before. That’s another access chain that spans multiple systems, and most firms don’t have logging that shows what the agent read to make its decision.

These workflows save real time. We typically see 4 to 6 hours per attorney per week recovered from intake and admin work that never made it onto a billable invoice. But every hour saved is an hour the agent spent reading, writing, and moving data between systems. If you haven’t audited what those systems are, you’re running blind.

What an AI Agent Can Access Without You Knowing

The risk isn’t that your agent will go rogue. The risk is that it will do exactly what you told it to do, using access you forgot you gave it. Most firms deploy agents by connecting them to existing tools: the DMS, the CRM, the calendar, the email server, and maybe a cloud storage bucket where scanned documents live. Each connection requires credentials. Those credentials carry permissions. And permissions in most law firm systems are set to “if you’re logged in, you can read everything.”

Your Document Review Agent needs to read contracts. So you give it access to the contracts folder. But that folder lives in a document management system where folder permissions inherit from the parent. The agent can now read every subfolder, every matter file, and every scanned exhibit. It’s not trying to. It’s just following the path you gave it.

Your Intake Voice Agent needs to check for conflicts. So you connect it to your CRM. The CRM API doesn’t have row-level security. The agent can read every client record, every contact note, and every billing entry. It only needs to check names, but the access level you granted doesn’t distinguish between “read names” and “read everything.”

Your Matter Triage Agent needs to pull the last five emails from a lead. So you give it access to the firm’s email server via an integration. That integration uses a service account with mailbox access to every attorney’s inbox. The agent only queries the intake mailbox, but the credentials let it read every email in the firm if it wanted to. It won’t want to, but the access is there.

This is how breaches happen. Not because the agent is malicious, but because the access model assumes humans are using the system. Humans have judgment. They know not to open the sealed file. They know not to forward the privileged memo. Agents don’t have that context unless you’ve built it into the workflow, and most firms haven’t.

What Monitoring Looks Like for AI Agents

Monitoring isn’t about watching the agent work in real time. It’s about building a log of what the agent touched, when, and why. If something goes wrong, you need to be able to answer three questions: what did the agent read, where did that data go, and who can see it now.

The firms we work with implement three layers of monitoring. First, access logging. Every time the agent reads a file, queries a database, or pulls a record, that action gets logged with a timestamp, the file name, and the agent’s task ID. This log lives in a separate system from the agent itself, so the agent can’t modify it. If a client asks whether their settlement agreement was accessed by an AI tool, you can pull the log and show exactly when and why.

Second, output tracking. Every summary, memo, or email the agent generates gets tagged with the source documents it used. If the agent writes a case brief, the brief includes a metadata footer listing every file it read to produce that brief. This isn’t visible to the end user, but it’s there in the audit trail. If a privileged document ends up in a summary that shouldn’t have included it, you can trace back to the moment the agent pulled that document and figure out why the access control didn’t stop it.

Third, anomaly detection. This is the layer that catches the Hugging Face scenario. If your Document Review Agent suddenly reads 400 files in an hour when it normally reads 40, that’s a flag. If your Intake Voice Agent starts querying client records outside of active call windows, that’s a flag. These aren’t necessarily breaches. They might be legitimate spikes in activity. But they’re worth investigating before they turn into something worse.

Most firms don’t have any of this in place when they deploy their first agent. They assume the vendor handles it, or they assume the agent is “safe” because it’s running in their own environment. Neither assumption is true. The vendor built the agent to complete tasks. Monitoring is your job, and it requires infrastructure most law firms don’t have in their IT stack. That’s where the AI audit for law firms starts: mapping what systems your agents can touch, what permissions they’re using, and what logs exist today.

The Cost of Getting This Wrong

A data breach in a law firm isn’t just a regulatory issue. It’s a client relationship issue, a malpractice exposure, and in some jurisdictions, a bar complaint. The dollar cost is hard to estimate because most breaches don’t get reported publicly, but the firms I’ve worked with after an incident typically spend $80K to $250K on forensic analysis, client notification, and remediation. That’s before any settlement or malpractice claim.

The reputational cost is worse. One firm lost three major clients after a vendor breach exposed case strategy memos. The breach wasn’t the firm’s fault. The vendor’s system was compromised, and the firm’s data was collateral damage. But the clients didn’t care whose fault it was. They cared that their privileged communications were no longer privileged, and they moved their business to a firm that could demonstrate better data controls.

AI agents add a new vector because the exposure isn’t always obvious. A traditional breach involves an attacker exfiltrating files. An agent breach might involve the agent summarising privileged material in an email, attaching a confidential document to a workflow task, or logging sensitive data to an external analytics platform. The data didn’t leave your environment in a way that triggers a firewall alert, but it’s still exposed.

The firms that avoid this outcome are the ones that treat agent deployment like a security project, not just an efficiency project. They map access before they turn the agent on. They build logging into the workflow from day one. And they run a quarterly audit to check whether the agent’s permissions still match its task scope. This isn’t expensive or complicated, but it requires someone to own the question. In most firms, no one does until something breaks.

What an Omni Audit Covers for Law Firms

When a firm asks us to audit their AI agent deployment, we’re looking at three things: access, monitoring, and containment. The audit takes 60 minutes, and you walk out with three outputs: an access map, a risk score, and a remediation checklist.

The access map shows every system your agent can touch, the permission level it’s using, and the data types it can read. We’ve found agents with read access to HR files, billing records, and sealed case documents because the folder structure didn’t distinguish between public and privileged. The map makes that visible. It’s not a blame exercise. It’s a snapshot of what’s connected today, so you can decide what should stay connected and what needs to be segmented.

The risk score is a single number that reflects how much exposure you’re carrying. It’s based on the number of systems the agent can access, the sensitivity of the data in those systems, and the logging infrastructure you have in place. A score of 7 or higher means you’re carrying material risk that a client would care about. A score of 4 or lower means you’ve got the basics covered. Most firms score between 5 and 8 on their first audit.

The remediation checklist is the action plan. It’s a prioritised list of changes, ranked by impact and effort. The top three items are usually quick fixes: tighten a permission, add a log, or segment a folder. The next five are infrastructure projects that take a few weeks: build an audit trail, set up anomaly detection, or migrate the agent to a least-privilege service account. The last few are strategic: renegotiate a vendor contract, update your client engagement letters, or build a policy around what agents can and can’t access.

We also walk through your existing workflows and show you where an agent could add value without adding risk. Most firms are underusing the agents they’ve already deployed because they’re not sure what’s safe to automate. The audit gives you the confidence to expand. See Omni for law firms to book your session.

If you’re still in the planning phase and want a practical checklist to guide your intake workflow, we’ve built a worksheet that covers conflict checks, data capture, and system integration. You can grab the AI Client Intake Checklist for Law Firms and use it to map out your first deployment before you connect anything.

How to Deploy Agents Without Creating Exposure

The firms that deploy agents successfully start with a narrow scope and expand once they’ve proven the monitoring works. They don’t connect the agent to every system on day one. They pick one workflow, one data source, and one output. They run it for a month, review the logs, and then add the next connection.

For intake, that means starting with the Intake Voice Agent connected only to your calendar and a blank CRM record. The agent captures the call, books the consultation, and writes the details into a new record. It doesn’t read your existing client list. It doesn’t check billing history. It doesn’t pull case files. You add those connections later, after you’ve confirmed the agent is logging every action and the logs are readable.

For document review, that means starting with a single matter and a single document type. The Document Review Agent reads contracts in one folder, produces a memo, and saves it to a review queue. It doesn’t touch discovery files. It doesn’t read emails. It doesn’t access the DMS root. You expand the scope after you’ve tested the output quality and confirmed the agent isn’t pulling documents it shouldn’t.

For matter triage, that means starting with form submissions only. The Matter Triage Agent reads the web form, scores the lead, and routes it to a partner. It doesn’t read email. It doesn’t query the CRM. It doesn’t check billing records. You add those integrations once you’ve built confidence in the scoring logic and the routing rules.

This phased approach takes longer, but it’s the only way to catch access issues before they become exposure issues. Every connection you add is a new path for data to move. If you add ten connections at once, and something goes wrong, you won’t know which connection caused the problem. If you add one connection per month, and you’re reviewing logs between each addition, you’ll catch the issue before it compounds.

The other advantage of a phased approach is that it gives your team time to learn how the agent works. The first time an associate sees an AI-generated case brief, they’re going to read it carefully and check every citation. By the tenth brief, they’re skimming. That’s fine if the agent is accurate, but it’s a problem if the agent occasionally hallucinates a case or misreads a clause. Phased deployment keeps the review rigor high while the team builds trust. You can read more about how we think about agent workflows on the Omni Ops page and the Omni Voice page.

What Happens Next

The OpenAI breach at Hugging Face wasn’t a failure of AI. It was a failure of access control and monitoring. The agent did what it was designed to do. No one was watching what it accessed, and no one noticed when it stayed active longer than expected. Law firms deploying AI agents face the same risk, with higher stakes. Your agents will read privileged communications, pull client data, and generate summaries that might include material you didn’t intend to share. If you haven’t audited what systems those agents can access, and you haven’t built logging around what they do, you’re carrying exposure you can’t measure.

The fix isn’t complicated. Map your access, build your logs, and review your permissions quarterly. Start with a narrow scope and expand as you prove the monitoring works. Treat agent deployment like a security project, not just an efficiency project. And if you’re not sure where to start, book a 60-min Omni Audit and we’ll walk through your current setup together.

Most firms wait until after an incident to take this seriously. The firms that win are the ones that build the guardrails before they need them. You’ve got the tools. You’ve got the workflows. Now build the monitoring that makes those tools safe to use at scale. If you want to explore how other firms are thinking about AI deployment, the insights section and the guides library have case studies and frameworks you can adapt to your own practice.