Law Firm AI Agents: Shared Logins vs OAuth vs API Keys

By Jude Lee · · Custom

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

Why agent identity stopped being a theoretical problem

For two years the question in small firms was “can AI do this task?” The 2026 question is “who exactly was logged in when it did?”

There is a steady stream of trade reporting about banks and government portals detecting — and in some cases blocking — logins driven by personal AI agents. We’re not going to hang an argument on a specific article or a number we can’t stand behind; if you want to cite one, verify it yourself before you repeat it. The underlying mechanic, though, is uncontroversial and worth internalizing: fraud and abuse systems score sessions on behavioral signals like typing cadence, navigation speed and device fingerprint. An agent driving a browser with a human’s credentials produces a session that doesn’t look human, because it isn’t. Whether a given institution treats that as fraud, as a terms-of-use violation, or as nothing at all is their call, not yours.

Translate that to a seven-lawyer firm: the bank holding your IOLTA account, the county recorder, your e-filing provider and your malpractice carrier all have an interest in knowing whether a human or a script is on the other end of the session. Your answer should not be “we gave the bot Jennifer’s password.”

These are editorial rules of thumb — judgment calls, not measured findings:

3 models
Realistic ways an AI agent authenticates: shared human login, delegated OAuth token, or its own service account
Editorial rule of thumb
Read-only first
Sensible starting scope for any new agent until the logs look boring
Editorial rule of thumb
1 identity per agent
Target state: every agent is distinguishable from every human in the audit trail
Editorial rule of thumb

The three ways an agent can get in

Shared human credentials. The agent (usually a browser-driving agent or RPA script) logs in as a person: same username, same password, sometimes the same MFA code read aloud by a paralegal. Everything it does is attributed to that person. This is the only option for systems with no API — which still includes a lot of court e-filing portals, insurer portals and county systems.

Delegated OAuth. The agent is registered as an application. A human clicks “authorize,” and the agent receives a scoped, expiring token. Access can be revoked without changing anyone’s password. Clio’s developer documentation describes an OAuth 2.0 flow for API applications, and Microsoft 365, Google Workspace, NetDocuments and DocuSign follow the same general pattern. The Model Context Protocol’s authorization guidance for remote servers also builds on OAuth — re-check the current spec, since this area has been moving fast as of 2026.

Be realistic about what OAuth buys you. Many legal and productivity APIs publish coarse scopes — “read all matters” with no per-matter restriction, “full mailbox” rather than one folder — and plenty of audit logs record which application acted, not which specific record it touched or why. Delegated OAuth is a meaningful improvement over password-sharing. It is not the fine-grained, self-documenting permission system the marketing pages imply. Read the vendor’s actual scope list before you design around it.

Dedicated service account or API key. The agent is its own user: “Intake Agent,” “Reconciliation Agent.” It holds its own key, has its own permission set, and shows up in logs under its own name. This is what you typically use when you’ve built your own integration layer — for example a custom MCP server over your firm’s matter data. The tradeoff: there’s no human consent gate at runtime, so over-permissioning a service account is one of the easier ways to give an agent far more reach than you intended.

Agent borrows a human login
Works anywhere a browser works, including portals with no API. But: actions are indistinguishable from the lawyer’s own; MFA either gets bypassed or becomes a daily interruption; fraud systems may flag or lock the account; terms of use for many court and bank portals restrict automated access — verify the specific portal’s terms before you automate it.
Agent has delegated OAuth or its own service account
Named identity, expiring tokens, revocation without a password reset, cleaner offboarding. But: only available where the vendor exposes an API, sometimes behind a higher-priced plan or a developer approval process, scopes may be coarser than you’d like, and a service account may consume a paid seat.
If your audit log can’t tell the difference between you and your agent, you don’t have an audit log. You have an attribution problem waiting for a bar complaint.

Where the key actually lives

“Give the agent its own key” is only safer than password-sharing if the key doesn’t then end up somewhere worse. The common failures are mundane: an API key pasted into a chat prompt or a system-prompt file, a token committed to a repo, credentials sitting in a plaintext .env on a laptop that isn’t encrypted, or a service account password stored in a shared spreadsheet because the firm’s password manager “is for people.”

