Explain the concept of a blast radius for an AI feature and how design limits it.

Corebridge is an AI coding agent with access to a company's repos and, for small fixes, its production infrastructure directly. Bram Achterberg is a senior platform engineer who has used it daily for eight months. The concept underneath his story is blast radius: how far a single mistake can reach, not how likely the mistake is.

How to answer this, stage by stage

Nobody is grading whether you can define blast radius in one sentence. They're grading whether you can point at the exact decision that made one bigger than it needed to be.

Let's learn

Here is what happens when a tool works fine for months, gets a little more trusted every one of those months, and then, for one Tuesday morning, does not.

Before Corebridge, engineers on Bram's team fixed small production issues by hand: check the alert, open a narrow terminal session scoped to exactly the one service in question, make the fix, close the session. Slow, maybe twenty minutes end to end, but nobody's fix ever reached past the service they opened.

The whole method, in five rows. The third one is the hard one, and the one this whole answer turns on.

Now Corebridge reads an alert, diagnoses the likely cause, and can run the fix itself, no terminal session, no waiting for a human, often in under a minute.

Here's the turn: the extra speed was never the problem. The problem is that Corebridge's access had quietly grown from one low-traffic service to fourteen, and its blast radius, how far a single wrong call could reach, grew right along with it, unnoticed, because each individual grant looked small and reasonable on its own.

At its worst, an agent gets one diagnosis wrong on a Tuesday morning and the damage lands not on the service it was actually looking at, but on two completely unrelated ones sharing the same database credential.

Eight months of small, reasonable widenings. One shared credential that never had an edge.

What I would leave alone: low-stakes fixes on an isolated dev branch don't need this treatment. A mistake there can't reach production at all, so a narrow, short-lived credential buys nothing.

The lesson: a blast radius isn't something you notice growing. It's something you only measure honestly after it's already gone off.

Now here is the same thing as a story

The short version above is what you'd say defending this redesign to Corebridge's platform council. Read this one for the actual Tuesday.

Bram Achterberg has spent seven years catching race conditions before they ever reach code review, the kind of engineer other people's PRs get routed to when something feels subtly wrong. Corebridge, when it launched, only ever touched a single low-traffic internal reporting service, and Bram reviewed every one of its pull requests in full, out of habit as much as caution.

Over eight months, as Corebridge proved reliable on small fixes, its access grew: a second service, then write access to shared configuration, then permission to run database migrations directly against production. Each grant, on its own, looked like a small, sensible convenience. Nobody ever sat down and added the whole thing up.

The team assumed Corebridge's reach could be turned down gradually if needed. It was never actually built with a dial at all.

On a Tuesday morning, an alert fired: query latency climbing on the internal reporting service, the same small one Corebridge started on. It read the logs, decided the cause was a stale index, and ran a migration to rebuild it.

The third box is the actual mistake. Everything after it was just the credential doing exactly what it was allowed to do.

The index it rebuilt wasn't only used by the reporting service. It was shared by two other, unrelated checkout-adjacent services that had been quietly pointed at the same database years earlier. Rebuilding it locked the table for forty minutes. Checkout went down along with the reporting dashboard nobody was even looking at that morning.

Eight months of quiet growth, forty minutes of damage, and a redesign that fits on one credential.

With the redesign, Corebridge now requests a fresh credential for every task, scoped to exactly the service the alert named, expiring in ten minutes, with no path to touch anything outside that boundary even if its own reasoning insists a fix elsewhere would help. Run the same Tuesday forward: the agent still misdiagnoses the cause, still tries to rebuild the index, and the credential simply can't reach the two other services. The reporting dashboard hiccups. Checkout never notices.

None of these four existed on the old shared credential. All four came out of one dropped index.

The old design asked the team to trust that scope, once granted, stayed reasonable forever. The new one never lets scope outlive the task that needed it.

I approved each access grant because each one, alone, looked like an obviously safe convenience. It took one shared index to see that eight small yeses had quietly built one very large blast radius nobody had actually signed off on.

The five steps, if you want to remember it

The recap, one line per letter: find the person is Bram and his habit of reviewing everything, locate the habit is re-adding up total access, identify the flip is scope trusted broadly versus scope trusted in a narrow slice, pinpoint the old decision is one shared credential nobody revisited, and show the replay is the same mistake contained to one service instead of three.

And if you want to be sure it really works, try it somewhere elseA different flip family, a pharmacy order-entry assistant instead of a coding agent. The blast radius here is measured in prescriptions, not services.

PharmaLoop is an AI assistant that helps pharmacists process refill requests and flag drug interactions. Petros Amundsen is a pharmacist who uses it during every shift. This story runs on a different family, the delegation flip, not scope: as PharmaLoop proved reliable on routine refills, pharmacists began letting it auto-approve more categories of request without a second look, handing off judgment calls that used to always get a human's eyes first.

The old decision behind it: PharmaLoop's rollout let any refill request the model scored above a fixed confidence number auto-approve, across every drug category, on the theory that a single confidence threshold was simpler to reason about than category-specific rules. The risk that decision created: a request for an interaction override, approving a drug combination the system would normally flag, scored above the threshold on a rare, unusual case, and auto-approved with no pharmacist glance at all, since the interface never distinguished a routine refill's blast radius from a life-threatening interaction's.

Only the top-left corner, rare and high-damage, ever needs a hard human boundary. Everywhere else, the confidence threshold is fine as it is.

Swap the trigger and it still runs.
Speed: an interviewer caps you at sixty seconds. Say "scope every agent credential to one task, expire it fast, and make the boundary a hard wall," and stop.
Cost: there's no time to rebuild the credential system this quarter. Say so honestly, and start by scoping down whichever service shares infrastructure with the most other services first.
The model gets better, for real: if Corebridge's diagnoses genuinely get more accurate, that's still not a reason to widen the credential back out, a rarer mistake inside a wide blast radius still costs the same when it happens.

Where people run it wrong.
They measure how often the agent is wrong and stop there, without ever asking how far a wrong action could actually reach.
They grant access in small increments and never re-add the total, so the blast radius grows one reasonable-looking step at a time.
They assume a boundary the agent could reason its way around counts as a real limit, when only a boundary it physically can't cross actually does.

How to use it live. When someone asks you to explain blast radius, don't reach for percentages. Ask: if this feature is wrong right now, what is the largest thing nearby it could still touch? Design to shrink that answer, not the odds of being wrong in the first place.

Flashcards (tap any card to flip it)

Check yourself Score: 0 / 0