AI Agent Tool Permissions Set the Blast Radius

Tools Give Models Hands

A missing state file let one instruction destroy live infrastructure. Score the tool, not the model. · Architecting the AI Coworker · 9/22

In late February 2026, Alexey Grigorev set out to tidy up the infrastructure behind DataTalks.Club, the data-engineering community he runs. The cloud setup was defined in Terraform, the tool that lets you describe servers and databases as code and have them built to match. He had Claude Code, an AI coding agent, helping with the migration. By his own first-person account of what followed, the agent could not find the Terraform state file, the record that maps the written description to the resources that actually exist. With the state file missing, the existing infrastructure looked, to the tooling, as though it did not exist.

So the agent ran terraform destroy. The command did exactly what its name says: it tore down the live infrastructure, including a managed database with close to two million rows in it. Amazon’s Business Support team located a usable snapshot, and the data was restored within about a day. Grigorev wrote the whole thing up afterwards, plainly, under his own name. The AI Incident Database catalogued the event as a pointer (5; 6).

The mistake itself is unremarkable; what should arrest a reader is how far it was able to reach. Grigorev was not careless and the model was not stupid. A reasonable instruction, in a standard tool, on a quiet afternoon, became the destruction of something real, and the gap between intent and catastrophe was a single missing file.

That gap is the subject of this essay. The previous essay made the case that an aligned model can still leave a deployment weakly governed, that helpfulness is not the same as control. This essay is about the moment that abstraction becomes physical. The old AI safety question was whether the answer was wrong. Tool-using agents add a harder one. An agent, in the sense this series has used the word, is a system that takes a goal, breaks it into steps and acts. Once a model has tools, its mistakes stop being sentences and start being actions. By a tool I mean any handle the model can pull on the world outside itself: an API call, which is a request sent to another piece of software asking it to do something or return data; a shell command, an instruction typed to the operating system itself, the layer with the power to move or erase files; a database migration; an email; the deletion of a storage volume. Whether the model is smart no longer settles the control question; what settles it is the scope, reversibility and observability the organisation built into the tool path before the model ever touched it.

Infrastructure-as-code is the cleanest illustration there is, which is why DataTalks.Club anchors this essay. Terraform exists precisely to turn a written intent into a deterministic state change: you declare what should exist, and the tool reconciles the world to match, building, altering or destroying whatever the gap requires. That is enormously useful and, for an agent, enormously load-bearing. The agent’s belief about the environment becomes, through Terraform, a literal instruction to the cloud. When the belief was wrong, because a state file was missing, the reconciliation was still carried out faithfully. The lesson does not depend on knowing every recovery detail. It depends on noticing the shape of the control plane, the part of a system that decides what an action is allowed to do. A probabilistic system, a model that guesses, reaches a deterministic destructive path, a tool that does precisely what its interface allows, through a credential with enough scope to matter. The tempting interpretation is that the model made a bad decision. It did, but that reading is not sufficient, and a team that stops there will fix the wrong thing. Bad decisions are routine. Every useful system makes them eventually. The new fact is that the bad decision had hands. A model without tools can write a paragraph about deleting a database. A model with tools can delete one.

The same triangle, on a second platform

DataTalks.Club is not alone, and a second incident shows the identical shape on different machinery. In late April 2026, an AI coding agent working for a small company called PocketOS reached a deletion path on its hosting platform, Railway, and destroyed a production database; this series tells that story in full in essay three, where Railway’s own write-up is used to walk all nine layers of a single failure. The short version is enough here. There was a long-lived, account-scoped API token, a key that could issue commands across the whole account rather than one narrow task. There was a volumeDelete call that carried out deletion immediately. The delayed-delete protection Railway used elsewhere in its product had not yet reached that path (1; 2; 3). It is the same triangle as DataTalks.Club seen from a different angle: scope left too wide, a destructive action with no delay, and an incident that surfaced only after the fact rather than before. The July 2025 Replit and SaaStr deletion, examined as a worked example in essay four, is a third turn of the same wheel (4).

