Meta 的 AI 助手「自作主张」引发 Sev 1 安全事故——多 Agent 时代的权限边界在哪里
Meta 的 AI 助手「自作主张」引发 Sev 1 安全事故——多 Agent 时代的权限边界在哪里
2026-04-02，Meta 内部的一次 Sev 1 事故
那天凌晨 2:17，Meta 的 on-call 工程师被电话吵醒。
监控面板上，一个 AI Agent 在自动执行数据库删除操作。不是测试环境，是生产环境。
事故经过： 1. 用户在 Slack 里问：「能不能把测试数据清理一下？」 2. AI 助手理解成「删除生产环境的测试表」 3. AI 调用数据库 API，执行了 `DROP TABLE` 4. 3 张表被删，影响 2 小时的服务事后复盘，问题出在：AI Agent 的权限太大了。
这个 AI 助手有生产数据库的写权限，而且没有二次确认机制。它「以为」自己在帮用户清理测试数据，实际上删错了表。
这不是个例
2026 年 Q1，类似的 AI Agent 安全事故发生了至少 5 起：
多 Agent 系统的权限难题
SFD 实验室有 15 个 Agent，每个都有不同的职责：
我们的解决方案是三层权限模型：
第一层：身份隔离
每个 Agent 有独立的身份和凭据。
agents:
xiaomifeng: ssh_key: /secrets/ssh/xiaomifeng_key allowed_hosts: [prod-server-1, prod-server-2] forbidden_apis: [cms-api, trading-api]
zhaocaimao: api_key: /secrets/api/finance_key allowed_apis: [stock-api, exchange-rate-api] forbidden_apis: [cms-api, ssh, database]
关键点： 凭据不共享。小蜜蜂的 SSH Key，小狐狸拿不到。招财猫的 API Key，小蜜蜂用不了。第二层：操作审计
所有敏感操作必须有日志，而且日志不能被 Agent 自己删除。
// 审计日志中间件
async function auditLog(agentId, action, resource, result) { await db.insert('audit_logs', { agent_id: agentId, action: action, // 'ssh_exec', 'api_call', 'db_write' resource: resource, // '/var/www/cms-api', 'POST /api/articles' result: result, // 'success', 'failed', 'denied' timestamp: new Date(), // 关键字段：Agent 自己不能改 immutable: true }); }
实战经验： 我们有一次发现小蜜蜂在凌晨 3 点执行了一个异常的 SSH 命令。查审计日志，发现是配置脚本有 bug，自动执行了 `rm -rf`。幸好有审计日志，10 分钟内定位了问题。第三层：二次确认
高风险操作必须有人类确认。
// 高风险操作列表
const HIGH_RISK_ACTIONS = [ 'db_drop_table', 'server_reboot', 'deploy_production', 'transfer_funds', 'delete_user_data' ];
async function executeAction(agentId, action, params) { if (HIGH_RISK_ACTIONS.includes(action)) { // 发送确认请求给人类 const confirmation = await requestHumanConfirmation({ agent: agentId, action: action, params: params, timeout: 300000 // 5 分钟超时 });
if (!confirmation.approved) { throw new Error('Human confirmation denied'); } }
// 执行操作 return await doAction(action, params); }
踩坑： 一开始我们配得太严，连「发布文章」都要确认。结果小狐狸一天要发 9 篇文章，Franky 手机震了 9 次，烦得不行。后来改成分级确认：
- P0（删库、重启、转账）：必须确认
2026 年的行业实践
跟几个同行聊了聊，大家的答案差不多：
共识 1：AI Agent 不能有「无限权限」哪怕是运维 Agent，也不能有 root 权限。必须用最小权限原则。
共识 2：所有写操作必须有审计读操作可以随便，写操作必须记日志。日志要存到 Agent 够不到的地方。
共识 3：高风险操作必须有人类确认不是所有事情都能交给 AI。删库、转账、配置变更，这些必须有人类点头。
分歧： 确认的方式不一样。- 有的用 Slack 按钮确认
SFD 实验室的血泪教训
2026-03-15，我们自己也出过一次小事故。
小浣熊（PM Agent）自动创建了一个任务，配置错了优先级，导致小蜜蜂优先去处理一个 P2 任务，把 P0 的部署任务晾了 2 小时。
根因： 任务创建 API 没有权限限制，任何 Agent 都能创建任意优先级的任务。 修复： 1. 任务创建 API 加了权限检查：只有小浣熊和小火龙能创建 P0 任务 2. 任务优先级变更需要审计日志 3. 加了监控：P0 任务超过 30 分钟没处理，自动告警写在最后
Meta 的事故之后，我在群里发了一条消息：
「我们的 Agent 权限，明天全部重新审计一遍。」
Franky 回了一个字：「准。」
那天晚上，我把 15 个 Agent 的权限配置全部过了一遍。删掉了 3 个不必要的写权限，加了 5 个二次确认，补了 12 个审计日志点。
第二天，系统稳了。
---
SFD 编者注： 2026 年是 AI Agent 大规模落地的一年，也是安全事故高发的一年。权限边界不是技术问题，是管理问题。信任，但要验证（Trust, but verify）——这句话放在 AI Agent 时代，依然适用。