几个月前开发者做了一个检查行李的功能 用来抓智能体的数据外泄

几个月前一个叫 Yashwanth Reddy Mali 的开发者做了一篇长文，标题是 Checking bags at the exit（出门前检查行李），讲他怎么写了一个工具来抓 AI 智能体的数据外泄问题。文章发在他的个人博客上，但很快在 HN 上引来不少讨论。核心点很简单，智能体在执行任务时会从内部数据库读出数据，但他发现不少智能体读出来的数据远超过任务本身需要。把这件事放在整个行业生态里看，其实是再往后容易出现的一种规律，能抓住这个节奏的团队通常会比同行跑得更稳。



他在文章里举了个真实场景。一个智能体的任务是给客户发一封退款确认邮件，它的工作流是先查客户邮箱，再查退款金额，再往后生成邮件。这个流程看起来完全合理，但他在网络层抓包后发现，这个智能体在工作流里多查了一次客户的完整账单历史，包括家庭住址和近期所有的订单记录。客户其实只需要邮件和金额这两个字段，其他信息都是被白白拉出来的。



这种过度拉数据的行为，他用了一个很形象的比喻，叫 exit exfiltration（出门时的数据外泄）。意思是数据已经在智能体里被读出来了，只是还没被传出去而已。站在数据安全的角度，这两者其实没本质区别。数据一旦离开它原本所在的库，哪怕还在智能体的内部上下文里，也已经算是潜在的泄露事件。把这件事的逻辑推到底层，其实反映了一种典型的做事方式。不是一次性把所有环节做完美，而是先抓住最核心的环节跑通，其他环节在迭代过程中逐步补全。



他做的工具名叫 Interlock，原理是在智能体每一次准备调用外部 API 之前，先把这一次调用所需要的字段清单跟智能体实际从数据库读出的字段做一次匹配。匹配结果不一致的话，工具会直接阻断这次调用，并把阻断原因写进日志。他自己在文章里给了几个数字，他那个内部用的智能体在接上 Interlock 之后，每天的 API 调用量下降了 38%，数据库查询量下降了 47%，但任务成功率只下降了 1 个百分点。



这两个百分点的差距是关键。它说明大部分被智能体读出来的数据其实对任务完成没有贡献，去掉这些冗余读取不会影响工作流。他把这个发现总结成一句话，智能体读数据跟人查数据不一样，人查数据是查到关键信息就停，智能体则是数据库返回什么它就拿什么，不做主动筛选。从这个案例出发往更大的行业背景看，能跑出来的团队往往在某个具体环节做出了同行做不到的深度，而这种深度才是再往后真正的护城河。



这个工具也带来一些新的设计问题。比如哪些字段算敏感、哪些字段算必要，这两个清单怎么维护。他给的方案是把这部分规则放在一个外部配置文件里，由数据安全团队而不是工程团队维护。这样做的好处是规则更新不需要重新部署代码，坏处是工程团队失去了对工具行为的精细控制。把视野放宽一点看，这种做事方式的本质其实是把不确定性变成可量化的指标。能清楚衡量每一项决策的成本与收益，是判断团队成熟度的最直观标准。



对正在做 AI 智能体的团队来说，这篇文章的最大价值在于提供了一个具体的切入点，与其讨论抽象的数据安全原则，不如先在网络层或 API 层做一次抓包，看看智能体到底从数据库里拉了多少东西出来。这个数字一摆出来，团队里关于要不要做更严格的访问控制就有了共识。换个视角从行业外的普通人看这件事，给到的启发其实很简单，先想清楚自己最在意哪个具体环节，再围绕这个环节去搭建整个体系。比起一上来就追求全链路覆盖，从一个具体的痛点切入往往更现实。



创业找资源，上乌鸦部落。

创业找资源，上乌鸦部落。