正文
AI Agent 写代码的能力越来越强。它不只是回答问题，还能读取文件、修改代码、运行测试、安装依赖、提交变更，甚至调用外部工具。
权限设置得好，它是一个高效的工程协作者。权限设置得太松，它就是一个手速很快的风险源。
很多团队第一次使用 AI Coding Agent 时，会走向两个极端：要么什么都不让它做，效率很低；要么为了省事直接开全权限，结果 AI 改了不该改的文件、跑了不该跑的命令，甚至影响本地环境或生产配置。
更成熟的做法不是问“要不要给 AI 权限”，而是问三件事：哪些命令可以自动跑，哪些命令必须人工确认，哪些操作应该直接禁止。
先按影响半径分层
AI Agent 权限管理的第一原则是最小权限。
也就是说，Agent 只应该获得完成当前任务所必需的权限，而不是默认拥有整个项目、整个终端、整个网络和整个系统的控制权。
我觉得最有用的判断标准不是“这个命令常不常见”，而是“这个命令的影响半径有多大”。影响越小，越适合自动化；影响越大，越需要人类确认。
Claude Code 的 allow / ask / deny 规则、Codex 的 sandbox / approvals、Gemini CLI 的 sandbox expansion，本质上都在做同一件事：默认受限，按需提权，提权可见，操作可审计。
| 只读当前项目 | rg、git diff、git status |
| 本地验证 | pnpm lint、pnpm typecheck、pnpm test |
| 修改单个任务文件 | 编辑当前任务相关源码 |
| 改全项目格式 | prettier --write . |
| 改依赖和 lockfile | pnpm add、npm install |
| 改数据库结构 | prisma migrate、rails db:migrate |
| 删除文件或 Git 历史 | rm -rf、git reset --hard |
| 影响远程和生产 | deploy、push、publish |
可以自动跑的命令
可以自动跑的命令通常有三个特征：风险低、可重复、不会改变关键状态。
只读命令最适合自动放行。它们帮助 Agent 理解项目，不会修改文件，也不会改变系统状态。
本地验证命令也应该尽量放行。AI 写完代码后必须验证，否则“已完成”没有工程意义。
这里有两个边界。
第一，只读不等于完全无风险。cat .env 也是只读，但不应该允许。源码、测试、文档可以读；密钥、凭据、生产配置不能读。
第二，本地验证只在本地无副作用时自动跑。如果测试会连接真实数据库、调用外部 API、写入共享环境或修改远程资源，就必须人工确认。
格式化命令可以自动跑，但只应该格式化本次修改过的文件。不要为了修一个按钮运行全项目格式化。
这条规则能避免小任务变成大 diff。不要成为英雄。小 diff 更容易审。
# Read-only
pwd
ls
find
tree
cat
sed -n
grep
rg
head
tail
git status
git diff
git log
git show
# Local checks
pnpm lint
pnpm typecheck
pnpm test
pnpm build
npm run lint
npm run test
pytest
go test ./...
cargo test# Good
prettier --write src/components/Button.tsx
eslint --fix src/components/Button.tsx
# Ask first
prettier --write .
eslint --fix .必须人工确认的命令
需要人工确认的命令不一定都是危险命令，但它们会改变环境、依赖、数据库、远程状态，或者扩大 Agent 的权限边界。
这些命令应该默认 ask：
依赖安装尤其要谨慎。AI 很喜欢用新库解决问题，但团队维护的是长期项目，不是一次性 demo。新增依赖会改 lockfile，引入供应链风险，也可能影响 CI。
数据库命令也不应该自动跑。即使命令名看起来像开发环境，如果环境变量指向共享库或生产库，后果就完全不同。
网络命令需要说明访问目标、用途和传输数据。curl | bash 这类命令应该默认禁止，因为它下载并执行远程脚本。
Git 写操作要分开看。git status、git diff、git log 可以自动跑；git commit、git push、git reset、git rebase 不应该自动执行。
## Ask before running
### Dependencies
- npm install
- pnpm add
- yarn add
- pip install
- poetry add
- go get
- cargo add
### Database
- prisma migrate
- prisma db push
- rails db:migrate
- rails db:drop
- alembic upgrade
- sequelize db:migrate
### Git write operations
- git add
- git commit
- git push
- git checkout
- git rebase
- git reset
### Network
- curl
- wget
- ssh
- scp
- rsync
### Containers and services
- docker compose up
- docker compose down
- docker run
- kubectl必须禁止的操作
有些动作不要靠确认弹窗解决。直接禁止。
原因很简单：这些命令的失败模式太糟，影响半径太大。让 Agent 看到一个确认框，不等于它理解了这个动作的真实后果。
生产部署、基础设施变更、包发布、删除数据库、读取密钥、重写 Git 历史，这些都不应该交给 Agent 自动执行。
AI 可以帮你生成计划、解释风险、写配置、准备 diff。最后的 apply、deploy、push、publish，应该由人类执行。
## Deny
- rm -rf /
- rm -rf *
- git reset --hard
- git clean -fd
- docker system prune -a
- npm publish
- pnpm publish
- terraform destroy
- kubectl delete
- rails db:drop
- dropdb
- psql production
- curl * | bash
- wget * | sh
- commands that read `.env.production`
- commands that access production databases写进 AGENTS.md / CLAUDE.md
权限规则不要只写在聊天 prompt 里。Prompt 是一次性的，很容易忘记，也不方便团队共享。
更好的方式是把命令策略写进 AGENTS.md 或 CLAUDE.md。这不是替代工具权限配置，而是让 Agent 每次进入项目时都读到同一套工作边界。
真正的权限仍然要在 Claude Code、Codex、Gemini CLI 或你的运行环境里配置。文档负责让 Agent 知道该怎么做；沙箱和审批负责决定它能不能做。
# AGENTS.md
## Permission Policy
The AI agent must follow least-privilege rules.
### Auto-allowed
The agent may run these commands without asking:
- git status
- git diff
- rg
- pnpm lint
- pnpm typecheck
- pnpm test
- pnpm build
### Ask before running
The agent must ask before running:
- npm install
- pnpm add
- docker compose up
- prisma migrate
- git commit
- git push
- curl
- wget
### Never run
The agent must never run:
- rm -rf
- git reset --hard
- git clean -fd
- terraform destroy
- kubectl delete
- npm publish
- commands that read `.env.production`
- commands that access production databases
## File Safety
- Do not read or modify `.env`, `.env.production`, or files under `secrets/`.
- Do not modify CI/CD files unless explicitly requested.
- Do not modify database migrations unless the task explicitly requires it.
## Before finishing
The agent must report:
1. Files changed
2. Commands run
3. Tests passed or failed
4. Commands skipped due to permission rules
5. Risks and follow-up work不同工具里的落点
Claude Code 可以参考 allow、ask、deny 的思路。先放行只读和明确的本地检查，再把安装、提交、推送和网络动作放进 ask，最后把删除、密钥和敏感文件放进 deny。
Codex 里先从 workspace-write 和 on-request 开始。这个组合允许 Agent 在当前工作区内推进任务，同时把越界写入、网络访问和权限升级留给确认。
Gemini CLI 的沙箱扩权适合一次性动作，比如某个命令需要网络，或者需要访问工作区外的一个只读目录。不要把一次扩权变成长期默认。
非交互环境要更严格。CI、批量修复、自动化改代码，不应该让 Agent 临时决定要不要提权。只允许读文件、改指定目录、跑测试；禁止网络、新依赖、删除文件、push；所有超出规则的操作直接失败。
# Codex starting point
approval_policy = "on-request"
sandbox_mode = "workspace-write"
[sandbox_workspace_write]
network_access = false
writable_roots = []
[shell_environment_policy]
inherit = "core"
exclude = ["*KEY*", "*TOKEN*", "*SECRET*"]团队落地流程
权限体系不需要一次设计成很复杂。先做 6 步。
每次任务结束时，Agent 应该输出类似这样的记录：
这让人类能快速审查它做过什么，也能发现权限规则是否需要调整。
- 列出项目里的安全命令，例如
pnpm lint、pnpm typecheck、pnpm test、pnpm build。 - 列出高风险命令，包括依赖、数据库、生产、部署、删除、网络。
- 写入
AGENTS.md/CLAUDE.md，不要只靠口头约定。 - 使用沙箱、独立分支、临时 worktree 或容器，不要让 Agent 直接操作主分支和生产环境。
- 要求 Agent 在任务结束时输出命令记录。
- 定期审计权限规则，看白名单是否过宽、黑名单是否遗漏、测试命令是否过期。
Commands run:
- pnpm lint
- pnpm test
Commands skipped:
- pnpm add lodash, skipped because dependency changes require approval.常见错误
最常见的错误是为了省事直接开全权限。短期看效率提升，长期看风险很高。Agent 一旦拥有全权限，就可能删除文件、修改配置、安装依赖、访问网络、运行危险脚本、改 Git 历史、影响远程仓库。
第二个错误是只限制命令，不限制文件。AI 即使不跑危险 shell，也可能通过文件编辑造成风险，比如修改 .env、CI 配置、权限逻辑或数据库 migration。
第三个错误是允许 AI 自动装依赖。AI 很喜欢用新库解决问题，但长期项目最怕“为了一个小函数加一个包”。
第四个错误是没有命令记录。如果 AI 跑了什么命令没人知道，出了问题很难追溯。
第五个错误是测试命令不明确。如果你不告诉 AI 正确测试命令，它可能猜一个命令，然后得出错误结论。
FAQ
结论：不是管死，而是管准
AI Agent 权限怎么设？答案不是“全部禁止”，也不是“全部放开”，而是分级管理。
低风险、只读、本地验证命令可以自动跑；依赖、数据库、网络、Git 写操作必须人工确认；删除、生产部署、基础设施破坏、读取密钥这类高风险操作应该直接禁止或强确认。
一套成熟的 AI Agent 权限体系，至少应该包括自动允许清单、人工确认清单、禁止命令清单、敏感文件限制、沙箱隔离、命令执行日志、项目规则固化和人类最终审查。
AI Agent 真正适合做的，是在安全边界内快速完成重复工作，而不是拿着无限权限替人类做所有决定。
权限设得好，AI 是效率工具。权限设得差，AI 就是自动化风险。
在 AI 编程时代，最重要的不是让 Agent 跑得更快，而是让它只在该跑的地方跑，只做该做的事，只改该改的文件，只执行该执行的命令。