As of October 2026, we recommend showing a law-firm reviewer the exact message, recipient, and attachments before an automated assistant sends anything the firm has designated for approval. The useful question is what that person can check before a proposed action becomes a real communication or record change.
Imagine a fictional intake exercise. An assistant prepares an acknowledgement for someone asking about a probate consultation. Your firm has decided that staff must review this kind of message before sending. We recommend making the next step clear: show the proposed message and its destination, give the reviewer an understandable decision, and stop if the approved details change.
Begin with the firm's decision about the task
We recommend agreeing on which activities need approval before choosing a screen or a vendor setting. Separate reading permitted information, preparing a draft, and carrying out an action. For each task, record what the assistant may do, what it must not do, and who can authorize an exception.
For example, the firm might permit drafting an acknowledgement from approved wording while requiring staff review before sending it. Treat that as a proposed operating arrangement for discussion, not a statement about what every firm needs or what its professional duties require. Have the firm's responsible reviewers make those decisions for the actual task.
OWASP's Excessive Agency guidance recommends limiting tools and permissions to what the application needs. It also recommends a human-in-the-loop control so a person approves high-impact actions before they are taken, and authorization in downstream systems rather than relying on the language model to decide whether an action is allowed. That is voluntary technical guidance, not a rule establishing a law firm's legal obligations.
Show the proposed action clearly
We recommend a review request that explains what will happen in ordinary language. For the fictional acknowledgement, show the full proposed message, the recipient, the sending account, any attachments, and the inquiry it relates to. If the assistant also proposes changing an intake record, show the current and proposed values separately.
Include the information the reviewer needs to decide, while avoiding unnecessary copies of private material. Identify the relevant source record and let the authorized reviewer inspect it through the firm's approved system. Ask whether the person can understand the request without reconstructing a long chat conversation or opening unrelated client records.
Make the available choices explicit. We suggest approving this action once, rejecting it, returning it for correction, or passing it to a named authorized reviewer. Explain which choice leaves the message unsent. If the reviewer edits the recipient, message, or attachment, request approval of the corrected version before carrying it out.
Keep approval attached to what was reviewed
OWASP's AI Agent Security Cheat Sheet says the component executing an action must verify that approval belongs to the current actor and exact tool call, remains valid, and has not already been consumed. It recommends checking and consuming approval in one atomic step immediately before execution so concurrent or repeated requests cannot reuse it.
For the fictional message, we recommend testing whether approval applies to that recipient, that text, and those attachments only. Ask the implementer to demonstrate what happens if any of those details change. A staff member should not need to infer from a button label whether a different message will be sent.
Where permissions belong in the first place is a separate design question. Our reading of the downstream-authorization guidance cited above is that the permission decision should sit outside the model; that is our inference, not a statement OWASP makes about this checklist. We cover that placement in our article on placing refusal controls outside the model. This checklist stays with the review step: what the person sees, which decision they make, and what the system verifies before acting.
Ask what happens when review cannot proceed
We recommend writing down the expected result when a request expires, a reviewer lacks authority, or the system cannot verify the approval. The same OWASP cheat sheet advises failing closed when an approval requirement is missing or a tool is unknown. For an action the firm has placed behind approval, the proposed result is to leave it unexecuted and tell the responsible owner what needs attention. Avoid silently treating an unavailable review step as permission to continue.
Name a backup reviewer where the firm's process needs one. Keep each person's identity distinct and agree on the actions that person may authorize. Ask the implementer how the record will show who made the decision and whether a request was rejected, corrected, expired, or completed.
We also recommend deciding how staff handle an urgent inquiry while the automated action is held. Document an approved manual process and its owner. Do not solve a review outage by removing the restriction from the assistant or lending it another person's account.
Keep automated checks and human decisions distinct
OWASP's prompt-injection guidance recommends human approval for consequential tool actions, based on the proposed operation, target, arguments, and caller's authority rather than keywords in the incoming prompt. It describes a separate model as a possible filter that sits alongside deterministic controls, not in place of them. This supports reviewing the proposed action instead of judging risk from the wording of the incoming request.
OpenAI's auto-review report is vendor-published material describing how a separate agent reviews requests to act outside a sandbox in its Codex tool, in place of user approval at that boundary. Its authors say red-teaming found cases where the reviewer could be misled into approving commands without user approval, and that the approach should not be treated as a security guarantee. We cite it only as an example of automated review. It is not evidence that a human reviewed a proposed action, and it does not show that the same arrangement suits a law firm's task.
We recommend labeling the decision accurately in the firm's records. If a machine check assessed a request, record the machine check. If a named person approved it, record that person's decision and what they saw. Ask the implementer to explain which checks can reject work and which requests still require a person.
Run a short approval exercise before expanding use
The following tests are proposed acceptance checks using fictional inquiries and permitted test accounts. These are recommendations, not results measured at a firm. Passing them is not a legal or security certification. Agree on expected outcomes with the firm's reviewers before the exercise.
- Change the recipient after approval. Test that the original decision does not authorize sending to the new destination.
- Change the message or attachment. Check that the revised communication returns for approval before sending.
- Check whether an approval can be reused. Try the same approved request again and in parallel. Ask the implementer to show that only the authorized execution occurs.
- Use an expired or unauthorized decision. Confirm that the proposed action remains unexecuted and the reason reaches its owner.
- Test what happens when approval verification is interrupted. Test the agreed failure case and confirm staff can follow the documented manual process without removing the assistant's restriction.
Keep a record the next reviewer can understand
For each exercise, record the proposed action, the reviewer, the decision, and the actual result. Retain references to the reviewed version and relevant source material under the firm's access and retention arrangements. We recommend collecting enough information to reconstruct the decision without turning the review record into another uncontrolled copy of client information.
Use the exercise to identify a concrete next step: clarify an instruction, correct a permission, improve what the approval request displays, or leave the task with staff. The OWASP agent cheat sheet advises structured security testing before production and again after material changes to prompts, tools, memory, retrieval, policies, or model providers. In the same spirit, we recommend repeating these checks whenever the assistant gains a new connection or permission. The goal is a review process the firm's people can explain and test before giving the assistant more responsibility.