Skip to content

Module 04

Blast Radius

Map what your agents may touch, and decide who answers when it goes wrong.

What an agent may touch is an accountability decision. Most people made it by accepting a default.

Movement IIRedesign the four decisions. Delegation, review, legibility and permission. Each is already decided by default; this is where the decision becomes deliberate and gets written down.

Permissions look like configuration

They are not. What can be read, changed and merged determines what an agent is trusted with, what it can damage before anyone notices, and who is answerable when it does. That is an accountability structure, and most of them were established by clicking through a setup screen.

The question is never whether the agent is trustworthy in general. It is what the worst plausible outcome is within the permissions it currently holds, and whether anyone has agreed to own that outcome.

Read, change, merge

Treat the three separately, because they fail differently. Read scope determines what leaves the repository and where it goes — a question about confidentiality, not correctness. Change scope determines what can be damaged. Merge scope determines whether a human is in the path at all.

Credentials deserve their own line. An agent operating with your token acts as you: the audit trail says you did it, and in most organisations that is not a technicality but the whole accountability mechanism. If the log cannot distinguish your work from the agent's, then attribution has already been decided, and it was decided against you.

Method

  1. 01List every agent, assistant and automation with access to your work, including ones you did not configure.
  2. 02For each, record read scope, change scope, and merge rights separately.
  3. 03Record whose credentials it operates under, and what the audit log shows.
  4. 04For each, write the worst plausible outcome — not the worst imaginable one.
  5. 05Name the person who answers for that outcome. If the answer is nobody, that is the finding.

How this goes wrong

  • Worst imaginable instead of worst plausible

    Catastrophising produces a document nobody acts on. The useful entry is the realistic bad Tuesday, not the breach scenario.

  • Forgetting the read scope

    Read access feels harmless and is the one with confidentiality consequences. What an agent reads may leave the building.

  • Shared credentials treated as a detail

    If the agent acts as you, you have already accepted accountability for everything it does. That may be fine — but it should be a decision, not a default.

The exercise

  • Map every permission your agents currently hold, split into read, change and merge.
  • Write the worst plausible outcome for each, and who answers for it.
  • Revoke one permission you cannot justify.

Permission map

The sections your artifact contains:

  1. Agents and automations with access
  2. Read / change / merge, per agent
  3. Whose credentials, and what the log records
  4. Worst plausible outcome, and who answers
  5. Revoked, and what broke

Done means. Every row has a named person in the accountability column. "The team" is not a name.

All modules

  1. 00Baseline
  2. 01Delegation Boundary
  3. 02Review Discipline
  4. 03Estate Legibility
  5. 04Blast RadiusYou are here
  6. 05Measurement
  7. 06Re-measurement