The workable pattern for a small firm: secrets live in your password manager’s shared vault or your hosting platform’s secrets store, get injected as environment variables at runtime, and are never typed into a prompt window — because prompts get logged, and those logs may sit with a third party. Give each secret a named owner, note its expiry date, and treat a key pasted into a chat as compromised and rotate it. Supervising delegated work extends to supervising where the delegated credential sits; see the ABA Model Rules on supervision and Rule 1.6(c)‘s reasonable-efforts standard for safeguarding client information, plus whatever your state bar has published on top of it.

Matching the model to the systems a small firm actually runs

Walk your stack and label each system with the best mechanism available, not the most convenient one:

A worked example: the monthly reconciliation agent

Say you want an agent that each month pulls the bank statement, matches transactions against ledger entries in your practice management system, and drafts an exceptions list for the bookkeeper.

The tempting build is a browser agent with the firm’s online banking login. The safer build: a read-only feed or exported statement into a folder the agent can read, plus an OAuth-scoped connection to the practice management system’s financial records, plus a human who reviews and posts every adjustment. The agent prepares; the human decides. That also keeps you aligned with the supervision expectations in ABA Formal Opinion 512 (2024) on generative AI and the ABA Model Rules on supervising nonlawyer assistance — and your state bar may have its own guidance, so check it.

To size the value, don’t take anyone’s headline number. Use your own: (hours the bookkeeper and a partner spend on reconciliation each month) × (your blended cost per hour) × 12, plus whatever share of that partner time realistically becomes billable instead of absorbed elsewhere. Then subtract build and maintenance cost, including the hours someone spends each quarter rotating keys and fixing broken connections. If the result isn’t comfortably positive on paper, the automation isn’t ready.

When the token breaks halfway through

Revocation gets all the attention; silent breakage causes more trouble. Refresh tokens expire, vendors deprecate scopes, an admin tightens a permission, a service account loses a seat at renewal. The agent then fails partway — the reconciliation reads the bank data, writes four ledger notes, hits a 401 on the fifth, and stops. Nobody notices, because success was the only outcome anyone built a notification for.

Design for it: have every agent run report completion explicitly (including “completed with errors”), and alert a named human on silence, not just on failure. Make write steps idempotent or checkpointed so a rerun doesn’t double-post. Log the last four characters of the credential used and its expiry so a human can diagnose in seconds. And decide in advance whether a half-finished run should roll back or hold for review — for anything touching client funds or filings, hold for review.

Getting the plumbing right

  1. Inventory what the agent will touch

    List every system, and for each one note: does it have an API? Does it support OAuth? Can we create a named service account? What do its scopes actually cover, and what does its audit log genuinely record?

  2. Give every agent its own identity

    No agent shares a human’s account. Name it, document its owner, and make sure the name appears in logs.

  3. Store the secret properly

    Shared vault or platform secrets store, injected at runtime, never pasted into a prompt. One named owner per credential.

  4. Start read-only, then widen

    Run the agent in read-and-draft mode until the output is boring. Write access is a separate decision — see our breakdown of read-only vs write access for law firm agents.

  5. Set rotation, monitoring and offboarding rules

    Rotate on a schedule you pick, alert on expiry before it bites, and make revoking a departing contractor’s agent access a one-click job.

  6. Put it in the vendor contract

    Ask prospective legal-AI vendors, in writing: how does your agent authenticate, what scopes does it request, what per-action logs can we export, and how fast do you notify us of an incident? Keep the answers.

When “no agent access” is the right answer

Sometimes the honest call is that the agent shouldn’t be connected at all. If a workflow runs twice a month, touches a portal that forbids automation, and takes twenty minutes, a human doing it with an AI-drafted checklist is cheaper and safer than any integration. Off-the-shelf features inside your existing practice management system also solve the identity problem for you — their agent runs inside their permission model, which is a genuine advantage over a bespoke build you now have to govern.

The decision that matters isn’t which AI you buy. It’s whether, six months from now, you can answer a client, a bank, or a disciplinary authority asking: who did this, and under whose authority? Build so that question has a one-sentence answer.

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