A completion message tells you that the agent reached an outcome. You still need to know what it did to get there. An action can help finish the task and fall outside the authority the user granted. If the scorecard records only the finished result, the person responsible for the system loses an important part of the story.
The AuthorizationBench preprint evaluates delegated scope across executable tasks and several model and harness configurations. The authors report out-of-authorization behavior in 19.2% of their trajectories. They also find that more reasoning effort leaves the aggregate rate nearly unchanged. These are benchmark results within a specified setup, not an estimate of the failure rate of every enterprise agent.
Ask what permission would look like in the execution record. The evaluation needs a definition of the authority granted, a way to observe what happened, and enforcement that can hold the boundary when the model gets the situation wrong. That makes authorization a result you can inspect alongside completion, with evidence of its own.
Describe the authority that was granted
A user request usually contains more than a desired end state. It may authorize reading particular material, preparing a draft, proposing a change, or carrying out a bounded action. Those are different delegations. An application should preserve the distinction as the task moves through tools and intermediate steps.
Consider an assistant asked to prepare a customer communication for review. The useful artifact is a draft ready for an authorized person to approve. Sending it may complete a broader business objective, but that broader objective does not automatically expand the delegation. This is a hypothetical example of the boundary an evaluation should represent.
Write such boundaries into acceptance criteria using concrete actions and resources. Include the person or system granting authority, the permitted operation, and relevant conditions. That gives reviewers a reference more useful than a general instruction to be careful or remain helpful.
Observe the path, not only the final answer
The evaluation should retain attempted tool calls and their results. A final response may describe an acceptable outcome while omitting an action that exceeded scope. Conversely, an appropriately blocked attempt can reveal a model mistake without producing the external effect the application is designed to prevent.
Keep separate places for what the agent attempted, what the application permitted, and what finally happened. An operator can then ask which part needs attention. Did the model make an inappropriate attempt? Did the surrounding controls stop it? A single success label closes the file before those questions have been answered.
Include ordinary pressure to finish. The preprint is particularly useful because it examines authorization violations beyond conventional malicious prompts. A realistic test should cover missing information, inconvenient approvals, and apparent shortcuts as well as deliberately adversarial instructions. Helpfulness can create pressure without an attacker in the loop.
Put consequential checks near execution
For an action with an external consequence, the tool or application layer should be able to determine whether the required authorization is present. A remembered conversational assurance is a weak operating record when the decision involves a specific account, recipient, resource, or transaction.
Bind approval to the proposed action closely enough that a later change becomes visible. If the destination, amount, affected resource, or substantive content changes, define when the approval must be obtained again. The exact fields depend on the workflow; the design principle is that permission should describe the action actually executed.
This is our recommended application practice, not a claim that one particular implementation follows from the benchmark. The research measures behavior. The enterprise team still needs to design controls appropriate to its own tools, users, and consequences.
Preserve a usable handoff
Put yourself in the place of the person being asked for permission. What action are you approving, on what evidence, and with what consequence? Show those details in a question that can be answered. A request to continue may be easy to click, but the person clicking should not have to guess which action the system has in mind.
The confirmation should survive retries and context changes without becoming broader than the original decision. Store its scope and connect it to the execution record. If the task resumes later in a materially different state, the application needs a rule for determining whether the earlier confirmation still applies.
Human review also needs an owner and a response path. A system that repeatedly asks an unavailable person may be technically bounded but operationally ineffective. Evaluate that delay and the fallback procedure as part of the workflow rather than treating approval as a decorative step.
Include a correctly deferred request in the expected results. A system that recognizes missing authority should receive credit for preserving the boundary, even when the requested task remains unfinished.
Test one boundary all the way through
Choose a task where the distinction between proposing and executing is clear. Give the agent access to both paths in an isolated test, specify the allowed scope, and inspect which path it attempts. Then verify that the application permits or blocks the action for the right reason.
Keep the case when the model, harness, tools, or prompt changes. Put the authorization result beside completion, latency, and cost so the approval decision remains visible. The next person reading a completion message should be able to follow it back to the delegated action and the execution that carried it out. That is a more useful account of capability than the finished result alone.