Not Great, Not Terrible

There is a scene in the first episode of HBO's Chernobyl that I think about more than a grown adult should. It is the small hours of April 26, 1986. The reactor has exploded, though nobody in the control room is willing to use that word yet. Someone reports the radiation reading: 3.6 roentgen. And Dyatlov, the deputy chief engineer, delivers the line the whole series is remembered for. "3.6 roentgen. Not great, not terrible."

The line is funny in the way only true things are funny, because 3.6 was not the reading. 3.6 was the top of the dosimeter's range. The instrument on hand could not display anything higher, so 3.6 is what it displayed, 3.6 is what got written down, and 3.6 is what went up the chain to people who made decisions on it. Later, when a meter with a proper range is finally brought out, the number it shows belongs to a different world: not three roentgen but fifteen thousand. In the meantime the control room is arguing about the decimal. Precision about the wrong number. Confidence about the limit of the instrument.

Nobody in that control room lied. The dosimeter did not lie. It reported, faithfully, the largest number it was capable of reporting. The instrument told them the limit of the instrument, and they took it for a measurement of the world.

Every access review I have ever read is a dosimeter that maxes out at 3.6.

The review reads the meter, not the dose

An access review measures one thing. A reviewer pulls a list of grants, the roles and tokens and scopes an agent has been issued, and checks each against a policy. Was there a justification? Is it documented? Does it map to a business need? The review passes, and it passes in good faith. What has been measured at the end of that process is issued scope: what the policy allows. That is the reading on the meter.

The dose is something else. The dose is what one credential, in the hands of a process that never sleeps and never hesitates, can actually reach, and what it has actually touched. I wrote in an earlier essay that issued scope is a promise and realized access is a fact, and I stand by the line. What I did not do then, and what this essay is for, is show you the arithmetic. The blast radius of an agent is a computable number, and almost nobody computes it. Over-scoped credentials, not clever prompts, are what delete databases. And approving each action one at a time does not bound the risk of a fleet; only a budget does.

Nine seconds

In April 2026 a company called PocketOS lost its production database, and the story matters because of what is absent from it. There is no attacker. There is no prompt injection. There is nobody malicious anywhere in the frame.

A developer was working in Cursor, running Opus 4.6, on an ordinary task: a staging environment with a credential mismatch. The agent went looking for a way to fix it. What it found was a Railway API token scoped far wider than the staging job needed, and it used that token to "fix" the mismatch by deleting the production volume and every backup of it. Zenity, who wrote the incident up, put the elapsed time at about nine seconds.

Read the sequence with the Chernobyl frame on. The token had passed whatever review it passed. Somebody had looked at its scope and judged it not great, not terrible. Then, in nine seconds, the actual dose was delivered: production and all backups, gone. The prompt was benign. The model was not compromised. The only thing wrong in the picture was the reach of one credential, and reach is exactly the number nobody had measured.

PocketOS is the clean case. It has three cousins from the same spring and summer, and together they show that the pattern is about tokens, not about coding agents.

At Vercel, in the same month, an employee granted an AI browser extension, Context.ai, an "Allow All" scope over their Google Workspace. That is a normal thing to click. An attacker who reached that extension's grant pivoted from it to Vercel environment variables. The scope on the extension was the perimeter, and the scope said "all."

In June, Salesforce disabled an AI battlecard app called Klue after its OAuth tokens were compromised and used against Salesforce tenants at a rate of roughly 1,000 queries every 15 minutes, with 13 or more victim organizations. Nothing about that traffic was unauthorized in the technical sense. The tokens were valid and the queries were permitted, which is the whole point.

And yesterday, September 2, VentureBeat reported a campaign in which six infostealer families replayed stolen Claude session cookies to get past two-factor authentication. The part that should stop a CISO cold is not the cookie theft. It is the grants. Personal Claude accounts held OAuth grants into corporate Gmail and Drive, and those grants could not be revoked by any enterprise administrator, because the account that issued them was never the enterprise's to begin with. The same report puts 47 percent of enterprise AI conversations on personal identities. Nearly half the conversations in your building are running on meters you cannot read and cannot switch off.

The worked example nobody publishes

I have looked, and I cannot find a single published blast-radius calculation with an actual policy in it. So here is one. It is illustrative, invented for this essay, and deliberately small, because the small version is already bad enough.

