Five levels of permission, assigned per task by how hard the action is to undo rather than by how much you trust the agent — and why granted permissions should expire with the task.
- An email you are certain about is still an email you cannot unsend.
Decide what an AI is allowed to do based on how hard it is to undo, not on how much you trust it.
Reading something: fine, unattended. Editing a file with a backup: fine, if you have tested the backup. Sending an email: a person clicks send, every time.
Permission is not a setting you turn on once. It is a level you assign per task, and the level should follow how hard the action is to undo.
Five tiers
How to assign a tier
Not by how much you trust the agent. By what the action does. Three questions, in order:
- Can this be undone by re-running? → tier 1 or 2.
- Can this be undone by restoring something? → tier 3 or 4, and only if you have actually tested the restore rather than assumed it.
- Can this be seen by someone outside? → tier 5, without exception.
An email you are certain about is still an email you cannot unsend.
Escalation, not blanket grants
The common failure is granting tier 4 once because a tier 4 task came up, then leaving it there. Permissions granted for a task should expire with the task.
A practical pattern: run at tier 1 first, always. The dry run costs one extra pass and catches wrong scope before anything is written — see prompting agents.
What this looks like in a real system — and a correction
Buzz, open-sourced by Block on 21 July 2026 under Apache 2.0, is a workspace where AI agents join channels as members rather than as bots. Each agent holds its own cryptographic keypair, and every action lands in a signed audit log.block.xyz announcement, 21 Jul 2026 · github.com/block/buzz — verified 22 Aug 2026
An earlier version said Buzz lets you "decide exactly what each agent can do", and used it as an example of fine-grained per-agent permissions. Block's own security documentation says the opposite.
From SECURITY.md: channel membership is the only access control mechanism. There are no separate ACL lists or capability taxonomies.Block SECURITY.md, reported by digitalapplied.com, Aug 2026
Most coverage implies granular permissions. The repository does not. If a participant — human or agent — is in a channel, it can read and write there.
And the real design is the more interesting idea. Buzz scopes by identity and room rather than by capability flags. The framing in its own README: you do not write a capability policy for a colleague — you decide which rooms they are in.
A permission model an operations lead can hold in their head gets audited. A capability taxonomy usually does not.
That is a genuine argument against the tier model on this page, and worth taking seriously. Coarse and legible may beat fine-grained and ignored.
The counter is that a channel is a blunt instrument. An agent that drafts replies and an agent that sends them, both in #support, have identical access — which is precisely the collapse this page warns about, arriving by a different route.
Worth knowing before adopting either position: Buzz shipped at version 0.4.x, roughly 85 contributors with the top ten being Block staff, and one independent week-long test flagged that the workspace shows nothing about what an agent is doing after it receives a message.DevToolsDaily test, 26 Jul 2026 · contributor analysis, digitalapplied.com
What tiers do not cover
Reading is not free. An agent with broad read access can exfiltrate through any write it has, and can be redirected by content it reads. Tier 1 is safe from damage, not from disclosure.
Keep credentials, personal records and anything you would not want in a log outside the read scope entirely. Guardrails covers the boundary itself.