An AI agent should perform only explicitly authorized actions within a defined process. Answering a question, preparing a proposal and committing the business to a promise involve different responsibilities. Connected systems need to enforce those limits, and observable outcomes need to confirm that they work.
An assistant can sound confident while missing an essential fact. Confident wording cannot stand in for commercial approval. The useful questions are specific: what can the system read, what can it change and who is responsible for that change?
Start with the action
In a hypothetical showroom scenario, the same assistant might explain opening hours, prepare a viewing request and suggest an available appointment. Each action has different consequences.
Reading public opening hours does not require access to every customer record. Suggesting a time does not reserve it. Confirming a visit requires a successful operation in the booking system, under the conditions the user accepted.
We would define permissions for each step. If the process does not need a function, the system should not receive access simply because an integration offers it.
| Possible action | Design condition |
|---|---|
| Explain public information | Use an approved, current source |
| Prepare a summary | Separate stated facts from unknowns |
| Record a request | Collect the required details, check access and prevent duplicates |
| Confirm an appointment | The user has selected it and the booking system has confirmed it |
| Offer an exceptional discount | Obtain approval from the designated commercial role |
| Change a contract | Follow a separate authorization and review process |
This is one possible allocation of responsibilities. Final limits depend on the service, the consequences of an error and how the company operates.
Permission has to exist beyond the conversation
An instruction to avoid discounts is useful, but the connected system also needs to restrict available operations. If a tool can apply any discount without an independent check, the conversation becomes the only filter for a commercial decision.
OWASP discusses excessive agency in terms of the functions, permissions and autonomy available to a system. We would address that concern through access limited to necessary operations and checks proportionate to their consequences.
Identity matters too. A product question can receive a public answer. A request about an order needs to be connected to a verified customer before private order details are displayed. Knowing an order number should not automatically be treated as sufficient proof.
What about instructions inside documents?
A document submitted for a quote may include technical requirements alongside text asking the system to ignore its rules or disclose other information. Incoming content is material to analyze. It does not acquire authority to change the process permissions.
This is a type of issue covered in OWASP’s prompt injection guidance. In our example, a document may inform the brief, while action approval remains part of a separate authorization mechanism.
A reviewer needs enough information to decide
Approval is useful when the reviewer can see what will happen: the recipient, the information used, the proposed commitment and any unresolved questions. An approval button beside an incomplete summary may transfer responsibility without improving the decision.
We would also show relevant sources, changes from the original request and the next step. For sensitive operations, we would establish who can approve them, how the decision is recorded and how the process can be stopped.
How do we test the boundaries?
Include requests the system should decline or hand over: another customer’s order, an unauthorized discount, conflicting information, an unavailable integration or a repeated submission. Check the resulting system state as well as the displayed response.
At NOT MORE., we can define these responsibilities with your team, then design and implement the agreed process. More autonomy becomes useful when the process, permissions and evaluation support it.
Which action would you allow the system to complete independently, and what would you want to see before approving it?