Controlling Tool Access

What an agent cannot do is as important as what it can. Tool access determines the blast radius of a mistake, a compromised instruction, or a model that misreads the task.

Grant capabilities by role

Start from no access and add only what each role needs:

• A researcher can read and search.
• A reviewer can inspect artifacts and run safe checks.
• An implementer can modify an explicitly scoped workspace.
• An orchestrator can dispatch work but does not automatically need broad write access.

Role-scoped toolsets create a security boundary, as developed in Security & Prompt Injection. They also force clear delegation, as developed in Cohort.

Match control to consequence

Use explicit resource patterns instead of broad wildcards. Require confirmation for irreversible or high-impact actions. Recheck authorization when a delayed action resumes, because the permission that existed when work started may no longer be valid.

Prompt instructions can remind an agent about a boundary, but they cannot enforce it. Enforce consequential restrictions in the harness, tool implementation, operating system, or external authorization layer.

Record every consequential action

Log the tool selected, validated inputs, authorizing identity, result, and any approval involved. Those records feed the Execution Ledger, giving operators and evaluators evidence of what actually happened.

Permissions control authority. The next chapter addresses a different design choice: how capabilities should be packaged and loaded.