Agent sandboxing & execution security

Toggle permissions with no task in mind at all. Each one has its own cost — "execute arbitrary code" is weighted far higher than "read files" — and the bars simply add: granting more never makes the total blast radius smaller.

Each permission $i$ carries a fixed risk weight $w_i$. A grant is a 0/1 indicator $g_i$ — off or on. The blast radius of a grant set is just the sum of the weights actually switched on, and a task succeeds only if every permission it genuinely requires is among them.

• $g_i$ — whether permission $i$ is granted (1) or not (0).
• $w_i$ — the fixed risk weight of permission $i$ (read: 1, write: 2, call an API: 3, execute code: 5).
• $R$ — the set of permissions the task actually requires.
• $\subseteq$ — every permission in $R$ must also be in $\mathbf{g}$; extra permissions in $\mathbf{g}$ beyond $R$ don't help.

1. The task fixes R, not the agent's convenience

   "Fetch the latest price from an API and save it to a file" needs exactly write and api — nothing about the task touches the filesystem's existing contents or requires running arbitrary code.

2. R = {write, api} sets a floor, not a target

   $\text{blast radius} = w_{\text{write}} + w_{\text{api}} = 2 + 3 = 5$ is the minimum achievable while the task still succeeds — you cannot go lower without breaking it.

3. Granting more only raises the sum

   Adding read on top costs $+1$ for zero gain: the task doesn't use it, so blast radius rises to 6 while capability stays exactly the same.

4. Granting everything is the worst case, not the safe default

   $1 + 2 + 3 + 5 = 11$ — more than double the minimal 5 — for a task that only ever touches two of the four permissions.

Task: fetch the latest price from an API and save it to a file.

With the task now stated explicitly, the readout tracks two things at once: whether it succeeds, and whether the current grant set is minimal. Start from every permission granted and remove them one at a time — the task keeps succeeding right up until you drop write or api.

Starting from all four permissions granted, remove permissions one at a time and watch both numbers:

1. All four granted

   blast radius $= 1+2+3+5 = 11$. Task succeeds — write and api are both present, plus two unused extras.

2. Remove execute

   blast radius $= 1+2+3 = 6$. Task still succeeds — execute was never in $R$, so removing it cost nothing in capability.

3. Remove read

   blast radius $= 2+3 = 5$. Task still succeeds, and this is now the minimum — both remaining permissions are in $R$ and neither can be dropped.

4. Remove api

   blast radius $= 2$. Task now fails — api was in $R$, so removing it breaks the task even though the blast radius dropped further.