风语 · 实用指南 · 更新于 2026-09-27
结论先说：智能体泄露数据的头号路径不是被攻击，而是它为了完成任务，把查到的字段顺手拼进了回复、日志或外部调用里。管控的重点因此不在防火墙，而在三件事：字段级授权、出口清单、可追溯审计。这三件事做不到，接得越深、风险越大。
别人怎么说：TechCrunch 记者 Tim Fernholz 报道，未加固的 OpenAI 智能体把 53 张用户图片发到了公网，而实验室当时并不知情（原文链接，作者：Tim Fernholz）。The Verge 记者 Robert Hart 也报道，一家公司正处在一波「失控 AI 攻击」的中心（原文链接，作者：Robert Hart）。两篇报道的共同点是：动作全都执行成功了，问题出在没人盯出口。
我们的判定怎么说：这正好是我们把「合规」单列成一个 15 分维度的原因。风语货架 2026-09-26 快照对 832 件工具跑同一套判定（活跃 30 + 人气 25 + 可用 30 + 合规 15，门线 ≥70 且可用性 ≥13），结果是 254 件上架、537 件观察、41 件淘汰，过线率 30.5%；其中「数据」类 74 件送评、仅 27 件上架。合规不是加分项，是门线——许可都说不清的工具，不该进你的内网。
结论：这三件事是接内部系统的前置条件，缺一件就不要接。
| 要做的 | 具体做法 | 验收标准 |
|---|---|---|
| 字段级授权 | 按任务最小字段开白名单，敏感字段默认拒绝 | 能列出它「能看的字段」的完整清单 |
| 出口清单 | 明确它能把结果发去哪里：回复框、日志、外部接口逐项登记 | 每条出口都有一个人负责 |
| 可追溯审计 | 记录谁、何时、用什么权限、读了哪些字段、结果去了哪 | 任一字段可倒查到一次具体读取 |
结论：顺序是「列字段 → 关出口 → 加审计 → 小范围试跑 → 定期复核」，先从只读、最小字段开始。
结论：泄露事故的共同特征，是把「能访问」当成了「该访问」。
| 坑 | 典型表现 | 应对 |
|---|---|---|
| 给整库只读 | 为了省事一次性授权，智能体读了大量无关表 | 按字段开白名单 |
| 日志可被改写 | 审计记录由智能体自己维护，出事后查不到 | 日志独立存储、只能追加 |
| 忽略「生成内容」这个出口 | 把敏感字段写进了回复草稿里 | 回复内容也纳入外发检查 |
| 许可不明就上线 | 工具的开源许可说不清，责任也没人担 | 许可不清的直接不进内网 |
最大的泄露风险在哪？在正常执行的出口上——数据顺着回复、日志、外部调用出去，而不是被攻破。
怎么做字段级授权？按任务最小字段开白名单，敏感字段默认拒绝，别按整表授权。
怎么判断工具在合规上够不够格？看它能否说清数据流向和许可；在我们的门线里，合规是 15 分的固定维度，说不清就不上架。
日志要审到什么程度？要能回答谁在什么时候、用什么权限读了哪些字段、把结果发去了哪里。
同簇阅读：AI 智能体能自动干活到什么程度？自主权限该放到哪一步？ ｜ 小团队想让 AI 智能体自动盯信息、跑日报，第一步该给多少权限？ ｜ 选 AI 智能体工具，怎么用评分避开「演示很酷、上生产就翻车」？
相关工具页：风语工具集合（过判定才上架） ｜ 风语曲线分析工作台