Legal AI Agent Data Leaks: 3 Access Models Compared

By Jude Lee · · Custom

Lawyers and an IT consultant reviewing system access permissions for an AI tool on a laptop in a small law firm

The week agents started getting treated like employees

Two stories from mid-October 2026 belong on the same page. Law.com’s Legaltech News ran a piece on the AI agent privacy problem, asking who answers for it when a legal AI shares client data it shouldn’t have. The same week, Help Net Security reported that security leaders increasingly classify AI agents as insiders — a non-human identity with credentials, access, and the ability to do damage.

That reframing is the useful part for a 4-to-40 lawyer firm. An insider has a name, a login, a permission set, and a supervisor. Most firms running AI today can’t say those four things about their tools. The agent is “the ChatGPT tab,” or “the thing built into Clio,” or worse, “the automation my paralegal set up that logs in as her.”

If you can’t name the identity your AI used and pull its log, you don’t have an AI governance problem — you have an unlogged insider.

Yes, AI is allowed — the duties just travel with it

The ABA’s Formal Opinion 512 (2024) addresses lawyers’ use of generative AI tools and works through the familiar duties: competence, confidentiality, communication, supervision, and reasonable fees. It is not a ban, and it is not a blank check. Model Rule 1.1 comment [8] has required technology competence for years. Rule 1.6(c) requires reasonable efforts to prevent unauthorized disclosure. Rules 5.1 and 5.3 put supervision of assistance — including nonlawyer and vendor assistance — on the lawyer.

State guidance exists and varies: the State Bar of California published practical guidance on generative AI for lawyers, the Florida Bar issued Ethics Opinion 24-1, and the New York State Bar Association’s AI task force published a report with recommendations. Read the one that governs you, and confirm anything consequential with your own bar’s ethics counsel — several states address client consent for third-party AI processing differently.

The operational translation: an AI agent is a thing you supervise, not a thing you deploy and forget. Which makes how it connects the real decision.

Model 1: the vendor-embedded agent

This is Clio Duo, Smokeball’s Archie, CoCounsel inside your document system, Casepoint’s newly announced eDiscovery agents, SixFifty’s employment-law agent — AI built by the company that already holds your data.

What’s good: the data never leaves a system you already vetted. Access control inherits from the user permissions you’ve already set. The vendor’s DPA and security posture already cover it. For most small firms, this is the lowest-friction path to “we use AI safely.”

What breaks: the agent can only see what that one platform holds. Your matter story usually lives across the practice management system, Outlook, a document store, and a billing ledger. A vendor agent is structurally blind to three of the four. You also inherit the vendor’s roadmap — if their summarization skill doesn’t match how your firm writes case chronologies, you adapt, not them.

Model 2: your own assistant, connected over MCP with its own identity

The Model Context Protocol is an open standard for giving an AI assistant governed access to specific tools and data — you expose a defined set of operations (“search matters,” “read document,” “create time entry”) rather than handing over a whole system. As of 2026 the MCP specification defines an OAuth-based authorization approach for remote servers; check the current spec at modelcontextprotocol.io rather than trusting a blog post, this layer has moved fast.

The security advantage isn’t the protocol itself — it’s what the protocol forces you to do. You have to decide, in writing, which operations exist. That’s a permission set. And you can issue the agent its own service account instead of letting it ride on a human’s session, which is the difference between an audit log that says “the intake agent read matter 2024-118” and one that says “Jennifer did,” at 2:14 a.m., in a matter she isn’t staffed on.

If you’re building this, the two decisions that matter most are covered in our pieces on read-only versus write access for law firm AI agents and connecting Claude to Clio via MCP.

Vendor-embedded agent
Fastest to deploy. Data stays inside an already-vetted system. Permissions inherit from existing roles. Limited to one platform’s data. Vendor controls behavior, output format, and roadmap. Liability sits largely in their DPA — read it.
Your own agent over MCP
Weeks of setup plus ongoing ownership. Can span PMS, email, documents, and billing. You define the exact operation list and the agent’s own identity. You own the logging, the key rotation, and the failure modes. Needs someone technical on retainer.

