Use Cases/Legal Agents

79% of lawyers use AI. 10% of firms have policies for it.

ABA Formal Opinion 512 (July 2024) confirmed that using generative AI without understanding how it handles client data violates Model Rule 1.6. Attorney-client privilege can be waived the moment privileged content hits a third-party server accessible to vendor personnel. Veto enforces confidentiality boundaries before any tool call executes.

Start free Learn about guardrails

The ethical obligation

ABA Formal Opinion 512 addresses six areas of ethical concern when lawyers use generative AI: competence (Rule 1.1), confidentiality (Rule 1.6), communication (Rule 1.4), candor toward the tribunal (Rules 3.1, 3.3), supervisory responsibilities (Rules 5.1, 5.3), and reasonable fees. State bars including California, Florida, and New York have issued jurisdiction-specific guidance building on these Model Rules. Runtime authorization is how you prove compliance.

The stakes are different in legal

Legal AI agents handle privileged communications, case strategies, and billing records. A breach in client confidentiality can trigger malpractice claims, bar disciplinary action, and irreparable harm to clients. Unlike other domains, legal errors carry professional and ethical consequences that extend beyond business risk.

Privilege waiver risk

Attorney-client privilege can be waived by AI tools that route privileged content to external infrastructure accessible to vendor personnel. The voluntary disclosure analysis applies regardless of whether disclosure was intentional. One tool call to the wrong endpoint can waive privilege on an entire matter.

Cross-matter contamination

An agent accessing documents from Matter A while working on Matter B creates conflicts of interest and confidentiality breaches. In firms with adverse parties across matters, a single cross-matter access could require withdrawal from a case.

Billing integrity

Agents logging time to incorrect matters, creating duplicate entries, or generating inaccurate billing records could constitute billing fraud. ABA Model Rule 1.5 requires fees to be reasonable — AI-generated time entries without controls undermine this obligation.

Supervision obligation

Model Rules 5.1 and 5.3 require managing lawyers to ensure that all personnel — including AI systems acting as nonlawyer assistants — adhere to professional conduct standards. Human-in-the-loop approval workflows are the mechanism for demonstrating this supervision.

ABA Model Rules mapped to authorization policies

Each Model Rule creates a specific authorization requirement. Veto policies enforce these requirements at runtime, creating auditable evidence of compliance.

ABA Model Rule	Obligation	Veto Policy
Rule 1.6 — Confidentiality	Prevent unauthorized disclosure of client information	Matter isolation, document access control, communication restrictions, data flow controls
Rule 1.1 — Competence	Understand AI tool capabilities and limitations	Scope boundaries prevent agents from operating outside designed practice areas
Rule 1.4 — Communication	Inform clients about AI use in their matter	Audit trails document AI involvement for client disclosure
Rule 1.5 — Fees	Reasonable fees, accurate billing	Time entry validation, duplicate detection, matter-scoped billing
Rules 5.1 / 5.3 — Supervision	Supervise AI as nonlawyer assistant	Human approval workflows, partner review for sensitive actions
Rules 3.1 / 3.3 — Candor	Do not present fabricated citations or authorities	Output verification policies, source validation requirements

Client isolation and document access policies

The most critical authorization pattern for legal agents: ensure each agent operates only within the bounds of its assigned matter. These policies enforce Rule 1.6 confidentiality at the tool-call level.

veto-policy.yamlyaml

name: legal-agent-guardrails
description: Client confidentiality and ethical compliance

