The OpenAI-Hugging Face incident in January made something clear: the API key that let an agent wander into someone else’s infrastructure wasn’t exotic. It was a standard, over-scoped credential sitting in a production environment. The agent didn’t need that level of access to do its job. It had it anyway.

If you’re running a law firm and you’ve deployed an AI agent—intake voice, document review, matter triage—you need to ask the same question about your own systems. What can that agent actually touch? What credentials does it hold? And if it exceeds the scope you intended, who carries the liability?

The Computer Fraud and Abuse Act doesn’t care whether the agent “meant” to access something. It cares whether the access was authorized. If your agent holds an admin-level API key to your practice management system and it pulls client data it wasn’t supposed to see, you’ve got a problem. If it writes to a database it should only read, you’ve got a bigger one.

This isn’t theoretical. Firms are deploying agents right now without a clear map of what those agents can reach. The credential scope issue is sitting in your environment today, and most firms won’t know until something breaks or a client asks the wrong question during a data breach deposition.

The credential problem most firms don’t see

When you set up an AI agent to handle intake calls or review documents, someone on your team—or the vendor—provisions access. That usually means an API key, a service account, or a set of system permissions. The question is: does that credential give the agent exactly what it needs, or does it give the agent everything?

In most cases, it’s the latter. The path of least resistance is to hand over admin-level access and move on. It works. The agent can read your matter files, write notes, update client records, pull billing data. No one complains until the agent does something it wasn’t supposed to do.

Here’s what that looks like in a typical mid-sized firm. You deploy an intake voice agent to answer after-hours calls. It needs to check for conflicts, log the caller’s details, and book a consultation. To do that, it gets access to your practice management system. But the API key you provisioned doesn’t just cover conflicts and calendar—it covers everything. Client trust accounts. Billing history. Opposing counsel notes. The agent doesn’t need any of that, but it can reach it.

Now imagine the agent encounters a caller who shares a name with an existing client. The conflict-check logic misfires. The agent pulls the wrong file, logs details into the wrong matter, and writes a note that references privileged information. You don’t find out until the client calls three weeks later asking why their intake form mentions a case they never discussed.

That’s a scope problem. The agent exceeded its authorization not because it was malicious, but because the credential let it. And under the CFAA, “exceeds authorized access” is enough.

What the CFAA means for firms deploying agents

The Computer Fraud and Abuse Act was written in 1986 to prosecute hackers. It’s been stretched to cover a lot more since then, including employees and contractors who access systems beyond their permission. The key phrase is “exceeds authorized access”—and courts have interpreted that broadly.

If your agent holds a credential that allows it to read or write data it doesn’t need for its function, and it does so, you’re in a gray area. The agent isn’t a person, but the firm is responsible for what it does. If the agent accesses client files it shouldn’t, writes to a database it should only read, or pulls billing data during an intake call, you’ve exceeded authorization.

The risk isn’t just regulatory. It’s reputational. A client whose privileged information was accessed by an agent they never consented to interact with has a legitimate grievance. A malpractice carrier reviewing your tech stack during a claim will ask hard questions about how you scoped access. And if you’re in discovery for a data breach, the opposing counsel will want to know exactly what your agents could touch and when.

Most firms don’t have an answer to that question right now. They know the agent works. They don’t know what it can see.

Audit your agent credentials this week

The fix isn’t complicated, but it requires someone to sit down and map what each agent actually needs. Start with the agents you’ve already deployed. For each one, list the systems it touches and the permissions it holds. Then ask: does it need all of that?

An intake voice agent needs to read your conflict database and write to your calendar. It doesn’t need to read billing records or update trust account balances. A document review agent needs to read matter files and write summaries. It doesn’t need to delete files or access opposing counsel correspondence. A matter triage agent needs to read intake forms and route them to the right partner. It doesn’t need admin access to your entire practice management system.

Once you’ve mapped the actual need, you can scope the credential. Most practice management systems and CRMs let you create role-based access or API keys with limited permissions. If yours doesn’t, that’s a vendor conversation you need to have this month.

