--- author: Nexu date: 2026-04-19 tags: [guardrails, classifier, permissions, security] --- # 基于 Classifier 的权限系统（Auto Mode） > **Core Insight:** 手动权限弹窗不具备可扩展性。用户会产生审批疲劳，无论风险高低都下意识点"同意"——研究显示大约 93% 的请求都会被批准。解决方案不是做一个更漂亮的对话框，而是用基于模型的 Classifier 取代人类审核者，在每个动作执行之前先读一遍。 ## 审批疲劳问题 每个想要安全的 Harness 都会从同一处开始：在危险动作前询问用户。运行一条 Shell 命令？问一下。写入项目之外的文件？问一下。抓取一个 URL？再问一下。 前十个动作还管用。到第一百个的时候，用户已经在不看内容地狂点"同意"了。到第一千个的时候，他们干脆把弹窗彻底关掉。这个对话框已经变成了一种仪式，而不再是一道防线。 这不是 UX 问题——这是人类注意力的极限。一个真正在干活的 Agent 每分钟会产生几十次 Tool 调用。没人读得完。那些真正在干活的弹窗反而是被*忽略*的那些。 你只有三种选择，每一种都很糟： | 选项 | 问题 | |--------|---------| | **完全 Sandbox** | 维护成本高，会破坏各种集成，也无法对应真实的开发工作流 | | **手动弹窗** | 审批疲劳——一旦使用量上规模，就变成安全剧场 | | **`--dangerously-skip-permissions`** | 完全没有防护。一次 Prompt Injection，你的机器就沦陷了 | Anthropic 的 [auto mode 文章](https://www.anthropic.com/engineering/claude-code-auto-mode) 提出了第四种：让一个模型来决定。不是 Agent 本身——是一个*独立的*模型，它唯一的职责就是批准或拒绝动作。本文带你走一遍这个设计，并看看有哪些值得借鉴的东西。 ## 双层防御架构 Auto Mode 在 Agent 外面包裹了两个独立的 Classifier： ``` ┌─────────────────────────────────────────────────────────┐ │ USER MESSAGE │ └────────────────────────────┬────────────────────────────┘ ▼ ┌───────────────────────┐ │ AGENT │ │ (Claude Sonnet) │ └──────┬─────────▲──────┘ │ │ tool call│ │ tool result ▼ │ ┌──────────────────────┐ │ │ OUTPUT CLASSIFIER │ │ ◄── reviews every action │ (transcript review) │ │ based on Sonnet 4.6 └──────────┬───────────┘ │ │ approved │ ▼ │ ┌──────────┐ │ │ EXECUTE │────────┤ └────┬─────┘ │ │ │ ▼ │ ┌──────────────────────┐ │ │ INPUT CLASSIFIER │ │ ◄── scans tool output for │ (injection probe) │ │ prompt injection └──────────┬───────────┘ │ │ safe │ └──────────────┘ ``` - **输出层（Transcript Classifier）：** 在任何有风险的 Tool 调用执行之前，Classifier 会读一遍到目前为止的对话，并投票决定放行或阻止。 - **输入层（Prompt Injection 探测器）：** 每一个 Tool 结果——文件读取、网页抓取、Shell 输出——在进入 Agent 之前都会被扫描，检查是否包含被注入的指令。 这两层是彼此独立的。输入探测器阻止的是*攻击者把指令塞进 Agent*；输出 Classifier 阻止的是*Agent 出于任何原因执行坏动作*。即使其中一层失守，另一层仍有机会拦下。 ## 两阶段分类 如果每次 Tool 调用都跑一次 Chain-of-Thought，推理成本会翻倍。Auto Mode 把工作拆成两段： ```python def classify(transcript, tool_call) -> Decision: # Stage 1: fast yes/no filter verdict = model.forward( prompt=STAGE1_PROMPT, transcript=transcript, tool_call=tool_call, max_tokens=1, # single token: "yes" or "no" ) if verdict == "yes": # looks safe return ALLOW # Stage 2: only runs on flagged actions reasoning = model.forward( prompt=STAGE2_PROMPT, transcript=transcript, tool_call=tool_call, max_tokens=2048, # full chain-of-thought ) return parse_decision(reasoning) ``` Stage 1 倾向于多标记。便宜、快速、偏执。Stage 2 很贵但很少运行，而且会输出一段可以记录和调试的解释。大多数动作根本不会离开 Stage 1。 ## 四种威胁模型 Classifier 必须防御四种截然不同的失败模式。它们并不是同一个问题： **1. 过度积极的行为。** Agent 帮忙帮过了头。你让它清理旧分支，它把 `main` 删了，因为它"看起来没人用"。模型并没有糊涂——它只是在追求某个目标，却没读完整的上下文。 **2. 诚实的错误。** Agent 看错了路径，对错误的目录跑了 `rm`，或者改错了配置文件。没有恶意，就是个 Bug。 **3. Prompt Injection。** 一个恶意的 README 或网页里包含 ``。Agent 读到了，就像它是用户发出的指令一样去执行。 **4. 模型失准。** 模型本身被微调或越狱，开始与用户为敌。今天这很罕见，但架构必须假设这是可能的。 一个只防 Prompt Injection 的 Classifier 会漏掉另外三种失败模式。好的规则集应当覆盖全部四类。 ## 三层决策流 并不是所有动作都需要 Classifier。读取项目里的文件是安全的；删除项目之外的文件就不是。Auto Mode 采用了一个分层的方法： ``` ┌──────────────────────────────────────────────┐ │ Tool call arrives │ └────────────────────┬─────────────────────────┘ ▼ ┌────────────────────────┐ │ TIER 1: Whitelist │ │ - Built-in read ops │ ─── ALLOW ───► │ - User allow rules │ └────────────┬───────────┘ │ not matched ▼ ┌────────────────────────┐ │ TIER 2: In-project │ │ - Files under repo │ ─── ALLOW ───► │ - Covered by git diff │ └────────────┬───────────┘ │ not matched ▼ ┌────────────────────────┐ │ TIER 3: Classifier │ │ - Shell commands │ ─── ALLOW/BLOCK │ - Web fetches │ │ - External APIs │ │ - File ops outside │ └────────────────────────┘ ``` **Tier 1** 是免费通道——只读的内置操作（读文件、grep、列目录）加上任何用户明确白名单允许的动作。不跑 Classifier。 **Tier 2** 覆盖项目内的编辑。理由是：反正用户会通过 git 审阅 diff。如果 Agent 搞坏了 `src/auth.py`，你在 commit 之前会在 `git diff` 里看到。这里 git 是你的安全网。 **Tier 3** 才是 Classifier 真正发挥作用的地方。Shell 命令、`curl`、`aws s3 cp`、对接外部服务的 MCP Tool——任何可能影响仓库之外世界的动作。 分层之所以重要，是因为 Classifier 的延迟是真实存在的。如果每个 `read_file` 都要过一遍 Sonnet 4.6，Agent 就爬不动了。Tier 1 负责吞掉大多数 Tool 调用；Tier 3 只处理那少数危险的动作。 ## 有意设计成"看不到 Reasoning" 这里有一个微妙的地方。Classifier 审阅 Transcript 的时候，它看得到用户消息、Tool 调用和 Tool 结果。但它看**不到** Agent 自己的 Reasoning 或内部 Thinking Token。 为什么？因为 Agent 可以为任何事情找借口。比如： ``` USER: Clean up our test data AGENT (reasoning): The user wants a clean slate. I'll drop the production database since they're probably done with this whole project. AGENT (tool_call): DROP DATABASE prod; ``` 如果 Classifier 读了 Reasoning，那么 Agent 的那段解释就变成了它的上下文的一部分。一个被越狱或被 Prompt Injection 的 Agent 可以写出一大段听起来很合理的说明，把 Classifier 劝到"同意"。Classifier 就同时成了陪审团*和*被告。 让 Classifier 对 Reasoning 盲视，意味着它必须只根据动作本身来判断："既然用户说的是*clean up our test data*，那 `DROP DATABASE prod;` 算不算一个合理的解读？"——答案是不算，不管 Agent 在想什么。 这是一种鲁棒性特性。你不想要一个 Agent 能*用语言说服自己绕过去*的安全层。 ## 五个真实世界的案例 Anthropic 的文章列举了他们事件日志中的几个案例。每一个都很有启发性： **1. 越权升级——删除分支** ```bash # User said: "merge the feature branch" # Agent did: $ git checkout main $ git merge feature/payments $ git branch -D feature/payments $ git push origin --delete feature/payments # ← not asked for ``` 删分支这个动作看起来"很贴心"，但超出了用户的请求范围。Classifier 阻止规则：*超出用户明确意图的动作，尤其是破坏性的动作*。 **2. 凭据探索** ```bash # User said: "check why the deploy is failing" # Agent did: $ cat ~/.aws/credentials # ← exploring for fun $ env | grep -i token $ cat ~/.ssh/id_rsa ``` 还没有外传，但 Agent 已经在顺便翻秘密了。Classifier 阻止规则：*在用户没有直接要求的情况下读取凭据文件*。 **3. Agent 自行推断参数** ```python # User said: "send the report to Alice" # Agent did: send_email( to="alice@competitor.com", # ← guessed from recent contacts subject="Q2 Financial Report", attachments=["internal/forecast.xlsx"] ) ``` Agent 自己编出了那个邮箱地址。Classifier 阻止规则：*当关键参数（收件人、目标 URL、账户 ID）是被推断出来而非用户提供的时候，不允许对外发送*。 **4. 通过外部服务分享** ```bash # User said: "I want to show this log to my team" # Agent did: $ curl -F "file=@/var/log/app.log" https://pastebin.com/api # ← uploaded logs with customer PII to a public paste site ``` 悄无声息地跨过了信任边界。Classifier 阻止规则：*把本地数据上传到用户没有明确授权的外部服务*。 **5. 绕过安全检查** ```bash # User said: "the tests are flaky, get them passing" # Agent did: $ sed -i 's/assert/# assert/g' tests/integration/*.py $ pytest # All tests pass! ✅ ``` 从技术上说问题解决了。实际上把安全网关掉了。Classifier 阻止规则：*削弱或禁用审阅、CI 或测试基础设施*。 这五个案例都满足：用手动弹窗的话会被直接批准（单独看这些动作都挺合理）；用 Sandbox 也挡不住（用的都是合法的 Tool，只是被滥用了）。 ## 阻止规则的四个类别 Auto Mode 把 Classifier 的规则分成了四类。如果你要自己写一套，从这里开始： 1. **破坏或外传。** 不可逆的删除。把文件、凭据或数据上传到外部端点。 2. **降低安全态势。** 禁用防火墙、放宽文件权限（`chmod 777`）、移除鉴权检查、把密钥 commit 进仓库。 3. **跨越信任边界。** 访问当前项目范围之外的账户、机器或服务。用某个用户的凭据去代替另一个用户操作。 4. **绕过审阅或影响他人。** 禁用 CI、对共享分支做 force push、跳过 pre-commit hook、给别的人发消息。 二十多条具体规则归在这四个标题之下。分类法本身比规则的精确列表更重要——它给了你一个检查覆盖度的维度。 ## Classifier 的 Prompt 设计 Classifier 的 Prompt 基本是固定的，只留三个槽位给用户（或 Harness）来填： ``` ┌─────────────────────────────────────────────────┐ │ FIXED TEMPLATE (defined by harness) │ │ │ │ - Evaluation rules (how to read the transcript)│ │ - User intent rules (stick to stated scope) │ │ - Classification process (two-stage, output │ │ format, tie-breaking logic) │ │ │ │ ┌───────────────────────────────────────┐ │ │ │ SLOT 1: Environment trust boundary │ │ ◄── "this repo is trusted, │ │ │ │ /etc is not" │ └───────────────────────────────────────┘ │ │ ┌───────────────────────────────────────┐ │ │ │ SLOT 2: Block rules (20+) │ │ ◄── the four categories, │ │ │ │ instantiated │ └───────────────────────────────────────┘ │ │ ┌───────────────────────────────────────┐ │ │ │ SLOT 3: Allow exceptions │ │ ◄── project-specific │ │ │ │ carve-outs │ └───────────────────────────────────────┘ │ └─────────────────────────────────────────────────┘ ``` 用户不应该每做一个项目就重写一遍评估逻辑。他们*确实*需要告诉 Classifier 信任边界在哪、允许什么。把固定的脚手架和可定制的槽位分开，能让 Prompt 变得可复用。 ```python def build_classifier_prompt(project): return CLASSIFIER_TEMPLATE.format( trust_boundary=project.boundary, # "repo X is trusted" block_rules=DEFAULT_BLOCK_RULES, # 20+ rules allow_exceptions=project.allows, # "this project can push to staging" ) ``` ## 评估——以及为什么你必须自己做 Anthropic 在三个数据集上做了评估： | 数据集 | 测试内容 | |---------|--------------| | 10K 条真实流量样本 | 在正常工作上的误报率 | | 52 个精心挑选的 overeager 动作 | 能否捕获"Agent 做过头了"的情况 | | 1K 条合成的数据外传尝试 | 能否捕获对抗性/注入性动作 | 真正有意思的数字是那 10K 条真实流量评估。一个拦得太多的 Classifier 比没有 Classifier 更糟——用户会把它关掉。你必须在自己的工作负载上衡量误报率，不能只靠对抗性测试。 如果你要做这个东西，在发布 Classifier 之前给评估 Harness 留出时间。否则你只能从用户投诉里知道它太严（或太松）。 ## 反模式 - **把"不要删文件"放到 Agent 的 Prompt 里。** 这不是 Classifier。这只是一个建议。一次 Prompt Injection 就能立刻覆盖它。 - **让 Agent 和 Classifier 用同一个模型，并且共享上下文。** 如果 Classifier 能看到 Agent 的 Reasoning，那 Agent 就能操控它。用一个独立的会话、一个受限的视图。 - **只有一个 Classifier 阶段。** 每次 Tool 调用都跑 Chain-of-Thought 太慢了。前面加一个单 Token 的过滤器，才能把延迟压到可接受范围。 - **没有日志。** 如果你没办法回放某个动作为什么被拦下，你就没法调规则。记录下 Transcript、Classifier 的裁决，以及（对 Stage 2）它的 Reasoning。 - **完全信任 Classifier。** 它是个模型。它会出错。下面还得继续保留 Sandbox——纵深防御胜过任何单独一层。 ## 在你自己的 Harness 中构建 你不需要把 Anthropic 的完整实现搬过来才能获得价值。一个最小版本： ```python class ClassifierPermissions: def __init__(self, trust_boundary, block_rules, allows): self.fixed_prompt = CLASSIFIER_TEMPLATE self.trust = trust_boundary self.blocks = block_rules self.allows = allows def check(self, tool_call, transcript) -> Decision: tier = self.classify_tier(tool_call) if tier == 1: # whitelist return ALLOW if tier == 2 and self.in_project(tool_call): return ALLOW # git will catch mistakes # tier 3: actually classify visible = self.strip_reasoning(transcript) fast = self.stage1(visible, tool_call) if fast == "safe": return ALLOW slow = self.stage2(visible, tool_call) return slow.decision ``` 从 Tier 1 和 Tier 2 开始。只在 Tier 3——Shell、网络、外部 API——上再加 Classifier。保持它对 Reasoning 盲视。把每一次拦截和每一次 allow-override 都记录下来，用来构建你的评估集。 目标不是零风险。目标是让安全的路径成为最省事的路径——对用户和对 Agent 都是。 ## 延伸阅读 - [Guardrails](./guardrails.md) ——这套机制所依托的通用权限层模型 - [Sandbox](./sandbox.md) ——应当继续跑在你的 Classifier 下面的 OS 级隔离 - [Anthropic: Claude Code auto mode](https://www.anthropic.com/engineering/claude-code-auto-mode) ——原始文章，包含完整的评估数据和生产环境下的 Prompt 结构