Tools & Permissions
Tool safety depends on three separate decisions: whether a capability exists, whether profile policy exposes it, and whether the current task authorizes its use. Read tools still need privacy limits. Write and external-action tools need tighter scope, approval, and read-back.
Record purpose, side effects, requirements, and data exposure.
Enable only families needed for that profile’s role.
Separate safe reads, reversible writes, external writes, destructive actions, and prohibited operations.
Bind each invocation to named inputs and destinations.
Read the exact target after writes and preserve evidence without secrets.
18 enabled public-safe families
What breaks—and how to recover.
Check profile policy and task authorization separately.
Use pointer-event and hit-testing checks for browser layers.
Verify the target state, not only the tool response.
Copyable implementation prompt
Create a least-privilege tool policy for [PROFILE]. Group tools into Read, Reason, Create, Act, and Coordinate. For each define availability, enablement, authorization, data boundary, approval level, side effects, rollback, and proof.
Use placeholders for paths, accounts, endpoints, identities, and credentials. Never publish secret values, private records, or a live control surface.
Verification gate
- All 18 relevant families are classified
- External and destructive effects require approval
- Secrets are excluded from prompts and logs
- Writes have exact read-back checks