design-agent-permissions

Goal

Create a permission model that makes concrete tool and action permissions predictable, reviewable, and safe to enforce.

Inputs

• Available tools and side effects
• Risk tolerance
• Operating environment and trust assumptions

Non-Goals

• Implementing the permission UI or backend
• Defining the broader cross-cutting autonomy policy for the whole agent
• Replacing explicit permission mechanics with vague caution language

Workflow

Trigger signals

• Autonomy policy exists but tool-level permissions haven't been mapped
• User asks "哪些操作需要审批" or "what needs approval"
• The team already agrees on checkpoint philosophy, but still needs concrete permission classes for writes, external calls, or destructive actions
• Checkpoint rules exist in prose but not as enforceable defaults
• Not for deciding the overall autonomy policy or checkpoint philosophy — that belongs in guardrails

1. Inventory concrete action classes

Import the reads, writes, shell commands, external calls, and irreversible side effects that the autonomy policy already identified. Success criteria: The permission design is grounded in real actions rather than vague labels like "safe" or "unsafe."

2. Group actions into permission classes

Organize actions by the specific enforcement mechanics they need, such as pre-approved reads, confirm-before-write operations, or deny-by-default external side effects. Success criteria: Similar actions share permission mechanics for concrete, explainable reasons.

3. Map policy tiers into enforceable defaults

Translate the chosen autonomy and checkpoint policy into concrete defaults for each permission class. Success criteria: Every important action class has an explicit default policy that references an existing autonomy decision rather than inventing a new one.

4. Define denial and ambiguity behavior

Specify what the agent should do when permission is denied, partially granted, or unclear. Success criteria: The agent does not improvise risky behavior when constraint appears.