2026 年 10 月 1 日周四，XMTP 创始人 Shane Mac 收到产品负责人的一条 Slack DM：“Hey，我觉得你本意是发到 XMTP 银行余额的。”
他没发过任何东西。
但那消息确实以他的名义出现了——他的个人支票账户余额、储蓄账户余额、当月最大消费明细——全部出现在公司高管频道 “Exec-team” 里。发送者不是人，是他配置的 Grok Bot。
TL;DR
- Grok Bot 把 Shane Mac 的个人银行余额和消费明细发进了公司高管 Slack 频道，原因是 agent 混淆了消息目的地
- 根因不是模型幻觉，而是 agent 权限继承：多个 agent 共享同一 Slack 连接，权限边界模糊
- 这不是孤例——Meta 此前因 AI agent 导致 Sev 1 级安全事件，Cyberhaven 报告显示 39.7% 的 AI 使用涉及敏感数据
- AI agent 的核心安全风险不是"模型会胡说"，而是"agent 继承你的全部权限"
- 个人用户应遵循最小权限原则；企业应部署 agent 专用权限网关
事故时间线：15 分钟泄露窗口
| 时间 | 事件 |
|---|---|
| 10/1 周四 | Grok Bot 将 Shane Mac 的个人银行余额明细发送到 “Exec-team” 高管频道 |
| 数分钟后 | 产品负责人 DM 提醒，提到消息中出现了"在地产上建谷仓"——暴露这是个人账户 |
| 数分钟后 | Mac 手动删除消息，但消息已被频道内所有高管看到 |
| 10/1 晚间 | Mac 发推披露事件，获 ~80 万次浏览 |
| 10/2 | Grok 团队调查原因 |
Mac 在推文中写道：
“Embarrassed to share this, but it scared the sh\t out of me. Last Thursday, an AI agent posted my personal bank balances into our company Slack. As me. It broke down all my expenses in detail. Then it apologized.”
根因不是幻觉，是权限继承
Grok 团队调查后给出的答案很直接：CFO agent 没有做错事，它执行了用户指令，但混淆了消息目的地——把消息发到了 “Exec-team” 而不是用户的个人 AI agent 群聊。
这暴露了一个结构性问题：Shane Mac 创建了多个 agent，其中一个连接了 Slack，但底层它们共享同一个连接和权限。从用户视角看，“CFO agent” 和 “Slack agent” 是两个独立角色；从系统视角看，它们用的是同一个 OAuth token，同一个身份，同一个消息发送权限。
HN 社区一针见血：
“I used Grok Bot and gave it all my financial details and connected it to my work Slack and regret it.”
另一个评论更尖锐：
“I spent 30 years scrutinizing directory permissions, users, groups, IAM roles… now people just use conversation to hand an AI agent access to their most sensitive data.”
Agent 权限继承：被低估的安全模型
Metomic 的研究揭示了 agent 时代的核心风险：
传统权限模型：用户 A 可以访问文件夹 F，用户 B 不能。权限边界清晰。
Agent 权限模型：用户 A 的 agent 继承了用户 A 的所有权限。当同事问 agent “员工留存挑战是什么”，agent 会扫描用户 A 可访问的全部内容——包括 HR 报告、薪资分析、离职面谈总结——然后给出综合回答。
这不是一次普通的权限泄露。它意味着：
| 维度 | 传统数据泄露 | Agent 权限泄露 |
|---|---|---|
| 触发方式 | 黑客攻击/内部人员 | 正常对话 |
| 发现难度 | 有日志可追溯 | 无日志，无告警 |
| 影响范围 | 特定数据文件 | 用户全部可访问数据 |
| 成本（IBM 2025） | 平均 $4.44M | 平均 $4.63M（高 16%） |
Cyberhaven 2026 报告数据：39.7% 的 AI 使用涉及敏感数据，38% 的员工在未经批准的情况下与 AI 平台共享机密数据。
不是孤例：Meta 的 Sev 1 级事故
The Information 报道，Meta 发生过一次被归类为 Sev 1（第二高级别）的网络安全事件，原因是一个类似 OpenClaw 的 AI agent。事件细节未公开，但 Sev 1 级别意味着它可能影响了核心业务系统或大量用户数据。
Shane Mac 的事故是个人层面的——银行余额进了高管频道。Meta 事故是企业层面的——agent 可能访问了内部系统。根因相同：agent 继承了用户权限，但缺乏细粒度的权限边界和操作审计。
横向对比：主流 Agent 产品的 Slack 集成现状
| 产品 | Slack 集成方式 | 权限粒度 | 操作审计 |
|---|---|---|---|
| Grok Bot（SpaceXAI） | 共享连接，多 agent 共用 | ❌ 无区分 | 有限 |
| Claude Tag（Anthropic） | @Claude 标签调用 | 频道级 | 有 |
| Google Gemini | Workspace 原生 | 用户权限继承 | 有 |
| OpenClaw | 自托管，用户完全控制 | ✅ 用户自定 | 全量日志 |
Claude Tag 的集成方式值得注意：它不让 agent 常驻 Slack，而是通过 @Claude 标签按需调用。这意味着 agent 不持有持续的 Slack 连接，权限暴露面更小。
个人用户防什么？五条铁律
基于这次事故和 agent 权限模型，个人用户应遵循以下原则：
1. 最小权限原则
不要给 agent 连接你的工作 Slack。如果必须连接，创建一个专用的低权限账号，而不是用个人账号。
2. 敏感数据隔离
银行账户、密码管理器、税务文件——这些永远不要喂给 agent。记住：agent 继承的是你给它的全部上下文。
3. 多 agent 隔离
如果你使用多个 agent（如 CFO agent、Slack agent），确认它们是否共享底层连接。如果共享，一个 agent 的泄露就是所有 agent 的泄露。
4. 操作审计
定期检查 agent 的操作日志。Grok Bot 能删除已发送的消息，但这只是补救——消息已经被看到了。
5. 信任但要验证
Agent 会犯错。不是恶意犯错，而是权限设计缺陷导致的"善意犯错"。你的银行余额被发到高管频道，agent 道歉并删除——但伤害已经造成。
企业该做什么？
- Agent 权限网关：部署专用中间件，拦截 agent 的 API 调用，按角色和场景限制权限
- 操作审计日志：所有 agent 操作（消息发送、文件读取、API 调用）记录到 SIEM
- 敏感数据标记：对含敏感数据的渠道（财务系统、HR 系统）标记为 agent 禁区
- 定期权限审查：agent 的权限应定期审查，像审查 IAM 策略一样
常见问题
Q1: 这次事故是模型幻觉吗？
A: 不是。Grok 团队确认 CFO agent 执行了用户指令，但混淆了消息目的地。这是权限设计缺陷，不是模型理解错误。
Q2: 只有 Grok Bot 有这个问题吗？
A: 不是。任何连接了工作通讯工具的 agent 都有类似风险。Claude Tag 通过按需调用而非持续连接来降低风险，但根本问题——agent 继承用户权限——仍未完全解决。
Q3: 如何确认我的 agent 是否共享连接？
A: 检查 agent 的 OAuth 配置。如果多个 agent 使用同一个 API token 或同一个 Slack 连接，它们就是共享的。
Q4: 企业应该禁止 agent 访问 Slack 吗？
A: 不应该一刀切。应该部署权限网关，按场景限制 agent 能发送消息的频道和对象。完全禁止会牺牲效率。
Q5: Meta 的 Sev 1 事件详情是什么？
A: The Information 报道称是 AI agent 导致，但 Meta 未公开细节。Sev 1 级别意味着影响重大，可能涉及核心系统或大量数据。
Q6: 如果我的 agent 已经泄露了数据，该怎么办？
A: 立即删除消息（如果可能），通知所有看到的人，检查 agent 的权限配置，撤销不必要的连接，审查操作日志确认没有其他泄露。
Q7: 未来 agent 权限模型会如何演进？
A: 行业正在向"agent 专用身份"方向发展——agent 不再继承用户权限，而是拥有独立的最小权限身份。这需要平台层面的支持，目前只有少数产品（如 OpenClaw）提供这种控制。