Use Cases/Legal Agents

Legal AI needs action policy, not just model policy.

ABA Formal Opinion 512 (July 29, 2024) says lawyers using generative AI must consider competence and confidentiality duties under the Model Rules and make reasonable efforts to protect client information. If an agent can send privileged material to a third-party system without review, the risk is not theoretical. Veto gives legal teams a policy boundary before a governed tool call executes.

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 gives legal teams the evidence record those duties need: what the agent tried to do, which boundary applied, and who approved exceptions.

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

Privilege risk increases when AI tools 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 create privilege-waiver risk for the 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 review 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 audit records for compliance review.

ABA Model RuleObligationVeto Policy
Rule 1.6: ConfidentialityBlock unauthorized disclosure of client informationMatter isolation, document access control, communication restrictions, data flow controls
Rule 1.1: CompetenceUnderstand AI tool capabilities and limitationsScope boundaries keep agents inside designed practice areas
Rule 1.4: CommunicationInform clients about AI use in their matterDecision records document AI involvement for client disclosure
Rule 1.5: FeesReasonable fees, accurate billingTime entry validation, duplicate detection, matter-scoped billing
Rules 5.1 and 5.3: SupervisionSupervise AI as nonlawyer assistantHuman approval workflows, partner review for review-required actions
Rules 3.1 and 3.3: CandorDo not present fabricated citations or authoritiesOutput verification policies, source validation requirements

Client isolation and document access policies

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

veto-policy.yaml
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 denied on the governed path

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 at the policy layer. The denial is recorded with decision context for the firm's compliance records. The agent receives only the approved result, not the source document.

Privilege risk 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, reducing involuntary privilege-waiver risk. 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 recorded 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

CapabilityDIYVeto
Client matter isolation
Privileged document access control
Opposing counsel communication block
Billing integrity enforcement
Partner approval workflows
External data flow controls
Evidence record for ethics review
Path to evidence reviewCustom buildWorkflow-scoped

Related use cases

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 do not match, the action is denied. This blocks accidental cross-matter access without requiring separate agent instances per matter. The isolation boundary is enforced at the authorization boundary, independent of the agent's reasoning.
How does Veto support ABA Formal Opinion 512 review?
Opinion 512 requires lawyers to understand how AI tools handle client data and implement adequate safeguards against unauthorized disclosure. Veto provides: data flow controls for governed external-service calls (Rule 1.6), partner approval workflows that demonstrate supervision (Rules 5.1/5.3), and decision records that document governed 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 decision context: what the agent wants to do, the arguments, and the policy that flagged it. Approvals and denials are recorded 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 privilege. Enforce ethical boundaries. Keep the records.