# Sizing an agent's blast radius > Read an agent's permission list as read, write and send rows, cut it down to the task, and put the one approval on the row that can't be undone. Page: https://schubergphilis.github.io/ai-training/safety/sizing-the-blast-radius/ License: CC BY-SA 4.0, https://creativecommons.org/licenses/by-sa/4.0/ Someone on a team of five wants an agent to tidy the shared folder `Projects/2025`: one subfolder per month, and no duplicate copies of the same file. The agent product asks what the agent may use, and the person ticks boxes until the setup screen stops asking. In this lesson we go through the permission list that came out of that screen and work out what each row reaches. Then we cut it down to the task and choose the one row where a person has to approve. An agent works in a [loop](https://schubergphilis.github.io/ai-training/concepts/agent-loop/#a-model-in-a-loop-with-two-tools): it looks at the task, picks a tool, runs it and reads the result, and repeats. Each tool call uses one of the rows below. The agent can use any row on any turn of the loop, even a row the task never needs. This is the permission list as granted. The team, the folders and the numbers are invented for this lesson. ```text Task: tidy the folder Team drive/Projects/2025. Sort the files into one subfolder per month and remove duplicate copies. Permission list as granted row kind where actions 1 read Team drive, every folder open, list 2 write Team drive, every folder create, move, rename 3 write Team drive, every folder delete (no trash) 4 read your mailbox open, search 5 send mail from your address to any address 6 send all-staff chat channel post Who can see each place Team drive, every folder 14 people Team drive/Projects/2025 5 people all-staff chat channel 120 people ``` ## What the list reaches A small program reads the list. For each row it prints who the row reaches and whether its actions can be undone. Its rule for undo is the plain one. Reading doesn't change anything, so there is nothing to undo. On this drive a move never replaces a file: two files with the same name are kept side by side, so a move or a rename can be moved or renamed back. A delete with no trash can't be restored, and a message that someone has read can't be taken back. #### Checkpoint: Which rows can't be undone? The program ends its report with the rows whose actions can't be undone. Type their numbers from lowest to highest, separated by spaces. For the list as granted, the program prints this report. ```text as granted row 1 read Team drive, every folder: open, list reaches: 14 people can be undone: nothing to undo row 2 write Team drive, every folder: create, move, rename reaches: 14 people can be undone: yes row 3 write Team drive, every folder: delete (no trash) reaches: 14 people can be undone: no row 4 read your mailbox: open, search reaches: you, and everyone who wrote to you can be undone: nothing to undo row 5 send mail from your address: to any address reaches: anyone with an address can be undone: no row 6 send all-staff chat channel: post reaches: 120 people can be undone: no rows that cannot be undone: 3, 5, 6 most people one wrong step can affect: anyone with an address ``` The task is about one folder that 5 people use. The list reaches files of 14 people on the drive, a mailbox with other people's mail in it, 120 people in the chat channel, and anyone with a mail address. Three rows can't be undone, and two of them send something to other people. That's the **blast radius** of this agent: what a wrong step can reach with the access it has. The request says "tidy one folder", and the list sets the size. Look at the last line of the report. One wrong step, such as a reply to a mail that the agent took for an instruction, can reach anyone. The tidy-up never needed that row. ## Write the list as read, write and send rows The setup screen sorts the access by product, such as the drive, the mailbox and the chat app. To size the blast radius, regroup the same access by what it does to the world. - **Read** rows let the agent see something. They don't change anything, but what the agent reads can end up in what it writes or sends. - **Write** rows change something that you or your team own. Some writes can be put back, like a move, and some can't, like a delete with no trash. - **Send** rows deliver something to another person or system. Once the message has been read, you can't take it back. Then go down the rows and ask one question of each: does the task need this? Cross out every row where the answer is no, and narrow every row you keep to the place the task is about. This is least privilege: the agent gets the access the task needs and nothing more (Guardrails and safety: why agent safety differs, defense layers, injection, human in the loop, Agent Engineer Course). For the tidy-up, rows 4, 5 and 6 go, because sorting files uses neither mail nor chat. Rows 1, 2 and 3 stay, because the agent has to see the files, move them, and remove the duplicates. All three shrink from "every folder" to `Projects/2025`. The same program prints the new list. ```text as the task needs row 1 read Team drive/Projects/2025: open, list reaches: 5 people can be undone: nothing to undo row 2 write Team drive/Projects/2025: create, move, rename reaches: 5 people can be undone: yes row 3 write Team drive/Projects/2025: delete (no trash) reaches: 5 people can be undone: no rows that cannot be undone: 3 most people one wrong step can affect: 5 people ``` The task is the same. The most people one wrong step can affect went from anyone with an address to 5 people, and one row that can't be undone is left. #### Pitfall: Granting the whole drive to save a click The setup screen offers "this folder" or "the whole drive", and the person picks the whole drive because it needs no path. Later the agent removes duplicates in another folder and takes a file with the same name in a colleague's folder for a copy. Because the grant covered the whole drive, the mistake deleted a colleague's file. Grant the folder the task is about, and grant again when the next task needs more. ## Place the approval on the row that can't be undone After the cut, one row is left that can't be undone: row 3, the delete. A person approves right before the agent deletes. The moves and renames in row 2 don't need an approval, because on this drive a wrong move can be moved back, and row 1 doesn't change anything. An approval on every move would ask the person dozens of times, and after the tenth time they stop reading. Keep the approvals few, and each one gets read. An approval is only as good as what the approver sees. If a prompt says "Delete the duplicates? yes / no", it asks the person to guess. To judge a duplicate, the approver needs each file the agent wants to delete next to the copy that stays, with the name, the folder, the date and the size of both. Then a wrong pair stands out: two files with the same name and different sizes aren't duplicates. The agent should hand over what the person needs to decide, so that the person doesn't have to ask (Guardrails and safety: why agent safety differs, defense layers, injection, human in the loop, Agent Engineer Course). A yes to the plan at the start doesn't replace this approval. "Sort by month and remove duplicates" reads well as a plan, and it says nothing about which files the agent later calls duplicates. The mistake happens in the middle of the work, at the delete. Row 3 can also be handled another way. Change the delete into a move to a folder called `duplicates`, and a person empties that folder after looking at it. The agent then has no row that can't be undone, and the person does the delete. Sorting the work by whether it can be undone is a standard step before you hand work to an agent (Guardrails and safety: why agent safety differs, defense layers, injection, human in the loop, Agent Engineer Course), and the move to a folder puts this delete on the side that can be undone. #### Checkpoint: Where does the person approve? The permission list is cut down to the three rows the task needs. You may put one approval step on it. Where does it go, and what does the approver see there? - Before each move and rename in row 2, with the old and new path shown for each file. - Before the delete in row 3, with each file shown next to the copy that stays. - Before the agent reads the folder in row 1, with the list of files it will open. - Once at the start, when the person approves the plan to sort and remove duplicates. ## Exercise Pick a task you would like an agent to do for you, such as sorting mail, filing documents or filling in a form. On paper, or in a note, write the permission list the agent would get from the boxes you tick by habit. Write each row as read, write or send, with the place it applies to. Cross out every row the task doesn't need, narrow the rest to the place the task is about, and mark the one row where a person approves, with a line on what that person sees. Writing the rows yourself shows you what the agent could reach before it reaches anything. A good result has at least one crossed-out row you would have granted without thinking, and a marked row that can't be undone or that reaches other people. The line under it names things the approver can check, such as names, counts or samples, and never only "yes or no". If nothing is crossed out, ask of each row which step of the task uses it. What did the unchecked list reach that you hadn't thought of? ## Recap 1. Write an agent's access as read, write and send rows, each with a place, and ask of each row who it reaches and whether it can be undone. 2. The tools and places an agent is connected to set its blast radius, whatever the request says. 3. Cross out every row the task doesn't need and narrow the rest to the place the task is about. The agent does the same task, and a wrong step reaches fewer people. 4. Put the approval right before the step that can't be undone or that reaches other people, and show the approver the evidence to judge it, such as the files themselves or a count with samples. #### Habit The next time a setup screen asks what an agent may use, write down the read, write and send rows it would get before you tick the boxes. ## References - Guardrails and safety: why agent safety differs, defense layers, injection, human in the loop, Agent Engineer Course, https://lsimons.github.io/agent-engineer-course/10-guardrails-and-safety/