If you’re working with a vendor who built the agent, ask them to document the permissions they provisioned and explain why each one is necessary. If they can’t, or if they provisioned admin access because it was easier, that’s a red flag. The vendor might not carry the liability when something goes wrong—you do.

For firms that haven’t deployed agents yet, this is easier. Scope the credentials before the agent goes live. Build the principle of least privilege into the deployment checklist. Make it a line item in your vendor contract: the agent gets exactly the access it needs to perform its function, nothing more.

We’ve built this into every Omni deployment. When we set up an intake voice agent or a matter triage agent, we start by mapping the data flow. What does the agent need to read? What does it need to write? Where does it hand off to a human? Then we provision credentials that match that map. If the agent only needs to read conflicts and write to a calendar, that’s all it gets.

It takes an extra hour upfront. It saves you from a much longer conversation with your malpractier carrier later.

What an intake agent should and shouldn’t touch

Let’s walk through a real example. You deploy an intake voice agent to handle after-hours calls. The agent answers the phone, asks the caller about their legal issue, checks for conflicts, and books a consultation if there’s no conflict. If there is a conflict, it thanks the caller and ends the call.

Here’s what the agent needs to access:

• Your conflict database (read-only) to check whether the caller or the opposing party is already a client.
• Your calendar system (write access) to book the consultation slot.
• Your intake log (write access) to record the caller’s name, contact info, and a brief description of the issue.

Here’s what the agent doesn’t need:

• Billing records.
• Trust account balances.
• Existing matter files.
• Privileged correspondence.
• Opposing counsel contact details.
• Case strategy notes.

If your intake agent can read any of that, you’ve over-scoped the credential. The agent will never need it to do its job. But if a logic error or a prompt injection causes the agent to pull that data, you’re exposed.

The same principle applies to document review agents. A first-pass review agent needs to read the document set you point it at and write a summary memo. It doesn’t need to delete files, edit metadata, or access unrelated matters. Scope the credential to match the task.

For matter triage agents that classify and route intake forms, the agent needs to read the form submission and write a routing note. It doesn’t need to update client records, pull billing history, or access the full matter file. Give it read access to intake submissions and write access to a routing queue. Nothing else.

This isn’t about distrusting the agent. It’s about limiting the blast radius when something goes wrong. Agents will make mistakes. Prompts will drift. Logic will misfire. When that happens, you want the agent to fail in a way that doesn’t expose privileged data or create a CFAA problem.

If you’re not sure where to start, the Omni Audit for law firms is built for this. We spend 60 minutes mapping your intake, triage, and document workflows. We identify where agents would add value and where they’d introduce risk. And we document exactly what credentials each agent would need, so you can deploy with confidence or fix what’s already running.

Book a 60-min Omni Audit and we’ll walk through your current agent deployments. You’ll leave with a credential scope map, a risk assessment, and a deployment checklist you can hand to your IT team or vendor.

The intake checklist you can use today

If you’re deploying an intake agent this quarter, you need a checklist that covers credential scope alongside the usual intake logic. We’ve built one for law firms that includes conflict-check workflows, calendar integration, and credential scoping.

You can download the AI Client Intake Checklist for Law Firms and use it as a deployment worksheet. It’s a one-page PDF that walks through the access questions you need to answer before the agent goes live. Print it, fill it out, and keep it in your deployment file. If something goes wrong later, you’ll be able to show you scoped access intentionally.

The checklist isn’t a substitute for an audit, but it’s a good starting point if you’re moving fast and need to document your decisions.

The dollar cost of getting this wrong

Let’s talk about what happens if you don’t fix this. The direct cost of a CFAA violation is hard to predict—it depends on the facts, the jurisdiction, and whether a regulator or opposing counsel decides to make it an issue. But the indirect costs are easier to estimate.

A client whose privileged information was accessed without authorization will ask questions. If they’re sophisticated, they’ll ask for an audit of your systems. That audit will cost you $15,000 to $30,000 if you hire outside counsel and a forensics firm. If the client decides to file a malpractice claim, your carrier will get involved. Expect your premiums to increase, even if the claim doesn’t pay out.

