Okta just paid around $200 million for an AI security startup called Permiso. The company specialises in one thing: stopping credential sprawl in environments where AI agents operate. That price tag tells you something. The market has woken up to a problem most law firms don’t yet know they have.

If your firm uses AI tools to draft documents, triage intake, or review discovery, those tools log in somewhere. They authenticate. They access data. And in most deployments, they’re doing it with a single shared credential that every agent, every matter, and every practice area uses interchangeably.

That’s a compliance disaster waiting to happen. It’s also a fast way to lose a client, blow a conflict check, or hand opposing counsel a gift-wrapped ethics complaint.

Here’s what’s at stake and how to fix it before it costs you a case.

The credential problem most firms don’t see

When you deploy an AI agent to handle intake calls or review contracts, someone on your team sets up an account. The agent gets a username, a password, maybe an API key. That credential sits in a config file or a secrets vault, and every instance of the agent uses it.

It works. The agent answers calls, triages emails, flags clauses. But that single credential now has access to every matter the agent touches. If the agent processes intake for family law on Monday and corporate M&A on Tuesday, the same identity sees both. There’s no separation. No audit trail that distinguishes which task accessed which file. No way to revoke access to one practice area without shutting down the entire agent.

This isn’t hypothetical. One mid-sized firm in our network deployed a Document Review Agent to handle first-pass contract analysis. The agent used a single service account with read access to the firm’s document management system. Six months in, a partner discovered the agent had indexed and summarised files from a matter where the firm had a conflict. The agent didn’t know. The service account didn’t care. The metadata logs showed the access, but no one had thought to scope the credential by matter or client.

The fix required a full conflict audit, disclosure to both clients, and a very uncomfortable conversation with the state bar. The firm got lucky. The breach didn’t escalate. But the partner told me it cost them 80 billable hours in remediation and nearly lost them a seven-figure client.

Why shared credentials break in legal work

Law firms operate under privilege, conflict, and confidentiality rules that don’t map to how most software handles identity. A typical SaaS tool assumes everyone in the account should see everything, or that permissions are managed at the user level. But legal work isn’t structured that way.

A junior associate on a real estate matter shouldn’t see discovery from an employment case. A partner handling plaintiff work can’t access files from a defendant matter in the same practice area. Conflicts checks happen at intake, and once a conflict is identified, access to related data has to be locked down immediately.

When an AI agent operates under a shared credential, none of that nuance exists. The agent is one identity. It sees what the credential allows. If that credential has broad access because the agent needs to work across multiple matters, you’ve just created a privilege leak that no amount of post-hoc logging can fix.

The risk compounds when you run multiple agents. An Intake Voice Agent that answers after-hours calls needs access to your calendar, your conflict database, and your intake forms. A Matter Triage Agent that reviews inbound emails needs access to your case management system and your client list. A Document Review Agent that performs first-pass analysis needs access to your DMS and your matter files. If all three agents share the same credential, or if each agent uses a single firm-wide identity, you’ve built a system where one compromised key exposes everything.

This is why Okta paid $200 million for a company that helps enterprises assign individual identities to non-human actors. The problem isn’t theoretical. It’s expensive, it’s widespread, and it’s about to get worse as more firms deploy AI without thinking through the access model.

What individual agent credentials look like in practice

The fix is conceptually simple but operationally specific. Every agent gets its own identity. Every identity gets scoped permissions. Every matter gets its own access boundary.

Here’s what that means in a working deployment.

You deploy an Intake Voice Agent to handle after-hours calls. Instead of giving the agent a single service account with access to your entire calendar and client database, you provision a unique identity for that agent. The identity has read access to your conflict database, write access to a staging intake table, and permission to book consultations into a specific calendar. It can’t see matter files. It can’t access billing records. It can’t read emails.

When the agent takes a call, it logs in with its own credential. The action is traceable to that specific agent. If you need to revoke access, you disable that identity without touching anything else. If you need to audit what the agent saw, you query logs tied to that credential. If the agent is compromised, the blast radius is contained to the narrow set of permissions you granted.