Model 3: shared logins and browser automation — the one to retire

A surprising amount of “law firm AI automation” in the wild is an assistant driving a browser session under a staff member’s credentials, or a no-code flow authenticated as whoever happened to connect it. It works. It demos beautifully. And it is the configuration that produces the Law.com headline.

Three specific failure modes: the agent inherits every permission that human has, including matters it has no business reading (a conflicts problem, not just a security one); the audit trail attributes machine actions to a person, so you cannot reconstruct what happened; and when that person leaves, your automation either breaks or keeps running on a credential you meant to revoke.

The honest version of the skeptics’ case

Search practitioner forums for AI automation experiences and the recurring complaint isn’t really hallucination — tools have improved and lawyers check citations now. It’s opacity: not knowing what the tool read, what it sent where, or how to explain any of it to a client or a malpractice carrier. That’s a fair criticism, and it’s an architecture problem rather than a model problem.

The other genuine disadvantage: every access model adds a supervision burden. An agent that touches twelve matters a day generates twelve decisions someone should be able to defend. Our write-up on oversight models for AI agents covers how to size that review load before you scale a pilot.

A vetting checklist before any agent touches a matter

  1. Name the identity

    Decide whether the agent gets its own service account or rides a human session. Write it down. Service account is the better default for anything running unattended.

  2. Enumerate the operations

    List every action the agent can take, in verbs. If the list is “anything a user can do,” you haven’t scoped it.

  3. Confirm retention and training terms

    Get the vendor’s position in writing on data retention, model training, and subprocessors. Ask specifically about sub-processors — that’s where client data most often moves without anyone noticing.

  4. Test the log

    Run the agent, then pull the audit trail. Can you tell which matters it read and what it wrote? If not, stop here.

  5. Define the human gate

    Decide which outputs are advisory and which can leave the building. Anything client-facing, court-facing, or money-moving stays human-approved.

  6. Check your jurisdiction

    Confirm with your state bar whether client consent or engagement-letter disclosure is expected for the specific tool and data involved. This varies meaningfully by state.

Modeling the cost of getting this wrong — with your own numbers

There’s no credible public benchmark for what a small-firm AI data incident costs, so don’t let anyone sell you one. Model it yourself with explicit assumptions.

Take the exposure side: number of matters the agent can reach × your honest estimate of how sensitive those files are. Then the response side: assume a confidentiality incident consumes, say, partner hours for client notification, associate hours for review, plus outside counsel or carrier involvement. Multiply hours by your actual rates. Compare that figure to the cost of the control that prevents it — typically a scoped service account and a few hours of configuration.

The upside math works the same way. If a properly scoped records-request or intake agent recovers staff hours, value them at what those people would otherwise bill or produce — not at a vendor’s marketing number. Plug in your own rates.

3
access models to choose between (pick deliberately, not by accident)
Rule 1.6(c)
the confidentiality duty that follows your agent everywhere
ABA Model Rules of Professional Conduct
hours × rate
the only ROI formula worth trusting — use your own inputs

What most small firms should actually do

Start with the vendor-embedded agent in the system that holds most of your work. It’s governed, it’s supported, and it answers the “is this safe” question with a contract you can hand your carrier. Build a custom MCP connection when — and only when — the job genuinely spans systems a single vendor can’t see, or when your firm’s method for a recurring task is distinctive enough that a generic skill produces work you’d have to redo.

And regardless of model: retire the shared logins this quarter. That’s the one change that costs almost nothing and removes the failure mode the headlines are about.

Where is your firm losing billable hours?

Get a free automation audit: we map your intake-to-invoice workflow and show you exactly what's worth automating — before you spend a dollar.

Get a free automation audit

Related guides