Permissions and safety
The trust boundaries that constrain what an agent can read, execute, change, publish, purchase, or send on a user's behalf.
Use it when
- Always—especially when tools reach files, networks, credentials, production systems, or other people.
- An agent or subagent can perform side effects without continuous supervision.
- Downloaded plugins, hooks, or MCP servers introduce new executable code or data access.
Choose another layer when
- A prompt-only promise where a platform policy, sandbox, or approval boundary is available.
- Permanent broad access granted to avoid designing a narrower workflow.
Production path
Build it in this order
- 01
Map actions to authority
Classify each capability by data access, side effect, reversibility, cost, and who or what it affects.
Quality check: Every meaningful action has an explicit authorization source.
- 02
Enforce boundaries outside the prompt
Use sandboxing, scoped credentials, allowlists, policy hooks, approval gates, and protected environments.
Quality check: Ignoring an instruction cannot bypass the critical control.
- 03
Log and rehearse recovery
Preserve tool calls and approvals without leaking secrets; test denial, timeout, rollback, and credential revocation paths.
Quality check: Operators can reconstruct what happened and contain a bad run.
Artifacts you may see
- permission policies
- sandbox configuration
- allow and deny rules
- audit logs
Connected layers
Evidence ledger
Primary documentation behind this guide
Provider-specific behavior is sourced to that provider. Open standards are sourced to their specifications and official maintainers.