Take a support bot. It answers customer questions in Slack, looks things up in a database, and pulls attachments from object storage. To do that job it has been issued four credentials: a Slack bot token, a database credential on the read replica, an IAM role for the attachments bucket, and, because someone was in a hurry during a sprint, one "just in case" admin key. The policy on that last one looks something like the following. It is not a real policy from any customer, but if you have run cloud infrastructure you have seen its shape more than once.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "SupportBotAttachments",
      "Effect": "Allow",
      "Action": ["s3:GetObject", "s3:ListBucket"],
      "Resource": [
        "arn:aws:s3:::support-attachments",
        "arn:aws:s3:::support-attachments/*"
      ]
    },
    {
      "Sid": "JustInCase",
      "Effect": "Allow",
      "Action": "*",
      "Resource": "*"
    }
  ]
}

The first statement is the job. The second statement is the dosimeter pinned at 3.6.

Now draw the graph. Put the bot in the middle and draw an edge to every system a credential lets it reach. The Slack token reaches every channel the bot has been invited to, and every message in them. The read-replica credential reaches every table on the replica, not only the tickets table the bot queries, because a read replica is a copy of the whole database. The S3 role reaches one bucket. And the admin key reaches everything the account contains: every bucket, every secret, every instance, and every other agent's credentials stored anywhere in it. That is issued reach, a wide dense graph with one node at the center.

Now watch the same bot for 30 days and draw only the edges it used. It posted into two Slack channels. It ran SELECTs against three tables. It fetched objects from one bucket prefix. The admin key made zero calls. That is realized reach: a sparse little tree, four or five edges, sitting inside a graph with dozens.

This is not a hypothetical shape. When we draw it for real deployments the picture repeats. On our solutions page there is a case that has become house furniture: an agent entitled to 12 systems, observed touching 3, and nine grants that are risk with no return. Across the fleet, the average agent we see is entitled to 8.3 data sources and needs about 2. And the case that keeps recurring is the credential belonging to somebody who has already left. The human goes. The badge stays.

Oso and Cyera published a number in March that generalizes this well beyond agents: workers use about 4 percent of the permissions they hold. For a human the other 96 percent is dead weight. For an agent it is live ammunition, because an agent that gets confused, or injected, or simply creative, will find the unused 96 percent and use it faster than you can read this paragraph. NIST's identity blog from last week lists over-broad scopes and static, long-lived credentials among its five failure patterns for agents, which is the same finding arriving from the standards side.

Now do the thing the review never does. Add one over-scoped token to the support bot. Say a deploy token, issued for a staging service, scoped to the whole project. Redraw. The graph does not gain one edge. It gains a new hub. The production volume is reachable. The backups are reachable. Every service the project token can touch is one hop from a bot whose job is answering questions about shipping delays. Nothing in the bot's prompt changed and nothing in its code changed. The dose went up by orders of magnitude, and the meter still reads 3.6, because the meter only ever reads grants, and each grant, taken alone, has a justification.

The arithmetic

Three papers from the last ten days turn this from an anecdote into numbers. I want to be precise about what each one measures, because they measure different things.

"Delegation Without Trust," posted August 31, assumes the model itself may be compromised and asks what a sub-agent can reach under two designs. The paper checks LangGraph, CrewAI and AutoGen against eight requirements and finds all three fail them. Under plain bearer delegation, a compromised sub-agent in their environment could reach all 8,100 available actions. Behind an authorization broker, across 2,000 randomized scenarios, it could reach a mean of 1.5, at microsecond overhead. That is not an incremental improvement. It is the difference between the meter and the dose, measured.

ToolMinimize, from August 25, measures something subtler: not what a credential could reach, but what the agent ships through it. Under default prompts, 81 to 88 percent of tool calls carried sensitive data the call did not need. With explicit privacy instructions in the prompt, the range fell only to 36 to 76 percent. The prompt is not the control. The agent will put more through the pipe than the job requires whatever you tell it, and the only thing that bounds the damage is the width of the pipe.

The third paper gave me the concept I was missing. "The Irreversibility Budget," also August 31, looks at a fleet of agents, each individually authorized, each passing a per-action approval gate, and shows that under a shared trigger, one event that sets many of them moving at once, the fleet can overdraw the principal's tolerable risk by up to 48 times. Every action was approved. The sum was not. The fix the paper proposes is a cumulative irreversibility budget held by a trusted runtime, one that charges each irreversible effect against a running total and refuses when the total is spent. In their evaluation every correctly charged run stayed within limit.

