This year’s Cybersecurity Awareness Month theme, “Don’t Make It Easy for Them”, ought to apply to the permissions we hand AI agents. I sometimes hear “human in the loop” talked about as though it settles the security question, when it tells us very little about whether someone can stop a damaging action in time.
In September, a Claude Code user reported that an agent had deleted more than 48,000 files despite instructions to preserve the originals. What concerns me about that account is the gap between what the user asked for and what the environment allowed. That gap is why we should look at the permissions before deciding where a human should step in.
Put limits on the environment
Think about giving a junior developer unrestricted access to production on their first day. If they accidentally deleted a database, most organisations would look at the process that allowed it to happen. They would ask why that person had so much access and what guardrails should have been there. Hiring a smarter developer wouldn’t answer those questions, and using a more capable AI model doesn’t answer them either.
The NCSC’s August advice on agentic AI makes a similar point. The more autonomy an agent has, the greater the potential impact when it behaves unexpectedly, so controls should reflect the consequences of failure. It also warns organisations not to rely on prompting alone.
This advice gives us a much more useful way to think about agent security. Low-risk work that is easy to reverse if something goes wrong can run with more freedom inside a clearly defined boundary. As the potential impact grows, that boundary needs to tighten and the points where a person intervenes need to become much more deliberate.
Make approval worth the attention
The concept is a fairly simple one. Different actions and instructions ultimately require different levels of human oversight. I would let an agent fix a straightforward spelling mistake on a website without waiting for approval, provided the workflow checks the result. However, a change to how customers are charged is different. A mistake there costs real money and reputation, so I’d want someone who understands the business involved much earlier. That person may know about a customer commitment that never appeared in the ticket, which is exactly the context I want human judgement to bring.
The reality is that AI can speed up how quickly code is produced, but that doesn’t automatically make the whole development process more productive. Recent research found that the gains from AI coding tools shrink as work moves into reviewing, integrating, testing and releasing code. If every increase in output creates more work for people further down the process, we have simply moved the bottleneck. And increasing the number of approval requests doesn’t solve that problem. Anthropic acknowledged in May that repeated permission prompts can leave people paying less attention to each one. A reviewer needs to understand the proposed change well enough to challenge it, and the workflow must pause before the consequential action happens.
Let’s take the example of the deleted files incident again. If someone is approving a cleanup, they should see which files will be affected before the command runs. Approval to tidy a project should stay tied to that agreed scope, with another decision required if the agent proposes to go further. Even then, we need to decide how we will recover when a mistake gets through.
Plan for recovery before increasing autonomy
For work that changes important files or changes crucial parts of a workflow, a tested recovery route is essential before expanding the agent’s access. That could mean protected backups that the agent can’t alter, alongside a clear audit trail of what actually changed. We should be able to reconstruct what the agent was asked to do, what actions it took and where a human approved or intervened. That transparency matters when something goes wrong because organisations need to be able to understand what happened well enough to fix the process afterwards, without depending on somebody remembering what they asked the agent to do. For actions we can’t reliably undo, such as releasing confidential information, the controls before execution need to carry more weight.
I absolutely agree with joint guidance from six national cybersecurity agencies published this year that recommends increasing autonomy gradually and evaluating results to decide whether an agent’s scope should grow or shrink. A good record on small changes should earn more freedom within an agreed scope, while access to actions with serious consequences should remain a deliberate business decision.
The responsibility for setting those limits belongs to the organisation deploying the agent, and just adding a human reviewer somewhere within a traditionally complex process doesn’t transfer enough of that responsibility to the person clicking approve.
Join our LinkedIn group Information Security Community!
——————————————————-
Click Here For The Original Source.