You do the same for your Matter Triage Agent. That agent gets a different identity with read access to your intake queue and write access to your case management system. It can classify practice areas and route matters, but it can’t book calls or access documents. The permissions are scoped to the task.

Your Document Review Agent gets the most restrictive setup. Instead of one identity with access to all matters, you provision matter-specific identities. When a new case opens, you create a credential scoped to that matter’s document set. The agent uses that credential to perform first-pass review, and when the matter closes, you revoke the identity. The agent never sees files from other cases. The access is time-bound and auditable.

This isn’t exotic. It’s how enterprises manage service accounts in regulated industries. The difference is that most law firms don’t think of AI agents as service accounts. They think of them as features of a tool. But once the agent authenticates and accesses data, it’s an identity. It needs to be managed like one.

If you’re not sure whether your current AI tools use shared credentials or individual identities, that’s the first question to ask. Most vendors default to shared. It’s easier to deploy and simpler to support. But it’s not compliant, and it’s not safe. See Omni for law firms to understand how we handle agent identity from day one.

The compliance and ethics angle

State bars are starting to pay attention. ABA Formal Opinion 512 requires lawyers to understand the technology they use and to ensure it doesn’t compromise client confidentiality. That opinion was written before AI agents became common, but the principle applies. If you deploy an agent that uses a shared credential with access to privileged material, and that agent leaks data or crosses a conflict boundary, you’re on the hook.

The problem is that most firms don’t know how their AI tools authenticate. The vendor says the tool is secure. The tool works. The firm assumes compliance. But when you dig into the config, you find a single API key or a service account that every agent instance shares. That’s not secure. It’s not compliant. And it’s not defensible if something goes wrong.

The fix requires three things. First, you need to inventory every AI tool your firm uses and document how it authenticates. Second, you need to map the permissions each tool has and confirm they’re scoped to the minimum necessary access. Third, you need to implement individual identities for each agent and matter-specific boundaries where appropriate.

This isn’t a one-time audit. It’s an ongoing practice. Every time you deploy a new agent or expand an existing one, you revisit the access model. You don’t bolt security on after the fact. You design it in from the start.

We built Omni with this model baked in. Every agent we deploy gets its own identity. Every matter gets its own access boundary. Every action is logged and traceable. That’s not a feature. It’s the foundation. If you’re evaluating AI tools and the vendor can’t explain how they handle non-human identity and matter-specific permissions, that’s a red flag.

What an Omni Audit uncovers

When we run an Omni Audit for a law firm, credential hygiene is one of the first things we check. We map every system your firm uses, every integration point, and every place an AI agent might authenticate. We document the access model, identify shared credentials, and flag privilege boundaries that aren’t enforced.

Most firms are surprised by what we find. A partner will tell us they use one AI tool for intake and another for document review. When we audit the setup, we discover both tools share a service account with admin-level access to the firm’s DMS. Or we find an agent that was deployed for a single practice area but has credentials that grant access to the entire client database.

The audit takes 60 minutes. You walk away with three things: a map of your current AI footprint, a list of credential and access risks ranked by severity, and a scoped plan to fix them. No deck. No 40-page report. Just the specific changes your firm needs to make in the next 30 days.

If you’re running AI agents today, or if you’re planning to deploy them in the next quarter, this audit is the fastest way to confirm you’re not building a compliance problem. Book a 60-min Omni Audit and we’ll walk through your current setup together.

For firms just starting to think through AI intake workflows, we’ve also put together a practical checklist that covers the most common credential and access questions. You can grab it here: AI Client Intake Checklist for Law Firms. It’s a worksheet, not a whitepaper. Use it to map your current intake process and identify where shared credentials or broad permissions might be hiding.

The cost of getting this wrong