rules:
  # Hard matter boundary — Rule 1.6 compliance
  - name: matter-isolation
    tools: ["read_document", "search_documents", "summarize_case"]
    condition: "args.matter_id != context.current_matter_id"
    action: deny
    response:
      error: "Access denied: document belongs to a different matter"
    audit:
      log_arguments: true
      alert_on_deny: true

  # Privileged document protection
  - name: privileged-document-access
    tools: ["read_document"]
    condition: >
      args.document_type == 'privileged' and
      context.user_role not in ['partner', 'associate']
    action: deny
    response:
      error: "Privileged documents restricted to partners and associates"

  # Opposing counsel communication block
  - name: opposing-counsel-block
    tools: ["send_email", "draft_letter"]
    condition: "args.recipient_domain in context.opposing_counsel_domains"
    action: require_approval
    constraints:
      approver_role: "partner"
    response:
      message: "Communication with opposing counsel requires partner approval"

  # Client communication scope
  - name: client-communication-scope
    tools: ["send_email", "draft_letter"]
    condition: >
      args.recipient not in context.client_contacts and
      args.matter_id == context.current_matter_id
    action: deny
    response:
      error: "Recipient not authorized for this matter"

  # Billing integrity — Rule 1.5
  - name: matter-billing-only
    tools: ["log_time"]
    condition: "args.matter_id != context.current_matter_id"
    action: deny
    response:
      error: "Cannot log time to a different matter"

  - name: time-entry-validation
    tools: ["log_time"]
    condition: "args.hours > 8"
    action: require_approval
    constraints:
      approver_role: "partner"
    response:
      message: "Time entry exceeding 8 hours requires partner review"

  - name: duplicate-entry-check
    tools: ["log_time"]
    condition: "args.duplicate_within_hours == 24 and args.same_task"
    action: deny
    response:
      error: "Duplicate time entry detected within 24 hours"

  # Work product protection
  - name: work-product-export
    tools: ["export_document", "share_document"]
    condition: "args.document_type in ['work_product', 'privileged', 'draft']"
    action: require_approval
    constraints:
      approver_role: "partner"
    response:
      message: "Work product export requires partner approval"

  # External tool data flow — prevent privilege waiver
  - name: block-external-phi-flow
    tools: ["external_api_call", "third_party_search"]
    condition: "args.contains_client_data or args.contains_privileged_content"
    action: deny
    response:
      error: "Cannot send client data to external services without BAA"

Real-world scenarios

Cross-matter access prevented

A research agent working on Matter B attempts to access a case file from Matter A. The policy evaluates matter_id against the agent's current context and denies access instantly. The denial is logged with full context for the firm's compliance records. The agent never sees the document.

Privilege waiver blocked

An agent attempts to send privileged client information to a third-party API for analysis. The policy detects client data in the outbound request and blocks it, preventing an involuntary privilege waiver. The partner is notified of the attempted disclosure.

Opposing counsel communication intercepted

An agent drafting an email to opposing counsel is intercepted. The policy recognizes the recipient domain and routes to a partner for approval before sending. The full email context is logged regardless of the approval decision.

Billing anomaly caught

An agent logging 12 hours for a single task triggers the time entry validation rule. The entry is held for partner review. A duplicate entry for the same task within 24 hours is denied outright, maintaining billing integrity under Rule 1.5.

Build vs buy for legal AI

Capability	DIY	Veto
Client matter isolation
Privileged document access control
Opposing counsel communication block
Billing integrity enforcement
Partner approval workflows
External data flow controls
Audit trail for ethical compliance
Time to compliance	Months	Days

Related use cases

Healthcare Agents

PHI protection, HIPAA compliance, and EHR access control

Enterprise Agents

SOC 2, multi-tenant isolation, and role-based access

Frequently asked questions

How do client isolation policies work with multiple matters?

Each agent session is bound to a specific matter context. Policies evaluate the matter_id in tool arguments against the session's current_matter_id. If they don't match, the action is denied. This prevents accidental cross-matter access without requiring separate agent instances per matter. The isolation boundary is enforced at the authorization layer, independent of the agent's reasoning.

How does Veto help comply with ABA Formal Opinion 512?

Opinion 512 requires lawyers to understand how AI tools handle client data and implement adequate safeguards against unauthorized disclosure. Veto provides: data flow controls that block client data from reaching external services (Rule 1.6), partner approval workflows that demonstrate supervision (Rules 5.1/5.3), and immutable audit trails that document AI involvement in each matter (Rule 1.4).

Can policies distinguish between different document types?

Yes. Policies evaluate document metadata including type (privileged, work product, client communication, public filing), sensitivity level, and access restrictions. Different rules grant different access levels based on user role, matter involvement, and document classification. Privileged documents can be restricted to partners and associates on the matter.

How are partner approvals handled?

When a policy requires approval, the tool call is paused and routed to the designated partner. They see the full context: what the agent wants to do, the arguments, and the policy that flagged it. Approvals and denials are logged with the partner's identity, timestamp, and rationale — creating the supervision evidence required by Rules 5.1 and 5.3.

Can Veto integrate with existing practice management systems?

Veto operates at the tool-call layer and is agnostic to your practice management system. Matter IDs, client lists, opposing counsel domains, and user roles are injected as context when initializing the agent. Integration with Clio, MyCase, PracticePanther, or custom systems is straightforward through the SDK's context parameter.

Protect client privilege. Enforce ethical boundaries. Prove compliance.

Start free Read the docs Talk to us