An AI tool reading a matter creates a different risk from one changing the record or sending work outside the firm. Agent permissions should therefore attach to the action and its consequence. Giving a product access to a matter should not automatically authorise every tool the product can call. A practical model needs to distinguish reading, analysis, proposed changes, approved writes and external action.

Level 1: Read

A read permission allows the agent to retrieve information the user is already authorised to access. Examples include opening a document, reading a factual record, retrieving a matter profile or checking the status of a task. The control should inherit the firm's existing permissions. An agent acting for one lawyer should not bypass an ethical wall or see a document the lawyer cannot open directly. Read access can still create risk. The material may contain privileged, confidential or personal information. The agent may combine several authorised sources into a sensitive inference. The system should record what was accessed and keep the scope tied to the assigned task.

Level 2: Analyse

Analysis allows the agent to transform the material without changing the underlying systems. It might identify relevant documents, extract facts, compare witness accounts, classify transactions or propose a chronology. The output should remain reviewable. The lawyer needs to see the source, the scope of the material considered and any failure that affected the result. An analysis permission should not imply that the system may adopt its own conclusion as the matter's reviewed state. The model can propose that two names refer to the same person. Another step is required before that decision affects the rest of the team.

Level 3: Propose

A propose permission allows the agent to create a candidate change or work product for approval. Examples include: a proposed correction to a date. a suggested merge of two entities. a draft request for admission. a recommended document classification. a draft email or filing. The proposed action should show its basis and consequence. A reviewer should be able to see which facts, documents and rules produced it. The proposal must remain separate from the approved state. A draft email should not be sent. A proposed factual correction should not alter later outputs for the whole matter until an authorised person approves it.

Level 4: Write

A write permission changes a governed internal system. The agent may update the factual record, create a task, save a new document version or write approved metadata back to another platform. This level requires more than a general instruction such as "help with the matter". The system should know: which object may be changed. which fields are in scope. who authorised the change. whether the action is reversible. what audit history is required. A write can be low risk or highly consequential. Correcting a typo in a private note is different from changing the reviewed date of a material event across the matter. Permission should reflect that consequence. The correction article sets out how proposed and approved factual changes should be stored.

Level 5: Act externally

External action sends, files, discloses or communicates something beyond the controlled internal environment. Examples include sending an email, sharing a document with a client, filing material with a court, issuing a discovery request or changing a deadline in a system used by other parties. These actions should require clear confirmation of: the recipient or destination. the exact content. the purpose. the authority relied on. the material being disclosed. A general approval at the start of a long workflow is weak where the final content and destination were not yet known. Confirmation should occur close to the external action. Some repetitive, low-risk actions may later be automated under a defined policy. The policy should identify the permitted action, scope, recipient class, monitoring and stop conditions.

Tool descriptions are not enforcement

MCP tools can include annotations indicating whether a tool is intended to be read-only, destructive or idempotent. Those annotations are useful risk vocabulary. The MCP project also states that they are hints. An untrusted server can claim that a tool is read-only and behave differently. The annotation does not enforce the boundary. Hard controls belong elsewhere: the identity and authorization layer. the server's actual scopes. the host's approval policy. the application's business rules. network controls and sandboxing. the audit record. The same applies outside MCP. A button labelled "draft" should not be the only thing preventing a generated email from being sent.

Permission should be specific to the user and matter

A partner, associate, paralegal, litigation-support professional and external expert may have different authority in the same matter. The agent should operate with the user's identity or a clearly defined service identity. Shared credentials make it difficult to understand who authorised an action and which permissions should have applied. Matter-level restrictions also matter. A user may be able to use a drafting agent on one matter and be barred from entering information from another. A client instruction may prohibit a particular AI service even where the firm's general policy permits it. Permissions should be evaluated at the time of the action because staffing, ethical walls and client requirements can change.

The lawyer's duty remains

ABA Formal Opinion 512 applies existing duties of competence, confidentiality, communication and supervision to generative AI. The Federal Court of Australia's GPN-AI likewise keeps responsibility with the people using the technology and requires particular care around filed material and protected information. Those obligations do not dictate one technical permission model. They do require the firm to understand the system's capabilities and limitations, protect client material and review work before relying on it. A permissions model makes that responsibility operational. It identifies which decisions remain with a person and prevents a broad tool connection from becoming broad authority to act.

Test the permission boundary

A product evaluation should include attempts to cross each boundary. Test whether the agent: can retrieve a document outside the user's permission. treats analysis as approved fact. writes a proposed correction before approval. sends or shares content without a final confirmation. follows a malicious instruction found inside a source document. records the action and the user who authorised it. can reverse an internal change. The test should use realistic matter permissions rather than an administrator account with access to everything. The known-matter test can include these governance checks alongside accuracy and omissions.

A minimum policy

A firm adopting agents can begin with a simple default: read and analyse within existing user permissions. require explicit approval before changing reviewed matter state. require confirmation before external communication or filing. record every write and external action. grant broader automation only for a defined workflow with monitoring. That policy can become more detailed as the firm learns which tasks are stable enough to automate. The useful distinction is between an agent that can produce a suggestion and one that has authority to change the legal work around it.

Verification in Legal AI Is a Design Problem

A Permission Model for Legal AI Agents: Read, Propose and Act

A practical permission model for legal AI agents, separating access to information from the authority to change a matter or act outside the firm.