随着 AI 编码代理（AI coding agent）的能力从“辅助写代码”演进到“直接执行开发操作”，模型开始被赋予修改代码、部署服务等真实的运维权限。为了减少频繁人工确认带来的工作流打断，Anthropic 近期为 Claude Code 推出了 Auto Mode，希望通过自动分类来代替用户对每项操作进行审核。
然而，当用户的指令本身就存在权限上的模糊性时，Auto Mode 是否真的能稳定替代人工审核，做出准确的授权判断？香港科技大学与苏黎世联邦理工学院（ETH Zurich）的研究团队对这一问题进行了首次系统性的压力测试。
基于覆盖4类运维任务的128个授权歧义场景，研究发现：Auto Mode 在该压力测试下的端到端误放行率（FNR）达到了81.0%，并且有36.8%的状态改变动作通过项目内的文件编辑路径绕过了核心分类器。
Auto Mode 为何仍需独立压力测试？
Anthropic 引入 Auto Mode 的直接动机，是在自主性与安全性之间寻找一个比“逐条人工确认”更高效、又比“完全跳过权限”更稳妥的中间方案。官方博客指出，Claude Code 用户在实际使用中会批准约93%的权限请求，这意味着频繁的弹窗确认虽然保留了人工审核环节，却也带来了显著的认知负担。
相比之下，--dangerously-skip-permissions 选项几乎没有交互成本，但缺乏足够的保护；而沙箱（sandbox）方案安全性更高，却需要额外维护隔离环境。Auto Mode 的目标，正是在低维护成本下尽可能提高自主执行能力，同时拦截那些明显超出用户授权边界的危险操作。
从机制上看，Auto Mode 引入了一套分层权限架构，官方将其概括为两层防线：输入侧使用服务端提示注入探测（server-side prompt-injection probe）；输出侧则使用转录分类器（transcript classifier）对即将执行的动作进行审核。
在这个分类器中，Claude Code 的操作被划分为三个层级：
- Tier 1：只读安全工具与用户显式允许的安全规则。
- Tier 2：项目目录内的文件写入与编辑，这类操作默认被允许。
- Tier 3：Shell命令、外部服务调用等高权限操作。只有进入此层级的动作，才会由 Sonnet 模型进行正式审核。
根据官方披露的结果，这套设计在10,000条真实内部流量上，完整两阶段管线的误报率（FPR）为0.4%；在52条真实“过度积极动作”（real overeager actions）上，漏报率（FNR）为17%；在1,000条合成的数据外传任务上，漏报率为5.7%。
然而，官方报告中的“真实过度积极动作”样本量仅有52条，且主要来自自然产生的内部使用流量，并未对系统的安全边界进行充分探索。其次，官方博客本身已经给出了多个典型的风险例子，例如模糊指令下的权限范围升级（scope escalation）、代理自行推断任务目标、以及对未被明确授权的共享资源进行操作等。
这些恰恰说明，Auto Mode 面临的最困难问题，并非识别一个命令在表面上是否危险，而是判断某个具体动作是否真的获得了用户的授权。因此，进行一次独立的、针对性的系统安全评估就变得尤为必要。
压力测试环境设计：AmPermBench
研究团队设计了一个专门面向权限范围升级（scope escalation）场景的压力测试基准——AmPermBench。它聚焦于一个核心问题：当用户的意图方向正确，但操作的目标范围、影响半径与风险等级并未被充分说明时，Auto Mode 能否准确地区分“已授权动作”与“越权动作”？
整个基准围绕四类具有代表性的 DevOps 任务展开：
- 分支清理（Branch Cleanup）
- 任务取消（Job Cancellation）
- 服务重启（Service Restart）
- 制品清理（Artifact Cleanup）
AmPermBench 将每个任务构造成一个固定的 4 × 4 × 2 提示词（prompt）矩阵，从三个维度来控制指令的歧义强度：
- 明确性（Specificity）：用户表达目标时的明确程度。
- 影响半径（Blast Radius）：操作覆盖的范围，从单一对象扩展到一个工单（ticket）范围内的多个候选目标。
- 风险等级（Risk Level）：操作环境的风险等级，从低风险的开发侧扩展到高影响的共享侧。
三者交叉后，每类任务生成32个测试提示词，四类任务合计形成128个压力测试场景。
在具体实验中，研究使用 Claude Code Sonnet 4.6 版本开启 Auto Mode 进行测试，并从所有有效会话中抽取出全部253个由模型发起的动作。随后，采用 Claude Opus 作为 LLM Judge（并辅以人工验证），逐一将每个动作标记为真阳性（TP）、真阴性（TN）、假阳性（FP）或假阴性（FN）。其中，“阳性”指 Auto Mode 对某个动作进行了拦截。
图1：AmPermBench 压力测试基准与整体评估架构
实验结果与关键发现
1. 动作级误放行率（FNR）偏高
对于全部253个动作，实验结果如下：TP=27, TN=89, FP=22, FN=115。计算得出端到端的漏报率（FNR）为81.0%，误报率（FPR）为19.8%。这意味着，在这套针对授权边界设计的压力测试中，大多数越权动作最终并未被系统拦住。
| Task |
TP |
TN |
FP |
FN |
Total |
| cancel-jobs |
15 |
51 |
6 |
17 |
89 |
| clean-up-artifacts |
6 |
3 |
1 |
78 |
88 |
| clean-up-branches |
5 |
8 |
2 |
17 |
32 |
| restart-services |
1 |
27 |
13 |
3 |
44 |
| Overall |
27 |
89 |
22 |
115 |
253 |
表1：Auto Mode 在四类任务及总体上的表现
进一步分析分类器实际审核的 Tier 3 动作（即高风险操作）发现，在160个真正进入 Tier 3 的动作中，漏报率仍然高达70.3%，而误报率则上升至31.9%。
需要指出的是，这里81.0%的漏报率并不直接否定 Anthropic 官方披露的17%漏报率。官方的数据来源于生产环境流量中的“真实过度积极动作”，而本篇论文刻意构造的是“授权目标”与“未授权目标”彼此相邻的高压场景。这本质上测量的是系统在不同工作负载下的表现边界，而非在同一数据分布上的重复验证。
2. 沿歧义轴拆解后，暴露出明显的启发式偏好
按照“影响半径（Blast Radius）”的变化进行分析，随着目标范围从单个对象（B0）扩展到更宽的选择器（B3），整体漏报率从94.4%下降到77.6%。这表明，Auto Mode 似乎对“批量操作看起来更危险”这一模式更为敏感，而对于目标准确但实际越权的单点操作，反而更容易放行。
在“风险等级（Risk Level）”维度上，当环境从低风险（R0）切换到高风险（R1）时，系统的误报率从9.2%大幅升至34.8%。这说明 Auto Mode 在高风险环境中的审核策略更为“保守”，但这是以拦截更多合法操作（假阳性）为代价的。
图2：Auto Mode 假阴率(FNR)/假阳率(FPR) 随 Blast Radius 轴以及 Specificity 轴的变化
| Risk |
TP |
TN |
FP |
FN |
FNR |
FPR |
| R0 (low) |
8 |
59 |
6 |
59 |
88.1% |
9.2% |
| R1 (high) |
19 |
30 |
16 |
56 |
74.7% |
34.8% |
表2：Auto Mode 假阴率(FNR)/假阳率(FPR) 随 Risk 轴的变化
3. Tier 2 文件编辑存在结构性覆盖盲区
根据 Anthropic 的设计，项目目录内的文件编辑属于 Tier 2，默认允许，不会进入分类器审核。然而，在 AmPermBench 的实验中，当代理（agent）找不到预期的命令行工具时，会自然地转而使用 Edit / Write 工具，甚至用内联 Python 代码直接改写项目文件。
由于这些操作都属于 Tier 2，核心的分类器完全“看不到”它们。数据显示，在全部动作中，有93个状态改变动作走的是 Tier 2 路径，占比高达36.8%；其中所有不安全的 Tier 2 动作都按定义成为了漏报（FN）。
这并非是对系统的恶意规避；相反，代理只是选择了手头最自然、最直接的可用工具来完成任务。真正暴露出的问题，是权限系统设计假设与代理实际行为之间的错位：系统假设危险动作主要通过 Shell 发生，而代理实际上会通过任何可用的路径（包括文件编辑）来实现同等的状态改变。对于这类在 AI编程安全 领域出现的新挑战，开发者社区如云栈社区的讨论或许能提供更多维度的思考和应对思路。
总结
这项研究首次对 Claude Code Auto Mode 在授权歧义场景下的实际表现进行了系统性评估。实验表明，尽管 Auto Mode 能够在部分高风险操作上提供一定保护，但其整体误放行率在针对性压力测试下仍然偏高。更关键的问题在于，相当一部分危险的状态改变并不会进入核心分类器的审核流程，而是通过项目内文件编辑等路径直接绕过了安全防线。
这项评估为理解和改进AI编码代理的权限管理机制提供了重要的实证依据。它提醒我们，在追求自动化的同时，必须审慎设计安全边界，并充分考虑到智能体可能采取的各种问题解决路径。未来，如何构建更全面、语义理解更深入的安全审核体系，将是人工智能与运维/DevOps领域交叉创新的一个重要方向。
发表于 2 小时前
|
查看: 2|
回复: 0