The immediate cost is remediation. If you discover a credential issue after an agent has been running for months, you’re looking at a full access audit, potential client notifications, and bar disclosures. One firm we spoke with spent 120 hours of partner time unwinding an agent deployment that had crossed conflict boundaries. That’s $60,000 to $80,000 in write-offs, not counting the reputational hit.

The longer-term cost is client trust. If a client learns that your AI tool had access to privileged material from a conflicting matter, or that a shared credential exposed their data to an unauthorised system, they’re gone. And they’re taking their referral network with them.

The hidden cost is the work you’re not automating because you’re afraid of the risk. We see this all the time. A firm knows they’re losing 30 to 40 percent of after-hours intake because no one answers the phone. They know an Intake Voice Agent would solve it. But they’re worried about compliance, so they do nothing. The agent never gets deployed. The revenue never gets captured. The cost is invisible, but it’s real.

Fixing the credential model removes that blocker. Once you know your agents operate with individual identities and matter-specific permissions, you can deploy them confidently. You’re not choosing between automation and compliance. You’re getting both.

How we handle agent identity in Omni deployments

When we deploy an Omni agent for a law firm, identity and access control are part of the build, not an afterthought. Here’s what that looks like in practice.

For an Intake Voice Agent, we provision a unique service identity with read-only access to your conflict database and calendar availability. The agent can check for conflicts and book consultations, but it can’t read matter files or access billing data. The credential is rotated every 90 days, and every action the agent takes is logged with a timestamp and a matter reference.

For a Matter Triage Agent, we create a separate identity with access to your intake queue and case management system. The agent can classify matters and route them to the right partner, but it can’t modify existing cases or access closed files. The permissions are scoped to the minimum necessary for the task.

For a Document Review Agent, we go further. Each matter gets its own agent identity. When you open a new case, we provision a credential scoped to that matter’s document set. The agent performs first-pass review, flags clauses, and produces a memo. When the matter closes, we revoke the credential. The agent never sees files from other cases, and the access is time-bound.

This isn’t optional. It’s how we build every deployment. If you’re comparing Omni to other AI tools, ask the vendor how they handle non-human identity. Ask if agents share credentials. Ask if permissions can be scoped by matter. If the answer is vague or if the vendor treats it as a custom feature, that’s a signal. Identity management should be default, not a premium add-on.

You can read more about how we approach agent security and compliance in our AI implementation guides or explore the technical architecture behind Omni Ops and Omni Voice.

What to do this week

If your firm is running AI agents today, or if you’re planning to deploy them soon, here’s what to do in the next seven days.

First, inventory every AI tool your firm uses. List the vendor, the task the tool performs, and the systems it integrates with. For each tool, document how it authenticates. Does it use a shared service account? Does it use individual identities? Does it have matter-specific permissions?

Second, map the permissions each tool has. What data can it read? What systems can it write to? What happens if the credential is compromised? If you don’t know the answers, ask the vendor. If the vendor can’t answer, that’s a problem.

Third, identify the highest-risk credential. That’s usually the one with the broadest access or the one that touches privileged material. Flag it. That’s the first credential you need to replace with an individual identity model.

If you’re not sure where to start, or if you want someone to walk through your current setup and identify the gaps, that’s exactly what the Omni Audit is for. Book my Omni Audit and we’ll map your AI footprint, flag the credential risks, and give you a scoped plan to fix them. It takes 60 minutes, and you’ll leave with a clear picture of what needs to change.

The firms that get this right are the ones that treat AI agents as part of their compliance infrastructure, not as a bolt-on productivity hack. They design access controls from the start. They scope permissions by matter. They rotate credentials and audit logs. And they don’t wait for a breach to force the conversation.

Okta didn’t pay $200 million for a credential management startup because the problem is small. They paid it because the problem is everywhere, and it’s about to get bigger. Law firms that fix it now will have a structural advantage over the ones that wait. You can explore more about how we help firms navigate AI compliance and deployment at the AI audit for law firms, or dive into the broader conversation on our insights hub.

The credential model you choose today determines whether your AI deployment becomes a competitive edge or a compliance liability. Choose carefully.