Tool Permission Boundaries
Tool access is capability. A good Rocky setup gives the system enough reach to help, but not enough silent authority to damage accounts or private data.
When this matters
This page is for operators who want Rocky to produce usable work without turning the system into a mystery box. Use it when you need a practical path, a clear verification step, and a boundary between suggestion and action.
The operating pattern
- List each tool. Name browser, web, files, terminal, desktop, Gmail, Discord, or APIs separately.
- Define read vs write. A tool may be safe for reads but risky for writes.
- Add approval gates. Require approval for payments, DNS, fulfillment, account settings, and customer-facing writes.
- Prefer APIs for repeatable work. APIs are easier to audit than GUI clicks.
- Verify after action. Every write needs a read-back check.
Pre-flight checklist
- Each tool has a reason
- Write actions are explicit
- Secrets are never typed by Rocky
- Dangerous workflows have confirmations
- Logs identify what changed
Common failure modes
- All-or-nothing access: A toolset should match the workflow, not the user’s entire life.
- GUI-only automation: Use desktop control when needed, but prefer APIs for stable operations.
- No verification: A clicked button is not proof that the state changed.
Verification
A page is not done because it was drafted. Verify the source, run the workflow, inspect the output, and record what changed. If a step touches money, customers, accounts, permissions, or private data, keep it behind an explicit human approval gate.