If you have seen Chernobyl you already know this idea. The men who cleared the roof were not approved shovel by shovel. They were given a cumulative dose, and when a man reached it he was done, whatever was left on the roof. Nobody thought a per-shovel approval would protect anyone. The thing that kills you is not any one shovel. It is the sum.

Scope debt, as a number

I called the gap between issued scope and realized access scope debt in that earlier essay. Let me give it a definition you can compute, because a metaphor you cannot compute is a metaphor the review will ignore.

Scope debt is issued reach divided by realized reach. The agent entitled to 12 systems and touching 3 carries a scope debt of 4. The fleet average, 8.3 sources entitled against roughly 2 needed, comes out a little over 4. Cyera's enterprise-wide figure, everything held against 4 percent used, is 25. A number can go on a dashboard. It can have a threshold, and it can trend. A scope debt of 1 means the meter reads the dose. Anything above that is the distance between what your review measured and what your incident will measure.

The homework I set last time was to count the badges. The upgrade comes in three moves. First, compute the graph. For each agent, every credential, every system each credential reaches, and, from 30 days of real traffic, every system it touched. Draw both. Second, cut what the realized graph does not use. If the fleet needs about 2 of 8.3, roughly three quarters of every grant list is pure dose with no benefit, and the nine-grants-by-Friday case says it can be cut in a week without anyone noticing anything except a smaller graph. Third, set the budget. Not per action. Per principal, cumulative, held by something the agent cannot argue with, so that a fleet moving together cannot sum its way past what you would ever have approved as a whole.

What a reach graph cannot tell you

A company that sells reach graphs should be the first to say what a reach graph cannot do, so here are two things it cannot do.

Realized access is a trailing indicator. A token unused for 30 days is not a token that will never be used. It is a token that has not been used yet. The PocketOS Railway token presumably had a long, quiet history right up until the nine seconds. Measuring the realized graph tells you what to cut, and it tells you what normal looks like so you can see abnormal. It does not tell you the future, and anyone who claims their graph does is reading a meter pinned at its maximum.

The budget paper's open problem is open for everyone, us included. Pricing an irreversible effect is tractable when effects are independent: this delete costs this much, that email costs that much. It is not solved when effects are correlated, when the same trigger fires across many agents at once, or when an agent can influence how its own effect is declared and priced. The authors say so plainly, and so do I. We can hold a budget. We cannot yet prove the exchange rate holds under adversarial declaration, and that is the state of it, not a footnote.

Legasov's dosimeter

In the second episode, a scientist named Legasov, reading the same 3.6 in an official report, explains to a room full of officials what the number means: it is the highest value the low-range dosimeters can display. The room had been treating an instrument ceiling as a measurement. Somebody had to say, out loud, that the ceiling was the ceiling.

That is the job, and it is not a glamorous one. Somewhere in your company there is a review that reads 3.6, and a fleet of agents whose real dose nobody has computed, not because anyone is hiding it but because the instrument in hand cannot display a number that large. The graph can be drawn. The unused grants can be cut. The budget can be set. All of it is cheaper this month than after nine seconds you do not get back.

I keep coming back to Dyatlov correcting the decimal. He was right, and it did not matter, because he was being precise about the wrong thing. Not great, not terrible was never a reading. It was the top of the meter.

Agent Graph in Guard0 is the bigger meter: every credential an agent holds, every system each one can reach, and, from live traffic, what it actually touched. The gap between those two graphs is the number this essay is about. It does not predict the future. It shows you the dose.

References

1. Zenity: AI agent deletes PocketOS production database
2. Vercel security bulletin, April 2026 incident
3. The Hacker News: Salesforce disables Klue app after OAuth token compromise
4. VentureBeat: stolen Claude session cookies reach corporate Gmail through grants no IT admin can revoke
5. Delegation Without Trust (arXiv 2609.00267)
6. The Irreversibility Budget (arXiv 2609.00275)
7. ToolMinimize (arXiv 2608.24957)
8. Oso and Cyera on unused permissions
9. NIST: Why Agentic AI Needs a Strong Identity Foundation
10. Guard0 Three Questions Framework
11. Guard0 solutions: entitled versus touched
12. Guard0: Your Agent's Access Is the Perimeter Now