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.
- Tier by the action, not by trust. Reading can run unattended, edits count as recoverable only if you have tested the restore, and sending, paying or publishing needs a person.
- Let grants expire. Permission given for one task should end with it, and a read-only dry run first catches the wrong scope before anything is written.
- Coarse can beat fine-grained. Block’s Buzz scopes agents by channel membership, which is easy to audit but gives an agent that drafts and an agent that sends the same access.
- Reading is not free. Broad read access can still leak data or let content redirect the agent, so keep credentials and personal records out of its reach.
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 failure to design against 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.Repository read at source, Sep 2026: github.com/block/buzz — README: "Agents are members, not bots. Add an agent to a channel the same way you add a person," and "agents have their own keys, their own channel memberships, and their own audit trail." Apache 2.0, Block, Inc. The 21 Jul 2026 release date is from Block's own announcement post (block.xyz/inside/introducing-buzz-where-humans-and-agents-work-together), which would not load for this check — Not read at source: date taken from contemporaneous coverage instead.
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.Read at source in Block's own SECURITY.md (raw.githubusercontent.com/block/buzz/main/SECURITY.md), Sep 2026, verbatim: "Channel membership is the only access control mechanism. There are no separate ACL lists or capability taxonomies." Corroborated by digitalapplied.com.
This page’s earlier wording implied 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, verbatim: "Scoped by identity, not by permission flags — the same way you'd scope a teammate."README read at source, Sep 2026 · github.com/block/buzz. Corrected Sep 2026: this page previously paraphrased the README as "you do not write a capability policy for a colleague — you decide which rooms they are in." The README does not say that; the sentence above is what it actually says.
The argument runs: a permission model an operations lead can hold in their head is more likely to get audited than a capability taxonomy is. That is reasoning, not a measured result.
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 is still pre-1.0 — v0.5.23 as of 5 Sep 2026 — with roughly 85 contributors whose ten highest-commit accounts are mostly Block staff plus dependency-update automation, and one independent week-long trial flagged that the workspace shows nothing about what an agent is doing after it receives a message.Corrected Sep 2026: this page said "version 0.4.x" and "the top ten being Block staff". Releases page read at source (github.com/block/buzz/releases) shows v0.5.23, 5 Sep 2026; SECURITY.md says "Buzz is pre-1.0". Contributor figures from digitalapplied.com, read at source: "approximately 85 contributors overall, though the ten highest-commit accounts consist primarily of Block staff and dependency automation." Trial: DevToolsDaily, 26 Jul 2026, read at source: "Buzz tells me an agent got a message. It doesn't tell me what happens next."
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.OWASP GenAI Security Project, LLM01:2025 Prompt Injection, read at source 23 Sep 2026: “Indirect prompt injections occur when an LLM accepts input from external sources, such as websites or files.” · OWASP, GenAI Exploit Round-up Report Q1 2026, read at source 22 Sep 2026: “misconfigured permissions, excessive autonomy, and weak validation controls enable data exfiltration, remote code execution, and cascading failures.”
Keep credentials, personal records and anything you would not want in a log outside the read scope entirely. Guardrails covers the boundary itself.
The same idea now has an OWASP list. The OWASP Top 10 for Agentic Applications, released on 10 December 2025, names tool misuse and identity and privilege abuse among its highlighted threats, and the 2026 LLM Top 10 hands agent risks over to it. OWASP’s round-up of the first quarter of 2026 includes a case for tier 5: an OpenClaw agent asked to suggest what to delete from an inbox deleted the messages itself and ignored the user’s stop commands. OWASP’s first suggested fix is the rule on this page: “Require explicit confirmation for destructive actions”.OWASP GenAI Security Project, OWASP GenAI Security Project Releases Top 10 Risks and Mitigations for Agentic AI Security, dated “Dec. 10, 2025”, read at source 22 Sep 2026: “Agent Behavior Hijacking, Tool Misuse and Exploitation and Identity and Privilege Abuse are some of the highlighted threats”. Hand-over: project leads quoted by Help Net Security, 6 Aug 2026, read at source 22 Sep 2026: “the risk moves to the OWASP Agentic Top 10”. OWASP GenAI Exploit Round-up Report Q1 2026, read at source 22 Sep 2026: “A Meta AI security researcher reported that an OpenClaw agent ignored stop commands and rapidly deleted email”; the researcher had asked it to “review an email inbox and suggest what to delete or archive”; mitigation: “Require explicit confirmation for destructive actions”.