If you’re in discovery for a data breach and the opposing counsel finds out your agents had over-scoped access, they’ll use it. They’ll argue you were negligent in how you deployed AI. They’ll ask for logs, credential audits, and vendor contracts. You’ll spend $40,000 to $80,000 in legal fees responding to those requests, and the case will take longer to settle.

The reputational cost is harder to quantify, but it’s real. If a client tells their network you deployed an AI agent that accessed files it shouldn’t have, that story spreads. Referral sources will hesitate. Prospects will ask harder questions during intake. You’ll lose deals you would have won.

Compare that to the cost of scoping credentials correctly. It’s an hour of work per agent. If you’re working with a vendor, it’s a line item in the contract. If you’re doing it in-house, it’s a checklist your IT team can follow. The cost is near zero. The risk you avoid is substantial.

For firms doing $1M to $25M in revenue, the typical cost of unbilled time and intake leakage is $80,000 to $250,000 per year. Agents can recover a meaningful portion of that—if you deploy them correctly. But if you deploy them with over-scoped credentials and something goes wrong, you’ll spend more fixing the problem than you saved.

What we’re seeing in firms that got this right

The firms that have deployed agents successfully didn’t skip the credential scoping step. They mapped the workflow first, identified the data the agent needed to touch, and provisioned access that matched. When the agent went live, it worked. When something went wrong—a logic error, a misrouted call, a conflict-check failure—the blast radius was small.

One mid-sized litigation firm in our network deployed an intake voice agent last year. They scoped the credential to read-only access for conflicts and write access for calendar and intake logs. Three months in, the agent misclassified a caller and logged them under the wrong practice area. The partner caught it during a weekly review. The fix took ten minutes. Because the agent couldn’t access billing or matter files, there was no exposure. The client never knew.

Another firm deployed a document review agent for discovery. They scoped the credential to read-only access for the specific document set and write access for a summary memo folder. The agent produced 40 first-pass memos in the first month, saving roughly 60 hours of associate time. When the agent flagged a clause incorrectly, the associate caught it during review. Because the agent couldn’t edit the original documents or access unrelated matters, the error didn’t propagate.

Both firms spent an extra hour during deployment to map the credential scope. Both avoided problems that would have cost them significantly more to fix.

If you want to see how this works in your firm, the Omni Audit is the fastest way to get a clear picture. We’ll map your workflows, identify where agents would help, and document the credential scope for each one. You’ll leave with a deployment plan you can execute this quarter.

The three questions to ask before you deploy

Before you deploy an AI agent—or if you’ve already deployed one and you’re not sure how it’s scoped—ask these three questions:

1. What systems does the agent need to access to do its job?
2. What permissions does the agent currently hold?
3. If the agent exceeds its intended function, what’s the worst data it could touch?

If the answer to question three includes privileged client information, billing records, or trust account data, you’ve over-scoped the credential. Fix it before you deploy, or fix it this week if the agent is already live.

Most firms don’t have good answers to these questions right now. That’s not because they’re careless. It’s because the credential scoping conversation didn’t happen during deployment. The vendor provisioned access, the agent worked, and everyone moved on.

But the OpenAI-Hugging Face incident is a reminder that over-scoped credentials are a ticking liability. The agent doesn’t need to be malicious. It just needs to exceed its authorization once. And when it does, you’re the one explaining it to your client, your malpractice carrier, and possibly a regulator.

The fix is straightforward. Map the workflow. Scope the credential. Document the decision. If you’re not sure how to do that, book a 60-min Omni Audit and we’ll walk you through it. You’ll leave with a credential map, a risk assessment, and a deployment checklist. No deck, no upsell, just the information you need to deploy agents correctly.

If you’ve already deployed agents and you’re not sure how they’re scoped, the audit will identify the gaps. We’ll document what each agent can currently access, compare it to what it needs, and give you a remediation plan you can execute in-house or hand to your vendor.

The cost of getting this wrong is high. The cost of getting it right is an hour of your time. That’s the trade.