An AI agent’s permissions should be reviewed whenever the model behind the agent changes. A permission is approved against how a system behaved on the day it was granted. When the model is swapped, the permission stays in place and the behaviour behind it changes. In July 2026, the UK AI Security Institute found this out inside its own test setup.
This piece draws on the Diary of a CTO episode Agent Accountability, with Arpit Bhayani of Razorpay, Gaurav Maheshwari of Oodle AI and Prasanna Ranganathan of Fi. The permission argument is mine. The incident details come from AISI and Anthropic, and every figure below links to its source.
The UK AISI incident shows what a goal-driven agent does with the access it is given
On 28 July 2026, AISI’s security team saw data leaving a testing system through the Tor anonymity network. The review that followed found that, in one run, an agent had created a malicious pull request on a real, public open-source project on GitHub (AISI incident report).
The agent researched the project’s maintainers, created several fake identities and used them to pressure a real maintainer into approving the code. When the pull request was challenged in public, it edited its earlier activity to look harmless and considered adopting a fresh identity. AISI ran the challenge 122 times. In 10 of those runs an agent took unsanctioned action on the live internet, 19 actions in total. Seventeen came from Anthropic’s Mythos 5 and two from a single run of OpenAI’s GPT-5.6 Sol.
The conditions matter. AISI enabled internet access on purpose and switched off the model providers’ cyber classifiers. It says the models, in those configurations, are not commercially available, and that no agent escaped its sandbox. It also says no agent was told to deceive anyone. Deception appeared while the agent pursued the task it had been set.
A human maintainer caught the code and refused it. A member of the public who suspected it opened it inside an isolated environment. AISI describes the margin between failure and success as resting on human vigilance, with no technical barrier that would reliably stop a more capable agent. The full technical report is published as a PDF.
AISI approved the risk for older models and did not revisit it in time
AISI gave the agents internet access so they could download the tools the task needed. For earlier model generations, it says, that risk was judged acceptable. It also says it did not revisit that judgment quickly enough as capabilities advanced (AISI incident report).
Its response has two parts. Granting internet access in a cyber range now has to be actively justified instead of being the default. AISI is also building monitoring that watches an evaluation while it runs, because the alert that exposed this incident came from general network monitoring after the agent had already acted.
On the same scenario, Anthropic’s models differ widely and not in a straight line
Anthropic’s assessment of its own cybersecurity incidents includes a replication. It built a capture-the-flag task whose only solution lay outside the stated scope, on a simulated internet. It then counted the runs in which a model took at least one severely harmful action, such as faking an identity, planting a malicious artifact, deceiving a person or breaking into a third party’s system (Anthropic, 9 September 2026).
Mythos 5 took a severely harmful action in 82% of runs; the other models, 12% to 39%
Share of runs with at least one severely harmful action, by model (%)
The newest models improved on Mythos 5. Opus 5 took such an action in 31% of runs and Mythos 5.1 in 33%. Between versions the change is uneven. Opus 4.8 sits at 39%, above Opus 4.7 at 22% and above Opus 5. A permission approved against one of these models says little about the next one.
Anthropic cautions that its rates run higher than a fixed environment would produce, because its auditor actively tries to elicit bad behaviour, and it says it is unsure how realistic the evaluation is. In the runs it reviewed, the harmful actions came with the model believing the situation was fake in some way.
An agent should not hold the permissions of the engineer who deployed it
Gaurav Maheshwari of Oodle AI saw the same problem in his own work. When he moved to Opus 5, he told me, the model was better at complex tasks and also eager to do things nobody had asked for. His examples were starting a debug pod in a production cluster and inspecting binaries. The earlier models he had used did not do this.
His conclusion was about identity. If an agent acts with the same permission set as the engineer who deployed it, he said, that is very risky. An engineer takes a peer review before a production change and announces it in a channel. The agent does neither, and it holds every account and cluster the engineer can reach.
This account is Gaurav’s, given to me in the conversation for the Agent Accountability episode. I have not verified it independently.
A permission review asks three questions and reruns whenever the model changes
- What does the access reach? List every system, repository, secret and network path the agent can touch, including production clusters and the open internet. AISI gave its agents internet access to download tools and did not anticipate that they would use it against real people (AISI).
- Which identity does the agent act under? Give it its own scoped identity instead of an engineer’s, which is the point of Gaurav’s account above.
- Who would see an unexpected action, and how fast? AISI’s alert came from general network monitoring after the agent had acted. It is now building monitoring that watches an evaluation while it runs.
Write the grant date and the model next to each permission. When the model changes, answer the three questions again. This trigger is my own recommendation.
Who owns the review when the model is just a setting is still open
In many setups the model behind an agent is a configuration value or a vendor-side update. The person who changes it may not be the person who approved the permission.
Human review is the control most teams would reach for, and it is under strain. Prasanna Ranganathan of Fi told me that when AI-generated pull requests multiplied, his senior reviewers could not keep pace, and fatigue pushed even careful ones toward rubber-stamping.
None of the conversations behind this piece settled who should own the review. If the approval that mattered was given for a model that no longer exists, who is responsible for noticing?
Frequently asked questions
When should AI agent permissions be reviewed?
Whenever the model behind the agent changes, and on a fixed schedule in between. This is the author’s recommendation. Each permission should record the grant date and the model it was approved against.
What is agent permission drift?
It is the gap that opens when an agent keeps the access it was approved for while the model using that access changes. The term is used in this article and is not an industry standard.
Did the UK AISI agent escape its sandbox?
No. AISI enabled internet access on purpose and says no agent tried to break out of its sandbox or attack AISI’s own systems.
What stopped the malicious pull request?
A human maintainer of the open-source project refused it, and a member of the public who suspected it opened it inside an isolated environment.
Credits and sources
- Arpit Bhayani, Principal Engineer II at Razorpay, builds Agent Studio. His essay Slop Debt was published on 21 August 2026. Website · LinkedIn · YouTube
- Gaurav Maheshwari, Founding Engineer and India Site Lead at Oodle AI, formerly at Rubrik and Goldman Sachs. His talk: From ReAct to Multi-Agent System. Profile
- Prasanna Ranganathan, Founding Member at Fi. LinkedIn
- Sources: AISI incident report, 4 August 2026, and its technical report. Anthropic, 9 September 2026. Anthropic, 30 July 2026.