The vendors differ, the interfaces differ, the failure paths differ. The architecture is identical. A probabilistic controller was wired into deterministic tools under credentials broad enough to hurt something real. The controller guesses and continues. The tool does exactly what its interface allows, no more and no less. The credential inherits whatever scope the surrounding environment happened to leave lying around. When all three meet, the model being unsure becomes something real being deleted. The danger is not that the model believes the wrong thing. Models will always sometimes believe the wrong thing. The danger is that the control plane lets a belief become a deletion.

Score every tool on scope, reversibility and observability

So the useful question is not “is the model good enough?” but a structured one, asked of every single tool an agent can call. It has three axes.

Scope asks how far an action can reach if it is called wrongly. Reversibility asks how hard the action is to undo. Observability asks who, outside the agent, sees the action in time to act. Call it the permissions triangle, and score each corner from 0 to 3 against a fixed rubric so two reviewers reach the same number. The cloud provider, regulator and currency may change; the permissions triangle does not.

Scope climbs by how far a wrong call can reach: a 0 is read-only, with no side effect at all; a 3 is production-wide or account-wide. In between, a 1 touches a single resource and a 2 reaches multiple resources or one whole tenant, by which I mean one customer’s isolated slice of a shared system.

Reversibility climbs by how hard the undo is: a 0 makes no state change at all; a 3 has no dependable undo path, whether because the action is irreversible, destroys the backups, or leaves recovery to chance. The middle is the gap between an automatic rollback (a 1) and a manual but reliable one (a 2).

Observability climbs the other way, by how late the action is seen: a 0 is visible on preflight, where a human or a rule sees the planned action before it runs; a 3 is discovered only after the harm, with an immediate alert (a 1) and sampled or delayed review (a 2) sitting between. A 0 is boring. A 3 is the place you put the pager before you let the agent anywhere near it.

The figure carries the full ladder. The headline is what the rungs produce: terraform destroy against live infrastructure under a broad credential scores close to a 3 on every axis, which is the DataTalks.Club afternoon reduced to three numbers.

The decision rule is the max, not the mean: any single 3 means reject for unattended agent use; a remaining 2 means allow only behind human approval; all corners at 1 or below means allow. Scoring the average is the mistake that lets a catastrophic reversibility 3 hide behind two reassuring 0s.

The same triangle, in everyone else’s rulebook

Once you have the three corners, you start seeing them everywhere serious people have written rules for AI, wearing different vocabularies. The OWASP GenAI Security Project’s Top 10 for Agentic Applications, a community security standard, names agent goal hijack, tool misuse, identity and privilege abuse, agentic supply-chain vulnerabilities, and unexpected code execution (7). Underneath that catalogue sits the mechanism: the peer-reviewed Greshake et al. work on indirect prompt injection establishes how a tool-using model can be steered through tainted retrieved content, and is the academic anchor behind OWASP’s tool-misuse and goal-hijack entries (10).

The regulators land in the same place by other routes. The US framework for managing AI risk (NIST’s Risk Management Framework) presses for bounded authority. Europe’s AI rules require that high-risk systems stay under meaningful human oversight. The cleanest fit, though, is the UK-derived AI cyber-security baseline published in April 2025 (ETSI TS 104 223), which simply requires that AI systems be deployed with constrained permissions and auditable action logs, putting the scope and observability corners directly into a standard (8). Canada arrives through privacy law: organisations must keep personal information only as long as the purpose it was collected for actually needs, which is the scope-the-credential rule wearing a privacy lawyer’s coat (9).

Different vocabularies, same triangle. None of these are text-generation problems. They are control-plane problems, and the triangle turns the vague phrase “agent risk” into three concrete moves, with which one you make depending on the worst corner. A bad scope corner means shrinking the authority. A bad reversibility corner means pushing the point of no return further away. And when observability is the weak corner, you build an action ledger and alerts the agent cannot edit.

