Skill in 《Tool Permission System》

Skill.md

Tool Permission System

Every agent that can edit files, run commands, or call external APIs eventually faces the same question on each tool call: auto-allow, ask the user, or deny? Scatter that decision across individual tools and your safety policy turns into an unauditable mess. This skill collapses it into one permission pipeline — every tool call passes through the same pipeline before execution, and it is the single place that decides allow / ask / deny.

Core Architecture

The pipeline order is deliberate, short-circuiting from the hardest block to the most permissive default:

There are only three decision behaviors: allow, deny, ask. Don't invent new states.

Layered Rule Sources

Rules layer by scope, highest priority first: policySettings (enterprise admin, non-overridable) → userSettings → projectSettings → localSettings → cliArg → command → session. The key is that conflicts are settled by behavior order: the pipeline checks deny across all sources first, then ask, and only then allow — so enterprise enforcement always beats a user allowlist.

When to Use It

Use this skill when building or reviewing:

• allow / ask / deny decisions for tool calls
• rule configuration across project / user / enterprise scopes
• a tool-level checkPermissions() contract
• non-bypassable guardrails for dangerous operations (safetyCheck)
• a hook system's configuration format and lifecycle
• unattended / CI auto-deny plus an AI-classifier circuit breaker

How to Use

1. Implement hasPermission(tool, input, context) that short-circuits in the order above.
2. Implement checkPermissions() per tool for tool-specific rules and dangerous paths.
3. Configure layered rules and hooks via settings.json; add the dontAsk wrapper for unattended runs.

Boundaries

This skill only owns the design and implementation of the permission decision. It does not own a tool's business logic, the confirmation-dialog UI, user identity authentication, or the prompt engineering of an AI classifier.