Browser AI Agents vs MCP vs RPA for Law Firm Portals

By Jude Lee · · Custom

Law firm staff logging into a court portal on a desktop computer while reviewing printed docket pages

Portals are starting to notice that the user isn’t a person

Two recent developments are worth a small firm’s attention, not because they are about law firms, but because they signal where this is heading.

Law Commentary reported that major US banks have been detecting unauthorized AI agents logging into customer accounts with customer-supplied credentials. Separately, Dan Lohrmann asked in GovTech whether government websites should block personal AI agent transactions — a question that lands directly on court e-filing systems, recorder sites, and agency portals.

The regulatory backdrop is moving in the same direction. In the UK, the Information Commissioner’s Office has opened a call for views on AI agents and data protection expectations, summarised by Freshfields; if you intend to respond, take the submission deadline from the ICO’s own call-for-views page rather than from any secondary summary, including this one.

The pattern: operators of sensitive portals are deciding, right now, how they feel about software logging in on a human’s behalf. If your automation plan depends on an agent typing your bar-issued credentials into a court site, you are building on ground that may shift.

What a browser agent actually is

A browser agent (sometimes called “computer use”) is an AI model that gets screenshots of a browser window and can click, type, scroll, and read — the same way a person does. It needs no API, no vendor partnership, and no IT project. You describe the task in plain language — “log into the carrier portal, find claim 44-2219, download any new correspondence, and save it to the matter folder” — and it works the interface.

That is the honest appeal, and the honest limit. Browser agents are slow compared to an API call, they cost more per task because every screen is reasoned over, and they break in ways scripts don’t: a cookie banner, a session timeout, an unexpected two-factor prompt. They also look like a human user to the site, which is precisely why portal operators are getting nervous.

The three access routes, compared

MCP / API connection

What it is: the agent calls documented endpoints — your practice management system, DMS, billing platform — often through MCP, an open protocol for giving an AI governed access to tools and data.

Strengths: fast, cheap per call, structured results, auditable. Permissions are scoped at the token level, so you can grant read-only on matters and nothing on trust accounts.

Weaknesses: only works where an API exists. Most county recorders, many state e-filing systems, and plenty of insurer portals have none.

Best for: Clio, NetDocuments, Microsoft 365, e-signature, billing — the core stack.

Browser agent

What it is: the model drives a real browser, reading the screen and clicking.

Strengths: works on anything with a login. No integration to wait for. Tolerates minor layout changes that would snap a brittle script.

Weaknesses: slower, pricier per run, non-deterministic, and vulnerable to prompt injection from page content. Credentials have to live somewhere, and the site may class it as unauthorized access. There is also a confidentiality exposure that’s easy to miss: a screenshot-driven agent is transmitting images of matter data — client names, claim details, open documents on screen — to a model provider, so read the data-handling, retention, and training terms of whichever model you run before any client data appears in the window.

Best for: low-volume, read-only retrieval from portals you’d otherwise check by hand — and only where terms allow.

The third option is classic RPA: a recorded or coded script that clicks fixed coordinates and selectors. It’s deterministic, cheap to run, and fully auditable — and it shatters the moment the portal redesigns a button. If a screen never changes and you hit it two hundred times a week, RPA still beats an AI agent on cost and predictability. That’s not a nostalgic take; it’s a straightforward engineering call. We cover the broader integration question in AI plugins vs MCP vs Zapier.

Reach for a browser agent where no API exists — not where an API exists and nobody has wired it up yet.

Where small firms are actually pointing agents today

If you search for how firms use AI, you’ll find two very different answers: vendor marketing describing autonomous legal work, and practitioners on forums describing drafting help and summarisation. The practitioner answer is closer to reality as of 2026.

The stack most small and mid-size firms are running looks like: a general assistant (Claude, ChatGPT, or Copilot) for drafting and analysis; AI features inside the practice management system they already pay for (Clio Duo, Smokeball Archie, MyCase IQ); a point tool or two for research or review; and — in a growing minority — a governed connection from the assistant into firm systems so it can work on real matter data instead of pasted text. Browser agents are the newest layer and the least settled.

Concrete portal jobs worth a look, in rough order of safety:

Picking the slice of portal work actually worth automating

Don’t automate every portal. Spend one week logging, per person, every portal login: which site, what you did, how long. Rank by total annual minutes. Automate the top two or three; leave the rest alone.

The arithmetic you need is a formula, not a benchmark:

(minutes per task ÷ 60) × tasks per week × 52 = hours per year. Multiply by the loaded hourly cost of whoever does it today to get the cost base. Then multiply the recovered hours by the share you can genuinely redeploy to billable or intake work — if the hours just evaporate into slack, the real return is error reduction and staff goodwill, not revenue.

hours × rate
The only ROI formula that survives contact with reality — plug in your own figures
3 routes
API/MCP, browser agent, RPA — pick per system, not per firm
1 week
Suggested logging period before choosing what to automate

One search that keeps surfacing next to law firm automation is what percentage of lawyers earn $500,000 a year. We don’t have a reliable figure, and neither do most of the pages that confidently answer it — compensation data varies sharply by practice area, geography, and firm size. The useful version of the question is leverage: how much billable or business-generating work each attorney can support. Portal automation moves that number only if the recovered time is actually reallocated.

A sane rollout

  1. Inventory the portals and their terms

    List every site your team logs into. For each, note whether an API or official integration exists and what the terms of use say about automated access. This single sheet decides most of your architecture.

  2. Use MCP or the vendor API wherever one exists

    If Clio, NetDocuments, or your billing system has an endpoint, use it. A governed connection beats a screen-reader every time on speed, cost, and audit trail.

  3. Pilot a browser agent on one read-only job

    Pick the highest-minute portal with no API. Run the agent beside the human for two weeks and score two things: the disagreement rate (how often the agent’s retrieved set differs from what the human found) and silent failures (runs where the agent reported success but returned nothing, the wrong matter, or a stale document). Decide the bar before you start — our suggestion is that any silent failure that a reviewer wouldn’t have caught, or a disagreement rate you can’t drive down with instruction tuning inside the pilot window, ends the pilot and the task stays manual.

  4. Isolate credentials

    Use a dedicated service account where the portal permits one, never a personal bar or ECF login. If the portal only issues individual logins — common for county recorders and e-filing — that portal stays manual, or it goes through a vendor that holds the relationship and files under its own credentials. Store secrets in a vault, not a prompt. Log every session.

  5. Define the human checkpoint

    Decide in writing what the agent may do unattended and what requires sign-off. Submissions, filings, and anything touching trust funds stay human-approved.

When the right answer is no agent at all

If a portal task takes four minutes a week, automate nothing. If the portal has a vendor integration your practice management system already supports, use it and skip the build. If the screen is stable and the volume is high, a plain script is cheaper and more predictable than a reasoning model. Browser agents earn their keep in one specific gap: real volume, no API, tolerable terms of use, and a task where a wrong click is recoverable.

That gap is real in legal work — more real than in most industries, because so much of the public infrastructure lawyers depend on was built for humans with logins. Just build for the version of 2027 where portal operators have made up their minds about agents, not the version where nobody is watching.

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