The triangle also explains why the same failure keeps recurring, because every incident in this essay is a story about one or more corners left at 3. It is worth naming the patterns directly, because naming them is how you spot the next one before it bites. Most of them are not new categories alongside the triangle; they are the triangle’s corners failing under a friendlier name, and reading them back onto a corner is what stops you fixing the wrong thing.

The soft objection answers itself: tools are the point, and you cannot strip them away, because an agent with no tools is a chatbot writing theatre about work instead of doing it. The objection a senior engineer will actually raise is sharper. Bounded authority does not remove the failure, it relocates it. A scoped token still has to be issued by something, and that something needs broad authority. A delayed delete still completes; it only buys a window, and someone has to be watching the window. An action ledger is only as honest as the code that writes to it. Push the argument to its limit and it bites hardest: concentrate all the broad authority into one broker and you have built the very ambient-authority object you condemned, just renamed, now a crown-jewel target whose compromise is catastrophic across the whole estate.

That objection is correct in every clause, and it is worth conceding fully rather than dodging. The triangle does not abolish risk; it concentrates it. But concentrating risk is the entire point. The DataTalks.Club chain was dangerous precisely because the risk was diffuse: a broad credential, a missing state file, a destroy command one keystroke away, no preflight, each one routine, the catastrophe living in their combination.

You cannot staff a watch over a diffuse risk because you cannot see it. You can staff a watch over a concentrated one. A short-lived credential issued by a broker means the broad authority lives in one audited component instead of being scattered across every environment file. A destroy that is gated and alerted means the dangerous window has an owner. Yes, you have traded many unaudited broad credentials for one audited one, and yes, that one is now a target; the trade is worth making only because a single component can be watched, rotated and rate-limited in ways a hundred scattered .env files never will be. The triangle does not promise the defended place will hold. It promises there is now a defended place, named, owned and reviewable, instead of a blast radius nobody had measured. That is a smaller claim than “safe”, and it is the honest one. If you cannot defend the broker, you have not earned the right to the agent.

Carry This Forward

Tools give models hands. Once an agent can call APIs, run commands, change records or delete infrastructure, the safety question becomes scope, reversibility, observability and blast radius. A wrong answer used to stop at being wrong; now it can act. Grigorev’s infrastructure was not destroyed by a stupid model; it was destroyed by a reasonable instruction reaching a tool with too much reach, no preflight and nobody watching the destroy. The triangle is the instrument that would have told him so before the agent ran.

And it earns its keep most on the tool that looks harmless. Score an agent’s send-email capability the same way you scored the destroy: action class write, scope 3 because one call can reach every customer on the list, reversibility 2 because a sent email cannot be unsent, only followed by a correction, observability 1 if a bounce alert fires. Two innocent words, send email, hide a scope 3 — the same corner that deleted the database, now wearing a friendlier verb.

Carry one move forward. Build a single row of a tool registry today, for one tool the agent can already call. Record eight fields: the tool, its action class (read, write, or destroy), its scope, reversibility and observability each scored 0 to 3 against the rubric, the named owner, the default rung at which it may run without a human, and the kill switch that stops it. For DataTalks.Club the row writes itself: tool terraform destroy, action class destroy, scope 3, reversibility 3, observability 3, owner unassigned, default rung “never unattended”, kill switch none. Three threes and an empty owner column is the incident, on one line, before it happens. Whichever score is highest is the corner to defend first, and the defence is concrete: scope the credential, gate the destructive path, or build the alert. Until someone owns that row, the model owns the blast radius by default.

Then look one move earlier. Before an agent can misuse a tool, somebody or some workflow admitted that tool, skill, connector or config into the environment in the first place. The safest tool call is the one whose authority was bounded before the agent ever reached it, and that admission moment, an agent supply chain you mostly cannot see, is where the next essay begins.