Recommended check: this article is implementation guidance for managing partners, operators and AI practitioners. It is not legal advice, a compliance certification or a statement about any specific firm's systems.
Our interpretation: A natural question when evaluating an AI agent for intake, client communication or matter administration is whether it will refuse to do the wrong thing. That is a reasonable question, but it is not an adequate control. A refusal is something the model does. A control is something the system enforces whether or not the model cooperates. This article asks one question: where should a law firm's refusal controls live? The short answer, grounded in current OWASP guidance, is outside the model.
What the sources say, and what they do not
We have not certified the proposed implementation for any particular firm. We use the cited OWASP documentation as design guidance and recommend verifying the controls on the actual configuration.
- OWASP's Excessive Agency entry describes how an LLM-based system is often given the ability to call functions or interface with other systems. It defines Excessive Agency as the vulnerability that lets damaging actions occur in response to unexpected, ambiguous or manipulated model outputs, regardless of what is causing the model to malfunction. It also says the impact can span confidentiality, integrity and availability, depending on which systems the application can reach.
- OWASP's AI Agent Security Cheat Sheet says to enforce authorization in the execution component, outside the agent's context. It adds that a simple user_confirmed flag is insufficient.
- OWASP's LLM Prompt Injection Prevention Cheat Sheet explains that LLMs commonly process natural-language instructions and data together without clear separation. It also describes attackers generating many prompt variations until one slips past safety measures.
The sources do not establish legal duties for lawyers or failure rates for law-firm deployments or for the architecture proposed here. OWASP describes multiple mitigation approaches, including least privilege and downstream authorization. Applying those approaches to the workflow examples below is our recommendation, not evidence of measured performance.
Why a refusal cannot be the control
Our interpretation: The key phrase in the Excessive Agency definition is "regardless of what is causing the LLM to malfunction." The failure might be an ambiguous instruction, a confusing document or a deliberate manipulation. The framing treats the cause as secondary. What matters is that the system was able to take a damaging action at all.
Our interpretation is that the prompt-injection examples motivate controls outside model instructions. When instructions and data share the same channel, text inside a document can look like a legitimate instruction change. The cheat sheet's own example is a document summary request with an embedded line telling the model to ignore previous instructions. It also describes obfuscation, such as scrambled middle letters that keyword filters miss, and systematic variation, where small changes like random capitalization or spacing can find combinations that get past guardrails. It notes that LLMs respond non-deterministically to such variations.
For a firm, the practical reading (our interpretation) is this. A system prompt that says "never send documents without attorney approval" is a request to a probabilistic component. It may hold in your demo and in most production traffic. It is still not something you can show a regulator, an insurer or a client as an enforced boundary. If the only thing between the agent and an irreversible action is the agent's willingness to decline, the boundary is only as strong as the weakest input it ever reads.
Recommended architecture: four controls outside the model
This section is a recommendation from AlphaForge, informed by the OWASP excerpts above. It is not a standard and has not been validated as sufficient for any particular firm.
1. Deterministic authorization in the execution layer
Recommended check: One OWASP cheat sheet instruction is to enforce authorization in the execution component, outside the agent's context. In practice, the model proposes a tool call and a separate piece of ordinary code decides whether that call is permitted for this actor, this matter and these parameters. The decision uses rules and identity data, not model judgment. The model's opinion about whether an action is appropriate is never an input to the permission check.
2. Bounded tools and least privilege
OWASP’s Excessive Agency entry recommends limiting tools and permissions and enforcing authorization downstream. Our recommended application is to offer narrowly scoped tools, separate read-only and write identities where appropriate, and restrict records and actions to the task. We discuss the permissions question in our earlier post on excessive agent access. This is implementation guidance, not proof that a particular deployment enforces those boundaries.
3. Fail closed on unknown tools and missing approvals
The cheat sheet describes failing closed for unknown tools or missing approval requirements. In its example, two mapped low-risk tools skip human review; medium, high, critical and unmapped tools require it. It says this classification does not grant permission: the execution component must still check the actor’s authorization and any required approval for the exact action. Our recommendation is to block new or unlisted capabilities until their permissions and review requirements are defined.
4. Approval bound to the exact action, consumed once
This is the most specific guidance in the excerpt. A boolean saying a human clicked approve is not enough. According to the cheat sheet, the component must verify that the approval belongs to the current actor and the exact tool call, remains valid, and has not already been consumed. It should check and consume the approval in one atomic step immediately before execution so that concurrent or repeated requests cannot reuse it. If the target or parameters change, the action needs new approval.
For a law firm, imagine an attorney approving "send engagement letter to Client A." Under this design, that approval cannot be reused to send a different document, to a different recipient, or twice. Our recommendation is to make irreversible actions, such as outbound client communication, deletion, filing-related submissions and fee-related changes, always require this kind of approval.
A labeled illustrative example
The following is a hypothetical scenario for illustration. It is not an observation of any firm or product.
Our interpretation: Suppose an intake agent can read inbound emails, update CRM records and draft replies. A prospective client uploads a document that contains hidden text instructing the assistant to email the firm's conflict list to an outside address. In a refusal-first design, safety depends on the model noticing and declining. In an execution-layer design, the send-email tool is bounded to approved recipient domains, the conflict list is not readable by the intake identity at all, and any outbound message to a new address requires an approval tied to that exact message. The model may still be fooled. The system's impact is limited anyway. That difference is the point of moving the control.
Acceptance tests to run before go-live
These tests are our proposed acceptance criteria, offered as recommendations. Passing them does not certify a system as safe or compliant.
- Recommended check: Bypass the model entirely. Call each tool directly from a test harness with a fabricated unauthorized actor. Every call should be denied without involving the model. If the only reason a call fails is that the model declined, the control is in the wrong place.
- Recommended check: Replay an approval. Approve one action, execute it, then submit the same approval again, and submit it in two parallel requests. Only one execution should succeed.
- Recommended check: Mutate after approval. Approve an action, then change the recipient, matter or amount before execution. The system should require fresh approval.
- Recommended check: Register an unmapped tool. Add a tool with no risk classification. It should be blocked until someone classifies it and assigns an approval requirement.
- Inject through the data channel. Place instruction-like text in documents, emails and form fields, including obfuscated and varied forms; applying these examples to each input channel is our recommendation. Judge success by what the system was able to do, not by what the model said.
- Recommended check: Check blast radius. List every record and system each agent identity can reach. Compare that list to what the workflow strictly needs.
- Recommended check: Verify the audit trail. For each action, confirm you can reconstruct who approved it, which exact call was authorized, and when it was consumed.
What this does and does not establish
The sources establish the design direction: authorization belongs in the execution component outside the agent’s context, approvals must be specific and single-use, and prompt-level defenses face a real adversarial surface. They do not establish how any specific tool performs, how common these failures are in legal settings, or which duties apply to a given firm. Questions about professional responsibility, confidentiality and client consent require your own counsel and your jurisdiction's rules. I have not assumed any.
Nor do I claim that any firm today is exposed. Whether a particular deployment has excessive agency is a hypothesis that requires looking at its actual tools, credentials and approval paths.
Questions for a managing partner to ask this quarter
- Recommended check: For each agent we run or are evaluating, which actions are irreversible, and what code, not the model, stops them?
- Recommended check: Does an approval in our system bind to an exact action, and can it be used only once?
- Recommended check: What happens when someone adds a new tool or connector? Is the default blocked or allowed?
- Recommended check: Can the vendor show us a test where the model is bypassed and the call is still denied?
- Recommended check: Who owns the list of what each agent identity can reach, and when was it last reviewed?
Recommended check: If those answers are unclear, that is useful information. It may mean the firm's current assurance rests on the model's good behavior, which is the component you cannot fully predict. Move the boundary into the execution layer, test it without the model in the loop, and treat refusals as a helpful extra layer, not the barrier itself.