An experiment published in The New Stack reveals that granting an AI agent broader permissions than it needs can turn a simple logical error into a repeated financial action that the model does not stop on its own. In a test involving customer invoices, a support agent confirmed that a payment had failed and that the customer’s funds had not been withdrawn, but it issued a refund even though the facts did not support doing so, repeating the error five times.
Claude Sonnet 5 successfully detected the six cases designed to test this flaw, while Claude Haiku 4.5 failed in all of them. A single line in the system instructions asking the agent to verify the transaction status before carrying out a financial action also addressed the problem. However, the author considers both solutions fragile: an organization might replace the model with a cheaper version or modify the instructions during an experiment, causing the protection to disappear without a clear warning.
Denied Permission as a Security Barrier
The protection that withstood these changes was preventing the agent from having the billing:refund permission in the first place. In that case, execution failed at the permissions layer, regardless of the model or the wording of the instructions. This is the conclusion of the principle of least privilege in the architecture of AI agents: the goal is not only to stop attackers or protect secrets, but also to prevent a well-intentioned agent from quickly carrying out incorrect instructions automatically and without human oversight.
An agent differs in nature from a traditional service account that performs a fixed function. A support agent might read a ticket at 09:00, issue a refund at 09:04, and change the number of seats at 09:11. Therefore, the set of permissions required for all of its potential activities over a week does not necessarily reflect what it needs for a single task.
What Did the Experiment Measure?
The author built a test environment containing 30 permissions distributed across nine domains in a fictional enterprise API, including tickets, users, billing, subscriptions, files, messages, auditing, administration, and search. Thirteen permissions were capable of modifying or extracting state. The experiment included 20 tasks, each with an outcome that could be verified automatically, such as closing a ticket or refunding an invoice.
Four permission models were compared across Claude Haiku 4.5 and Claude Sonnet 5, for a total of 160 runs:
- Broad permission: A long-term grant containing all 30 permissions.
- Fixed role: A support role containing 17 permissions derived from a typical job description.
- Task-based restriction: Granting the permissions required for each run and revoking them when it ended.
- Just-in-time activation: Starting with no permissions and requesting each permission when needed, along with its justification.
Task-Based Restriction Reduces the Scope of Harm
The task-based restriction model achieved complete task completion while using approximately one-fifteenth as many permissions as the broad grant. Occasional denials and retries did not materially increase the number of API calls.
The fixed-role model was the weakest on both dimensions. It granted 17 permissions, including four that no task used, while lacking nine essential permissions. Expanding the role until all tasks succeeded would have required 26 permissions, compared with a median of only two permissions per task. Thus, the fixed role becomes both too broad and insufficient at the same time because it bases the decision on the job title rather than the actual work.
The just-in-time activation model achieved a similarly low level of harm exposure, but required approximately 80% more API calls. Permission denials in the task model were generally for optional exploratory paths, whereas denials in the fixed-role model were final because they blocked an essential permission.
Why Does This Matter to Organizations?
The results show that model capabilities and system instructions are defensive layers that can change, while a permission that has not been granted remains effective even when the model is switched or the prompt is modified. Teams should therefore design agent permissions around the current task and make sensitive permissions temporary and auditable, rather than collecting them in a broad permanent role.
The experiment remains limited by its synthetic environment, 20 tasks, and two Claude models; therefore, it does not prove that the results will match those in every organization or with every model. However, it offers a clear practical indication: testing the agent is not enough if the architecture allows it to perform actions it does not need, because changing the model or instructions may alter its behavior while its ability to cause harm remains in place.