A support agent may be allowed to draft a customer reply while being prohibited from sending it. If it produces the words "I cannot send that" and still calls the sending tool, the refusal has failed. The user-facing message and the execution decision need to agree.
Design rejection at the point where a proposal becomes an action. The model can identify ambiguity and explain a boundary. The application and downstream system enforce permission, required inputs and review conditions.
This follows the mitigation direction in OWASP's Excessive Agency guidance: narrow tool functionality, limit downstream privileges, and validate requests against authorization policies rather than delegating that decision to the language model.
Choose the response that resolves the boundary
Refusal is useful when the requested action cannot proceed. It is wasteful when a precise clarification or an authorized alternative would resolve the task. Separate these responses before choosing message copy.
| Condition | Response | What stays blocked |
|---|---|---|
| The caller lacks permission for the operation or target. | Deny the operation. Offer an authorized route if one exists. | The denied action; another agent cannot inherit permission from the handoff. |
| A required input is missing or inconsistent. | Ask for the specific input, or route its correction to the responsible source. | Actions that depend on that input; independent permitted work can continue. |
| Evidence does not support a consequential answer. | Abstain from the conclusion, state the evidence gap and offer review. | Representing an unsupported conclusion as established fact. |
| The action is permitted but requires approval. | Prepare the bounded action for an authorized reviewer. | Execution until the required approval and current permission checks pass. |
| The task is outside the product's supported scope. | Explain the scope boundary and route the request where appropriate. | An unsupported action; permitted assistance can remain available. |
These are proposed workflow distinctions, not a universal taxonomy. The same missing field can warrant clarification in a drafting task and block a financial write. Define the dependency on the field instead of treating every data-quality problem as a permanent hard stop.
A transient tool failure is different again. A permitted retry may be appropriate when the operation's effect is known and the retry policy allows it. If a write may already have taken effect, inspect the operation receipt before retrying. A timeout is not proof of non-execution.
Put authorization outside the model
Check the effective principal, operation, target and payload at the execution boundary. A read-only tool or credential should remain read-only even if the model proposes a write. Removing unnecessary actions from the available tool set narrows what it can propose; downstream permissions determine what it can execute.
The model's refusal text is not the guard. A field such as refused: true in a generated object is not the guard either. Both can disagree with a queued tool call unless the executor checks the same authoritative policy. Blast Radius Engineering develops the related tool-permission boundary.
Apply authorization to the proposed effect, not merely to the tool name. A permitted export function can still receive an unauthorized tenant, destination or record scope. Recompute the check for each operation in a multi-step workflow. Several individually permitted reads may produce a combined disclosure the workflow does not authorize; define any aggregate limit in the policy and test it.
Refusal after execution is incident handling. It cannot retroactively prevent the effect. Keep the execution receipt and the recovery path distinct from the earlier decision to permit or deny.
Confidence is evidence to validate, not permission
A model's self-reported confidence does not grant authority. Where uncertainty controls whether an answer is shown or routed to review, validate the signal on representative tasks and the kinds of error that matter to that workflow.
In Language Models (Mostly) Know What They Know, Kadavath and colleagues found useful self-evaluation under tested conditions, while reporting difficulty calibrating a learned "I know" estimate on new tasks. That supports testing the estimate's transfer; it does not establish a confidence threshold for your agent.
Choose an abstention policy using held-out examples, measured error among answered cases, and the fraction of requests the policy answers. Track false refusals separately: correctly rejecting an unauthorized write and incorrectly rejecting a permitted read are different outcomes. An apparent improvement can come entirely from refusing more work.
Evaluate ambiguous and shifted inputs alongside ordinary requests. If a new model, tool, document source or user population changes the task, repeat the relevant calibration and boundary tests. Describe unsupported uncertainty as uncertainty; do not convert fluent output or a high self-assessment into proof.
Make escalation executable by the recipient
A review request needs the intended action, its target and scope, the reason it paused, the supporting evidence references, and the decision required from the reviewer. Include only material that the reviewer is allowed to receive. A brief justification is sufficient; collecting hidden chain-of-thought or forwarding unrestricted conversation history does not establish a better authorization check.
Bind an approval to the reviewed operation and payload, with the workflow's validity conditions. If the payload, target or permission changes while review is pending, check again before execution. Approval of a draft message does not authorize a later version addressed to a different recipient.
Give pending work a visible state and a named destination. If no authorized reviewer is available, say which action remains pending and what can still proceed. The agent should not retry the same denied action through another tool or account to manufacture completion.
After cancellation, distinguish a cancellation request from confirmed prevention of the effect. If a downstream operation already committed, use its receipt and the approved recovery path. The phrase "stopped" is misleading when only the local workflow stopped waiting.
Test the effect as well as the wording
Use an instrumented executor or sandbox to observe calls and effects. The following cases are an acceptance design, not executed production results:
- Submit a write through a read-only principal. Assert that no write reaches the downstream system, even if the model proposes it or claims high confidence.
- Supply a required-field defect. Assert that the dependent action remains blocked and that the clarification names the missing field; test a permitted independent action separately.
- Approve an action, then change its payload or revoke permission. Assert that the old approval cannot execute the changed or newly unauthorized action.
- Give the model untrusted content instructing it to bypass review. Assert that the executor retains the permission and approval boundary.
- Test a legitimate request near the same boundary. Assert that the agent completes it or asks the necessary clarification without an unnecessary denial.
- Simulate a timeout after a write commits. Assert that the agent checks the effect before retrying and reports the receipt accurately.
Report attempted actions, permitted actions, denied actions and review outcomes as separate populations. A refusal rate alone mixes safety decisions with product failures. Inspect whether denied actions caused effects and whether legitimate requests still reached completion.
If a denied write appears in the downstream audit log, treat it as an incident and follow the recovery path. The refusal message cannot undo the write.