Key takeaways
- Specify permissions for individual actions, including who can receive or act on an output.
- Make human review practical by showing supporting information and measuring review effort.
- Use task-specific tests before changing access; set a named owner and a way to stop the action.
An assistant that drafts an invoice needs different permissions from one that posts it to the accounts. A support tool may need access to a customer’s order without permission to issue a refund. Make those distinctions when configuring the software, while the business owner decides which actions require approval.
Start with a list of actions the proposed system would perform. For each, record which information it reads, what it can change and who could be affected by a mistake. Include mistakes that are hard to detect, such as assigning a valid invoice to the wrong account.
OWASP’s 2025 guidance on excessive agency identifies unnecessary functions, permissions and autonomy as sources of risk in applications using language models. It recommends limiting tool capabilities and requiring human approval for consequential actions. Instructions in a prompt should be backed by controls in the connected software.
Define permissions for specific actions
The following arrangements can be combined within one application. Choose an approval requirement for each action and name the person who can change it.
Possible approval arrangements
| Arrangement | Example design | Person responsible |
|---|---|---|
| Read and summarize | An assistant reads approved documents and produces a summary visible only to its user. | The information owner approves access and sharing rules. |
| Prepare for approval | An assistant drafts a customer reply but cannot send it. | The reviewer checks the reply and recipient before sending. |
| Act within a narrow rule | Software applies an approved tag only to records meeting stated conditions. | The process owner defines the conditions and reviews errors. |
| Refer exceptions | A tool stops when a required field is missing or a requested action exceeds its permissions. | A named team handles the queue and can complete the task manually. |
Proposed workflow options.
Meeting notes can contain personal information; changing a customer record can affect another system that reads it later. Include everyone who can see or act on an output when reviewing permissions, along with any downstream software.
Give reviewers enough information to decide
An approval screen should show the proposed action, affected records and supporting information. A reviewer approving a draft quote needs the price, recipient and applicable terms. Ask the reviewer to confirm that they can check those details without recreating the entire task.
Measure review time during a trial, along with edits and rejected actions. A high approval rate could reflect good output, easy cases or hurried review. To distinguish them, have a second reviewer independently examine a sample and compare findings. Choose the sample around the kinds of mistakes the business needs to catch.
Test a permission change before extending access
Before allowing a new action, specify the cases it covers and the evidence needed to approve it. Test normal cases, missing information, unusual requests and failed tool calls. Include attempts to act outside the allowed customer group, record type or spending limit.
NIST’s AI Risk Management Framework leaves acceptable risk levels to organizations and their circumstances. A universal score cannot decide whether your particular refund, hiring or payment process should be automated.
For a change that does proceed, name someone who can disable the new action and restore the previous workflow. Agree which incidents require an immediate pause and who investigates less severe errors. Keep the ability to pause separate from the model’s own judgment about whether it made a mistake.
Record the approved permissions, test results and unresolved limits with the release. Revisit them when a connected system, customer group or business rule changes. An approval for one application should not silently become approval for a new use of the same model.
