In late April, Jer Crane, founder of a car-rental software company called PocketOS, posted an account of the worst nine seconds of his year. A coding agent — Cursor, running on Anthropic’s Claude model — had been helping his team with routine work when it found a live API token in its environment, used it to issue a volume-delete command, and wiped the company’s production database. The backups went with it, because the hosting platform stored them on the same volume, and PocketOS eventually restored from a copy three months old. When Crane asked the agent what it had done, it answered with a line that has been quoted everywhere since: “I violated every principle I was given.”

The story travelled fast, mostly under the “rogue AI” headline — ABC News ran it as an agent gone haywire. Fast Company and Ubergizmo both read the incident more carefully and reached the same conclusion, that the fault sat with the access rather than the AI, and I think they’re right: the question that matters is how the agent was ever in a position to do it.

Look at what that agent was actually holding. A piece of software employed to write and test code had inherited an environment containing a live credential with the authority to destroy production storage, and the backups sat within reach of the same command. No judgement was ever going to intervene, because agents don’t have judgement — they run on instructions and permissions, and when the instructions go wrong the permissions are all that’s left. This isn’t a rogue AI story. It’s a permissioning failure, and an agent with no route to that delete command, and no reach into the backups, couldn’t have done this damage however badly it misbehaved.

The principle we already learnt

The uncomfortable part is that we’ve known the answer for half a century. In 1975, Jerome Saltzer and Michael Schroeder set out their design principles for secure computer systems, and among them was least privilege: every program and every user should operate with the smallest set of permissions the job requires, and no more. The industry then spent the late 1990s and 2000s relearning that principle the expensive way, as worms tore through networks where every desktop ran as administrator. Anyone who ran a technology business through those years, as I did from 2001, will remember the slow work that followed: the IT manager who finally removed local admin rights from everyone’s laptops, weathered two weeks of complaints for it, and was proved right the next time something nasty arrived by email and found it couldn’t get past the person who opened it.

That work got done because the cost of not doing it kept arriving in production, and it left the industry with a settled instinct: when you provision access for a new system or a new starter, you begin from nothing and add what the role requires. Somewhere in the last two years, with agents, that reflex has gone missing.

Why agents get senior-engineer credentials

Watch how a coding or operations agent typically gets deployed and the pattern repeats: the agent inherits the credentials of the person who set it up. It’s the path of least friction (the developer’s environment already holds the API keys, the database connection, the cloud account), and the agent works impressively well with all of it, right up until the day it works impressively badly. We’d never onboard a human this way. A contractor joining for a fortnight gets scoped access and a degree of supervision precisely because we don’t yet trust their judgement, and yet the agent, which has no judgement at all, walks in with the standing access of a senior engineer. I’ve written before about shadow agents running on staff laptops with live company credentials; what PocketOS shows is that the sanctioned agents, the ones we deployed on purpose, are often just as over-provisioned.

The tooling, meanwhile, keeps drifting towards more autonomy. Anthropic launched auto mode for Claude Code in the spring, letting the agent decide which actions are safe to take on its own, and by August it had become the default for paying accounts. I use these tools daily, and the autonomy is exactly what makes them valuable — an agent that stops for approval on every file write is barely worth having. But autonomy and authority are different axes. You can give an agent enormous freedom of action inside a small, recoverable space, or narrow freedom inside a large blast radius, and most deployments today have that combination backwards.

Four patterns that scope an agent down

The fix is a set of habits, no product required, and none of them will be new to anyone who has administered systems for humans.

  1. Scoped tokens per task: Give the agent a credential minted for the job in hand, not a standing master key. If the task is analysing logs, the token reads logs and does nothing else, and it expires when the work ends. Long-lived broad credentials in an agent’s environment are exactly what turned PocketOS’s bad instruction into a dead database.
  2. Append-only writes by default: For the workflows it suits, an agent that can add but not delete or overwrite converts catastrophe into clutter. Had the PocketOS agent held append-only access, those nine seconds would have produced some untidy extra records and a lesson, rather than a three-month restore.
  3. Dry-run mode for destructive actions: Anything that deletes, drops, or overwrites should emit a plan for someone other than the agent to approve, rather than executing directly. The pattern is as old as rm having no undo; we’ve simply forgotten to apply it to tools that type faster than we do.
  4. Review queues for what remains: Where an agent’s changes really do need to land in production, land them as proposals: the agent does the work, records what it changed and why, and a named person approves it before anything takes effect. Anthropic’s own Claude Code Review ships exactly this shape, and it’s the pattern to copy for any consequential system an agent touches.

There’s a standards-track version of this thinking emerging too. On 28 April, Google handed its Agent Payments Protocol to the FIDO Alliance, the body behind passkeys, and the core idea is a signed mandate: instead of giving an agent your card, you sign an instruction like “spend up to £200 with this supplier before Friday”, and that’s all the authority the agent ever holds. Whether the standards can move as fast as the deployments is an open question — a protocol that changes custodian in its first year isn’t settled ground — but the direction is the right one: agent authority becoming something you can prove and bound, rather than something you extend and hope.

Scoping matters twice over, because permissions are also your defence when the agent gets manipulated rather than makes a mistake. An agent that reads the open web is operating in hostile territory now, and a prompt injection that hijacks a tightly-scoped agent inherits only the narrow access you granted — the damage is capped at what the task ever needed to touch.

An audit for next week

Here’s the practical version, and it fits in an hour. List the agents currently running in your business: the coding assistants, the workflow automations, the research tools with API access. For each one, ask two questions: what can it actually touch, and is that more than the task it was built for requires? Most of us will find at least one agent holding credentials a cautious manager would never have signed off for a new hire. For each of those, work out what scoping down would take — a narrower token, an append-only role, a review step — and do one this week.

Agents don’t have judgement, so your permissions have to. That’s the whole principle, and the good news is that our industry has applied it successfully before. The teams that gave up desktop admin rights twenty years ago still trusted their people — they just put boundaries where trust had been doing unnecessary work, and everyone got on with the job. Give your agents the same treatment, and you can enjoy what they’re genuinely good at without wondering what a bad nine seconds might cost.