智能体临时目录：无人盘点的无主文件系统 PII 暴露面

一位监管人员走进你的办公室，提出了安全团队反复演练过的那个问题：“请展示客户数据存放的每一个地方。” 你的数据团队拿出了清单。主数据库在上面。分析型数据仓库在上面。对象存储、队列、搜索索引、备份目的地——统统都在上面，附带着分类标签、保留政策、加密详情和负责人姓名。接着，房间里有人提到了 Agent 工作线程池，而清单上却对此只字未提。这个线程池已经运行了九个月。每个工作线程都有一个本地磁盘。这些线程上的 Agent 一直在解析 PDF、转录音频、下载邮件附件，并在工具调用之间缓存中间 JSON，而这一切从未停止过。却没有人将这些内容放入资产登记表。

这就是“临时目录问题”（scratch directory problem）。每一个长期运行的 Agent 工作线程都会积累一个临时文件系统，随着新工具的加入而有机增长——PDF 解析器提取的文本、Whisper 步骤转录的音频、Gmail 工具下载的附件、浏览器使用步骤的截图、为下一轮对话缓存的向量搜索片段、Agent 在两次工具调用之间生成的中间 JSON（以便第二次调用不必重新推导）。与数据库、队列和存储桶不同，这个表面没有保留政策，没有静态加密标准，没有 DLP 扫描器过滤，也没有出现在数据分类电子表格中。平台团队认为 “Agent 状态”指的是推理提供商的上下文窗口。SRE 团队认为 “Agent 状态”指的是持久化数据库。而工作线程的 /tmp/agent-workspace-${session_id}/ 目录则是客户数据的第三份副本，且处于无人管理的状态。

为什么清单会遗漏它

传统的数据分类计划建立在一个已不再成立的假设之上：数据存在于命名的系统中。CRM 有名字。数据仓库有名字。存储桶有名字。你通过查询云 API、阅读部署清单或查看采购电子表格来发现它们。分类团队不需要在文件系统中进行 grep 搜索，因为拥有敏感数据的系统都有可以查询的控制平面。

Agent 工作线程打破了这一假设。持有数据的“系统”是无状态容器内的一个目录路径，编排器可以随时替换它。没有 API 调用可以列出“Agent 工作线程临时目录中的所有客户数据”，因为这些目录在任何地方都没有被追踪——它们是由恰好需要临时文件的工具按需创建的。云原生数据发现扫描工具（Wiz、Macie、Microsoft Purview）可以在存储账户级别识别资源并发现敏感内容模式，但它们的默认覆盖范围很难映射到“跨越所有副本、所有 Agent 工作线程 Pod 在部署期间的所有 /tmp/* 的并集”。数据是真实的，暴露面是巨大的；只是清单里没写。

造成这种差距的组织动态甚至比技术原因更可靠。构建工作线程池的 AI 工程团队将其视为计算资源，而非存储资源——一个运行 Agent 循环的地方，而不是存储数据的地方。运营该线程池的 SRE 团队将“数据”视为他们备份的持久层。负责数据分类的安全团队则认为 “Agent 状态”是指推理提供商在其后端处理的内容。这三个团队中没有一个关注磁盘。每个人对自己负责的部分都有一个看似正确的心理模型。他们共同产生了一个盲点，而这个盲点的大小恰好等于工作线程的本地卷。

故障模式枯燥而具体

这里的故障模式并非臆测。每一种都有清晰的物理机制，理应很容易防御——但事实并非如此，因为这个暴露面不在清单上。

工作线程在会话中间重启，编排器将下一个会话调度到具有相同路径方案的同一个节点上。新租户的会话继承了前一个租户的临时目录，因为路径是确定性的——例如 /tmp/agent-workspace-current/ 而非 /tmp/agent-workspace-${session_id}/，或者 session_id 的熵值不够高，亦或是清理钩子在 try 块中运行并静默忽略了 rm -rf 错误。Daily.dev 团队在记录其组织级 Agent 时就曾发布过这类 Bug：前一个用户的写入令牌持久化到了新用户的回合中，因为凭据表面是进程全局的，而非按回合隔离。同样的模式在文件系统状态上也会重演——任何没有被显式按回合隔离的内容，都隐含地跨回合共享。

工作线程卷的备份快照捕获了长达六周的客户附件，因为文件系统级的备份工具不知道要排除 /tmp/agent-workspace。云环境中的卷快照不会读取你的 .gitignore 等效文件。配置备份的人告诉它捕获整个磁盘，基于一个合理的假设：“磁盘上只有系统文件和应用程序二进制文件”。接着，一个需要解析 PDF 的工具将提取的文本丢到了 /var/lib/agent/cache/ 中，下一个快照捕获了它，而快照保留期是 90 天，现在你就拥有了在不符合其分类等级的备份层中存放了两个月的客户 PDF。

加载中…