Excessive agency and blast radius
Most agent disasters are not clever attacks. They are an ordinary mistake meeting a permission nobody thought about. Build an agent below and watch the damage number move.
In 60 seconds
Excessive agency and blast radius
Most agent disasters are not clever attacks. They are an ordinary mistake meeting a permission nobody thought about. Build an agent below and watch the damage number move.
| Form | What it looks like | Example |
|---|---|---|
| Too many tools | The agent has capabilities the task never uses | A summarising bot with a delete tool because it shares a toolkit |
| Too much scope | The right tool, aimed too wide | Database access to all tables when it only needs orders |
| Too much autonomy | The right action, taken without asking | Refunds up to any amount with no approval step |
Interactive · what is the worst hour?
Tick the tools your agent has, then choose how much it does unsupervised.
The four questions of least privilege
- 1
What must it read?
List the exact tables, folders and endpoints. Not "the database" — the specific rows. Read access is where leaks come from. - 2
What must it change?
Write access is where disasters come from. Every write tool should have a written justification you would be comfortable reading aloud after an incident. - 3
What must it never touch?
Write this down explicitly. Payments, permissions, user accounts, production deploys, deletion. Then enforce it in code, not in the prompt. - 4
What is the worst hour?
If this agent were fully controlled by an attacker for sixty minutes, what is the total damage? That number is your blast radius, and it is the number that should drive your design.
Autonomy levels — pick one on purpose
| Level | The agent... | Right for |
|---|---|---|
| L0 · Suggest | Writes what it would do. A human does it. | Anything involving money, people, or production |
| L1 · Approve each | Proposes each action; a human clicks yes. | Sending email, writing to a database, deploying |
| L2 · Approve risky | Acts freely, pauses on a named list of risky actions. | Most useful production agents |
| L3 · Act, report after | Acts freely, everything is logged and reviewable. | Read-only research, drafting, internal analysis |
| L4 · Fully autonomous | No human in the loop at all. | Sandboxed, reversible, low-value tasks only |
Limits that cost nothing to add
- A hard cap on actions per run, and per hour.
- A spend cap in real currency, enforced by your code and not by the model.
- A time limit after which the run stops and reports.
- A per-tool rate limit — refunds are limited to N per hour regardless of who asks.
- A "novel action" trigger: anything the agent has never done before pauses for a human.
Watch and read more
Lab
A permission audit that removes half your agent's rights without breaking it.
The problem
-- What did it actually use?
SELECT tool_name, COUNT(*) AS calls, MIN(created_at), MAX(created_at)
FROM agent_tool_calls
WHERE created_at > now() - interval '7 days'
GROUP BY tool_name
ORDER BY calls DESC;
-- What was granted but never used? That list is your blast radius for free.You are done when
Hard questions
Try to answer before you reveal. If you can answer these, you understood the lesson.
Q1An agent uses delete_user twice in a year, both legitimate. Keep it or remove it?Reveal
Q2Read-only access is often called safe. Construct a scenario where a read-only agent causes a worse outcome than a write-capable one.Reveal
Questions people ask
How narrow is too narrow?
If the agent constantly fails and asks for permissions, you were too narrow — but that is a great problem to have, because you learn the real requirement from real usage instead of guessing generously up front.
Should each agent have its own credentials?
Yes, always. Its own identity, its own scoped token, its own audit trail. Sharing a service account across agents destroys your ability to answer "which one did this?" — the first question anyone asks in an incident.
What about read-only access? Surely that's safe.
Read-only cannot destroy, but it can leak everything it can see. Scope reads as tightly as writes. "Read-only access to all customer records" is a data breach with extra steps.
Do approval gates actually work?
Only if the human understands the specific consequence. Rubber-stamp dialogs train people to click yes and are worse than nothing, because they create a false record of oversight. Show the amount, the recipient, the row count.
How do I retro-fit this to an agent already in production?
Turn on logging first, run for a week, then list every tool actually used and every scope actually touched. You will typically find that half the granted permissions were never exercised. Remove those, then start tightening the rest.
Lesson test
5 questions. Get 3 right (60%) to pass and complete this lesson.
Sign in with your phone number to take the test and save your progress