# Design Agent Permissions

> Use after autonomy policy is set and you need permission classes, defaults, approvals, and denial behavior.

- **Type:** Skill
- **Install:** `agentstack add skill-bikeread-promethos-design-agent-permissions`
- **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior
- **Seller:** [bikeread](https://agentstack.voostack.com/s/bikeread)
- **Installs:** 0
- **Category:** [Agent Skills](https://agentstack.voostack.com/c/agent-skills)
- **Latest version:** 0.1.0
- **License:** MIT
- **Upstream author:** [bikeread](https://github.com/bikeread)
- **Source:** https://github.com/bikeread/promethos/tree/main/skills/design-agent-permissions

## Install

```sh
agentstack add skill-bikeread-promethos-design-agent-permissions
```

Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent.

## About

# 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.

### 5. Check least privilege against actual usability
Tighten permissions enough to reduce risk, but not so much that ordinary work
requires constant escalation.
**Success criteria**: The model is both safer and still operable for the target
job.

## Output Contract
A permission policy with:
- action classes,
- permission classes,
- mappings from autonomy policy to permission defaults,
- explicit confirmation thresholds,
- denial and ambiguity behavior.

## Escalation
Pause when:
- one permission rule is being used for materially different action types,
- denial behavior would silently corrupt outputs or state,
- frequent escalations suggest the policy is mismatched to the job,
- destructive actions are being bundled into broad approvals,
- the discussion drifts from permission mechanics into a broader autonomy
  philosophy that belongs in guardrails.

## Common Failure Modes
- Broad approvals for convenience
- Smuggling autonomy-policy decisions into permission mechanics
- Inventing new checkpoint policy inside the permission layer
- Implicit trust in destructive commands
- Undefined behavior after denial

## Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

- **Author:** [bikeread](https://github.com/bikeread)
- **Source:** [bikeread/promethos](https://github.com/bikeread/promethos)
- **License:** MIT

Install and usage instructions live in the source repository linked above.

## Pricing

- **Free** — Free

## Security capabilities

Automated source analysis of v0.1.0 — what this tool can access:

- **Network access:** no
- **Filesystem access:** no
- **Shell / process execution:** no
- **Environment & secrets:** no
- **Dynamic code execution:** no

*"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.*


## Versions

- **0.1.0** — security scan: passed — Imported from the upstream source.

## Links

- Listing page: https://agentstack.voostack.com/l/skill-bikeread-promethos-design-agent-permissions
- Seller: https://agentstack.voostack.com/s/bikeread
- Browse the marketplace: https://agentstack.voostack.com/browse

---
Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.