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

一条调试日志记录了 wrote 4.2MB to /tmp/agent-workspace-abc/contract.pdf 并发送到集中日志存储系统。日志中虽然没有内容，但路径在——而路径本身就是一个信号。六个月后查看日志的事故响应人员看到这条消息，并得知了三件事：该工作线程处理看起来像合同的 PDF，工作线程将其存储在本地磁盘，且存储路径方案是 /tmp/agent-workspace-${session_id}/${original_filename}。日志中的原始文件名可能包含客户或事项标识符。即便磁盘本身已加密，日志表面现在也在泄露关于磁盘表面的元数据。

监管机构询问“客户数据存放在哪里”，而安全团队提供的清单中完全缺失了工作线程池。这种故障模式让其他所有问题都变得至关重要。在 SOC 2 或 HIPAA 清单中遗漏一个表面，这种发现会从技术债工单升级为“停止发版”级别的问题，因为监管机构的下一个问题将是：“你们还漏掉了什么？”那个没有将 Agent 临时目录命名为数据存储的团队，无法给出合理的解释。

必须落地的纪律​

修复方法不在于架构的复杂性 —— 而在于为这一层命名。一个“智能体临时存储”（agent ephemeral storage）层，应具备与任何其他主存储系统相同的数据分类、保留、加密和删除保证。一旦该层被命名并列入清单，其余的控制措施就会自动纳入组织已经为 bucket 和数据库运行的相同操作规范中。

单会话生命周期是核心的承重原语。暂存目录必须在会话开始时创建一个具有高熵（high-entropy）会话范围路径的目录，仅由在该会话中运行的代码写入，并在会话结束时通过验证读取（verification read）进行擦除，而不是简单的“发后即忘”式 rm -rf。验证环节是大多数团队都会忽略的部分 —— 删除调用返回成功并不意味着磁盘已空，尤其是在文件系统错误或清理程序在孤儿进程恢复路径中运行时。AWS 对多租户智能体 AI 的规范性指南对此有明确规定：每个请求都会获得 /tmp/sandbox/tenants/<hash>/<request_id>/，并在请求完成时的 finally 块中销毁，外加一个后台扫描程序来清理在进程崩溃中幸存的陈旧工作区。后台扫描是弥补“我们编写了清理代码”与“磁盘实际上已干净”之间差距的关键。

单租户子目录命名空间化必须像行级过滤器（row-level filters）一样接受审计。数据库中 WHERE tenant_id = ? 的行级过滤器会在代码审查中被检查，通过跨租户探测进行测试，并在运行时监控是否存在。文件系统的等效项 —— /tmp/sandbox/tenants/${tenant_hash}/ —— 值得同样深度的审查，因为缺失租户范围的失败模式是完全相同的：租户 A 读取了租户 B 的数据。Cloudflare 关于 isolate 优于容器的论点就基于此 —— 容器启动速度太慢，导致团队会在不同任务之间复用它们，而复用正是创造跨租户攻击面的根源。如果你正在运行容器，单任务隔离必须由容器启动速度以外的手段来强制执行。

定期的资产发现扫描需要重新训练，以识别符合客户数据特征的文件系统路径，而不仅仅是存储账号级别的资源。大多数数据发现工具运行在云控制平面：它们枚举 bucket、数据库和磁盘，然后对每个进行抽样。智能体暂存表面位于更深的一层 —— 在一个已被归类为“系统”的磁盘内部。扫描需要深入 worker 的文件系统，寻找符合组织标记模式的路径（PDF 文本、转录音频、任何看起来像邮件附件的内容），然后将其作为新条目呈现在清单中。这在操作上可能令人感到不适，因为这意味着安全工具需要拥有对临时 worker 文件系统的读取权限，但这是随着新工具不断加入，保持清单真实性的唯一方法。

组织的认知觉醒​

这种风险面之所以会累积，是因为它掉进了一个极其明显的组织缝隙中。构建智能体的 AI 团队认为他们在编写应用程序代码，而应用程序代码通常不负责自己的数据分类 —— 那是平台的事情。运行 worker 池的平台团队认为他们在提供算力，而算力通常不负责数据分类 —— 那是数据团队的事情。负责分类的数据团队认为他们在对数据库和 bucket 进行编目，他们通常不会深入到应用程序的二进制文件中 —— 那是应用团队的事情。每个团队都有辩护理由称这不是他们的问题。然而，无论如何，磁盘里还是塞满了客户的 PDF。

弥补这一差距的架构认知是：智能体的暂存目录就是一个临时数据仓库 —— 那些还没有为此命名的团队，正在交付一个合规漏洞，其表面积随着每一个写入磁盘的新工具而增长。智能体集成的第一个 PDF 解析器只是一个微小、可控的足迹。Whisper 转录工具紧随其后，足迹稍大一些。浏览器截图工具又增加了一个更大的足迹。到智能体拥有 15 个工具时，磁盘已经成了由每个交付过工具的团队所塑造的客户数据拼贴画，而没有一个唯一的负责人拥有全局视野。

解决方法是在交付下一个工具之前为这一层命名，而不是在下一次监管调查之后。命名迫使清单录入，清单录入迫使保留和加密决策，而这些决策迫使负责 worker 池的团队真正负责其磁盘上的数据。在完成命名之前，worker 的本地卷的受保护程度正如所有人预想的那样 —— 毫无保护。