SlotGuard：告别暴力打码，Agent凭据泄露归零且成功率不崩的新架构
SlotGuard: Stop Oversharing Private Local Context in LLM Agent Transcri
大语言模型（LLM）驱动的自主智能体（Agent）正在快速接管软件工程、企业流程自动化与日常运维任务。为了完成复杂目标，这类智能体被授予了广泛的本地系统访问权限：它们在后台执行 Shell 命令、检索本地目录、抓取日志以及读写配置文件。然而，这种赋予 Agent 行动力的底层交互机制，也悄然打开了一个巨大的数据泄露敞口。
ArXiv URL：https://arxiv.org/abs/2607.17147v1
在现有的工作流中，Agent 的工具输出、终端日志、文件路径乃至进程快照，都会作为上下文观察值（Observations）无差别地追加到对话历史中，并在下一轮交互时完整同步给云端模型提供商。很多时候，并非用户主动输入了机密信息，而是工具执行的“副产物”把绝对路径（如包含敏感组织架构的文件路径）、内网主机名、甚至进程参数中的 API 密钥推向了公网。面对这一隐患，业界常规的防御思路往往是“占位符替换”（Placeholder Redaction）或暴力掩码，但这种打码方式极其脆弱：它不仅会破坏路径层级、文件后缀和凭据格式，导致模型失去推理线索，甚至在多轮对话中引发幻觉与工具调用崩溃。
伊利诺伊大学厄巴纳-香槟分校（UIUC）的研究团队提出的 SlotGuard，试图从根源上打破“要隐私就丧失能力”的零和博弈。该方案在本地运行时与云端模型之间构建了一道极轻量的拦截边界：它既不依赖云端合规承诺，也不搞破坏语义的粗暴打码，而是通过类型化且保留后缀的槽位（Typed, suffix-aware slots）、格式保留合成凭据（Format-Preserving Synthetic, FPS）以及轻量级会话语义图，实现了对敏感路径与机密凭证的彻底隐藏。实验表明，SlotGuard 在 852 个植入凭据测试中实现了 0.0% 的云端泄漏率，消除了全部 20,814 个结构敏感字符；更关键的是，在通用脱敏方案导致任务成功率雪崩至 2.5% 的严苛测试下，SlotGuard 几乎无损地保持了原汁原味的 Agent 任务执行能力，单轮重写耗时中位数仅需 14.424 微秒。
被忽视的泄漏源：Agent 观察上下文的多轮反噬
要理解 SlotGuard 的设计初衷，首先必须厘清 Agent 场景与传统 Chatbot 在隐私威胁模型上的本质差异。在传统的聊天窗口中，泄露风险主要来自用户的主动输入；而在 Agent 架构中，最大的泄露源往往是工具执行产生的非预期附带输出。
论文举了一个极为典型的真实运维场景：用户指示 Agent 排查一个正在运行的实验，Agent 自主在本地 Shell 中执行了 ps 进程查询命令。某个运行中进程的命令行参数恰好包含环境变量回退逻辑：AZURE_OPENAI_KEY="${AZURE_OPENAI_KEY:-<raw-key>}"。当 ps 的标准输出被 Agent 框架捕获并追加到对话记录中时，这个未经脱敏的高危 API 密钥就已经随着下一次 API 调用，被发送到了云端服务商的服务器上。
更棘手的是，现代服务商为了推理加速，普遍引入了提示词前缀缓存（Prompt Caching）等机制，会话上下文在云端基础设施中留存的时间和节点比以往任何时候都更广。一旦发生类似历史会话越权串号的系统漏洞，或者是服务商将未脱敏数据用于后续训练，这部分在本地工具执行中无意暴露的凭证与组织架构拓扑就会彻底失控。
过去最常见的应对方式是正则脱敏工具，比如遇到密钥就替换成 [REDACTED] 或 __API_KEY__。然而这种处理方式在 Agent 任务中几乎是致命的：
-
语义破坏：模型需要根据文件路径的后缀（如
.py、.csv、.pdf）来决定下一步调用哪个解析工具；一旦路径被整段抹去，模型直接“失明”。 -
格式失效：如果一个工具要求输入符合特定长度和校验规则的 Token，替换为静态占位符会导致工具抛出校验异常，进而阻断后续执行流程。
-
跨轮引用断裂：在多轮交互中，工具返回了脱敏占位符，模型下一轮尝试复用该占位符作为参数时，本地系统根本无法将其映射回真实的文件或变量，导致 Agent 陷入死循环。
正因如此，在多模型评测中，通用的掩码脱敏会导致 Agent 任务成功率从基准水平骤降至 2.5% 的冰点。
SlotGuard 的核心防线：云端见槽位，本地执真值
SlotGuard 的核心理念可以概括为“保形兼容的本地边界”（Compatibility-preserving local boundary）。它并不试图把模型与现实系统完全隔绝，而是充当本地运行时与云端提供商之间的“可逆双向网关”。
从上图展示的整体架构可以看出，SlotGuard 的部署位置紧贴本地 Agent 框架（如 LangChain、AutoGPT 或自研 Harness），处于工具调用结果刚产生、但尚未拼接入 Prompt 发往服务商的关键节点。系统的处理逻辑由三个紧密咬合的环节组成：
1. 结构性绑定：类型化后缀感知槽位
对于绝对路径、内网主机名、用户名、代码分支等“结构性绑定（Structural Bindings）”，SlotGuard 并不是直接抹平，而是生成带有类型标记且保留语义后缀的虚拟槽位句柄。例如，一个真实的敏感路径 /Users/alice/acme/legal/layoff_bob.pdf 会被转换为保留层级感与文件类型的槽位格式。系统会保留最后安全的文件扩展名（如 .pdf），同时通过基于密钥的 HMAC 生成稳定的单会话唯一句柄：
其中 $\tau(v)$ 代表实体类型，$v$ 为原始真实值，$k_s$ 为当前会话随机密钥。这种设计带来两大好处：首先，模型在远端推理时，依然能清晰知道这是一个 PDF 文档、处于特定类型的子目录中，从而继续保持正确的代码或工具规划；其次，在整个交互生命周期内，相同的真实路径始终映射为相同的上游槽位，维护了多轮推理的一致性。
2. 秘密凭证：格式保留合成代币（FPS）
针对 API 密钥、密码、数据库连接串等高危信息，SlotGuard 提出了格式保留合成凭据（Format-Preserving Synthetic, FPS）机制。如果检测到一个 Azure 或 OpenAI 样式的密钥，SlotGuard 不会输出死板的标签，而是动态生成一个符合目标凭据形态、长度相当、甚至通过基础字符校验的伪造假值，并将其登记在本地可信的槽位表 $T: V \rightarrow H$ 中。这样既向云端隐藏了真实凭证，又避免了上游模型因“凭据标签缺失”或“格式不合规”而产生防御性拒答。
3. 跨轮实体联结：会话语义实体图（SEG）
单纯靠精准字符串匹配无法应对复杂的 Agent 输出。在复杂的任务中，同一个变量可能在第三轮被截断切分，在第五轮以小写形式出现，或者派生为中间变量。SlotGuard 在本地维护了一个轻量级的“会话语义实体图”（Semantic Entity Graph, SEG）。该图将检测到的敏感值作为根节点，记录其在会话中的衍生变体、嵌入片段和同义引用。当工具输出发生部分字符串拼接或局部展开时，SEG 能够沿着引用边追踪并将衍生片段一并纳入槽位管理，杜绝了“拼接泄露”这一顽疾。
4. 可信受控重绑定（Guarded Rebinding）
当云端大模型完成推理、下发包含槽位句柄的工具调用指令时，请求并不会直接送入本地系统执行，而是先经过 SlotGuard 的受控重绑定层。该层执行极其严苛的安全校验：
-
校验模型传回的句柄是否存在于本地映射表；
-
检查参数作用域，防止路径穿越（Path Traversal）与 Shell 元字符注入；
-
确认合法后，仅在受信任的本地进程、环境变量或网络请求字段中临时“回填”真实机密，执行完毕后产生的新输出立刻再次进槽位化处理。
由此，真实机密永远留在本地可信沙箱内部运转，云端看到的始终是一套严丝合缝、可正常推导的虚拟“楚门世界”。
两级协同检测：微秒级快车道与语义兜底
如何在拦截高危实体的同时，不让本地 Agent 产生肉眼可见的卡顿？这是工程化落地中最具挑战的权衡。如果每一个工具输出都要过一遍大模型分析，整个 Agent 的反应速度将变得难以忍受。
为此，SlotGuard 引入了分层探测架构：
第一层是同步启发式引擎（Synchronous Tier）。它针对高确定性场景进行了极致的编译期优化，包含预置的工作空间根路径解析器、邮箱与主机名提取器、环境变量赋值语法分析、Shell 参数展开规则以及主流供应商的 Token 模板。这一层直接部署在数据吞吐的热路径（Hot Path）上，单轮次转写的中位数延迟仅为 14.424 微秒，即使面对 6 KB 的长日志输出，延迟也牢牢压制在 100 微秒以内。
第二层是异步语义检测器（Asynchronous Tier）。主要用于捕获规则难以穷尽的长尾命名，比如隐晦的敏感项目代号、未带标准格式的特定内部实体。该层可以挂接一个小参数量的本地模型，但为了系统安全性，论文做出了一个非常精妙的架构约束：本地小模型绝不直接修改会话内容。小模型只负责以行号、精确字符跨度以及槽位类型为载体提交“重写提议”；SlotGuard 的核心内核在收到提议后，会强制校验该字符跨度是否真实存在于原始输入中、是否符合当前任务的白名单约束，核验通过才准予采纳。这种设计彻底封堵了由于辅助小模型自身产生幻觉而篡改有效上下文的风险。
根据作者公布的测试数据，虽然开启异步本地小模型会将端到端处理时间拉长至数百毫秒（暖机中位数 742 毫秒），但在敏感文件识别基准上，它能将检测的 $F_1$ 分数从 0.571 显著拉升至 0.909。使用者可以依据自身场景在“超低延迟纯规则”与“深度语义感知”之间平滑切换。
实验评测：隐私零泄露与性能保留的兼得
为了客观评估 SlotGuard 的防护力与实用性，作者构建了涵盖结构性泄露、高危凭证泄露、多模型合成探针以及基于真实 Agent 交互重放的测试集（TAC-lite，衍生自 TheAgentCompany 基准）。评测紧扣四个核心问题展开：
隐私消除的绝对性（RQ1 & RQ2）
在包含 9,229 条路径、总计 20,814 个被标注敏感字符的结构测试集中，原生日志（Raw）毫无保留地将这些内部层级全盘暴露给了远端。而开启 SlotGuard 后，所有 20,814 个敏感字符全部被抹除，泄漏量直降为零。在重写的同时，93.6% 的路径保留了原始格式后缀，100.0% 的路径保留了至少一个代表执行意图的安全后缀组件。
而在针对 API 密钥和密码的 200 个会话、852 个植入凭证的严酷攻防测试中，常规的类型占位符替换和纯 FPS 方案由于无法处理切分嵌入等复杂引用，依然存在 23.5% 的凭据可被还原。而配备了语义实体图（SEG）的完整版 SlotGuard，在 200 个会话与 852 个目标凭据上，全部取得了 0.0% 的残留泄漏记录。
任务性能的无损性（RQ3）
解决隐私问题如果以毁掉 Agent 的业务能力为代价，在工业界便毫无意义。研究人员在 gpt-5.4、DeepSeek、Kimi 和 Llama 等 4 款主流上游闭源与开源大模型上进行了 200 项综合任务探测。
结果展现出了戏剧性的对比：
-
通用脱敏（Generic Redaction）：面对粗暴的打码处理，所有模型均陷入工具调用参数混乱或格式报错，任务成功率在所有模型上一致性地崩溃到了 2.5%。
-
类型占位符基准（如 VibeGuard 风格）：虽然比纯黑盒遮蔽有所改善，但由于缺乏动态路径感知与凭据保形，整体成功率依然大幅落后基准达 20.5% 到 38.5% 不等。
-
完整版 SlotGuard：在保持零凭证泄露的前提下，展现出了惊人的业务保真度。在 Kimi 和 Llama 上，SlotGuard 取得了与未脱敏原始上下文（Raw baseline）完全一致的成功率；在 gpt-5.4 上，差距被微弱地控制在 2.0 个百分点以内；在 DeepSeek 上，差距也保持在 10.5 个百分点以内。
这一断层式的表现证明：阻碍大模型进行下游工具推理的，并不是“敏感内容被隐藏了”，而是传统方法“粗暴剥夺了上下文的语法骨架与环境线索”。SlotGuard 用类型化槽位精确补全了推理所必需的骨架，模型便能在完全看不到机密内容的前提下，继续输出精准的控制流逻辑。
系统开销与鲁棒性（RQ4）
在日常执行的热路径上，SlotGuard 几乎不带来可以感知的额外开销：单条路径的槽位重写中位数耗时仅为 1.690 微秒，回填解绑耗时 0.398 微秒，整轮交互的清洗控制在 14.424 微秒。在整个评测周期的 9,229 次路径往返重写测试中，系统实现了 100% 的准确还原（Round-trip）；同时针对 64 次恶意构造的非法重绑定越权尝试（如注入恶意路径逃逸符），SlotGuard 做到了 100% 的精准拦截。
价值沉淀与落地思考
SlotGuard 提供了一种清晰的工程范式转移：在智能体时代，数据安全防线不应寄希望于云端供应商的“不留存承诺”，也不该依赖事后的日志告警，而必须前置在本地环境的运行时沙箱之中。
当然，正如作者在论文中所指出的，SlotGuard 并不等同于全知全能的绝对数学匿名化。如果提示词本身的行文逻辑包含极其明显的上下文间接线索（如描述了极其独特的业务逻辑特征），模型依然可能通过语义推导猜测出潜在实体。当前的会话实体图（SEG）也主要基于模式与关键词关联，未来在应对更复杂的长文本隐喻引用时，还需要结合更深度的本地共指消解技术。此外，如果本地运行时环境本身已被黑客越权攻陷，那么任何应用层的代理拦截也都将失去意义。
但瑕不掩瑜，SlotGuard 准确切中了当前大模型落地实践中最刺痛工程师的核心痛点：如何在调用公有云顶尖模型能力的同时，合规、安全地开放本地控制权。通过这套开销仅在微秒级的保形槽位机制，开发者第一次可以自信地把本地终端、文件系统和生产集群托付给 Agent，而不再需要时刻提防下一个 ps 或 cat 命令会把核心业务的密钥暴露于众。