开源本地Audit网关方案：通过动态校验防范AI中转投毒与窃取

背景

近期，Linux DO (LINUX DO) 社区内频繁曝出关于 AI 中转站（Proxy/Router）的安全事件。主要风险包括“中转投毒”和“敏感信息窃取”。许多用户在使用各类中转服务时，往往以“裸奔”状态直接暴露 API Key 和 Token，甚至将密钥直接发送给 AI 模型。由于恶意行为具有逐利性，攻击者利用这些中转节点进行数据截获或指令注入，导致用户面临严重的安全隐患。

此前已发生的具体案例包括：

1. 社区内关于中转站安全漏洞的讨论帖（如 topic/2219252）。
2. hub.linux.do 部分渠道被检测到返回内容包含 prompt injection（提示词注入），由用户 user2300 报告。

面对大规模的非定向投毒和窃取风险，传统的被动防御往往不足。因此，社区开发者提出了一种基于“本地审计网关”的主动防御方案，旨在通过提高攻击者的作恶成本来保障用户安全。

核心内容

该方案的核心思路是构建一个本地运行的审计网关（Audit Gateway），采用“不配合则拒绝”的策略。其基本逻辑是要求大语言模型（LLM）在生成真实的工具调用（Tool Call）之前，先生成一个特定的“守卫 JSON”（Guard JSON）进行自我校验。如果模型无法生成或配合校验，网关将拒绝执行后续操作。

1. 攻击面分析

该方案主要针对以下两种常见的攻击手段：

• Tool Call 触发恶意命令：攻击者通过修改命令的关键参数、命令名或工具名，诱导模型执行非意图的恶意指令。
• Prompt 注入：通过间接的提示词注入，使模型产生非意图的行为。

2. 防御机制：动态校验与配合策略

为了防止大范围投毒中招，该方案引入了动态校验机制：

• 模型配合：要求 LLM 在每次返回请求时，必须生成一个包含特定格式信息的 aad_guard_json。
• 格式示例：

  <aad_guard_json>{"name":"aad_guard_3d8a797cd7_WebSearch","tool_name":"WebSearch"}</aad_guard_json>
  

  此 JSON 需放置在真实的 Tool Call 申请之前。网关会验证此守卫信息与后续的工具调用是否对应，从而避免大范围投毒。

3. 敏感信息保护

• 默认保护：项目自身已对常见敏感字串进行基础保护。
• 主动占位替换：用户可以在接入网关时，使用双尖括号 <<此处主动加密>> 作为占位符。本地网关会在请求发出前替换为加密内容，并在返回结果后还原。这种方法适用于密码等非功能性上下文，且不影响模型的效果。

4. 方案的局限性

开发者明确指出，该方案并非万能，对以下情况无能为力：

• 定向投毒：攻击者针对用户内容进行二次分析后再进行投毒（例如针对特定 Agent 或逆向工程）。
• 模型毒化：模型本身已被毒化，从根源上产生恶意行为，此类隐蔽投毒难以通过网关层检测。

5. 适用范围

该实践主要应对大规模非定向投毒，旨在解决约 90% 的现有常见情况。对于不小心接入了被投毒上游的中转站站长，该方案相当有效。目前已在 Codex 和 Claude 等模型上测试正常。

关键要点

• 本地审计网关：通过本地部署网关，拦截并校验模型输出，实现“不配合则拒绝”的安全策略。
• 守卫 JSON 机制：强制模型在 Tool Call 前生成包含工具名称和唯一标识的 aad_guard_json，用于动态校验请求与返回的一致性。
• 敏感数据主动加密：用户可利用 <<占位符>> 语法主动标记敏感信息，由网关进行透明加解密，防止密钥泄露。
• 防御边界清晰：
  • 有效场景：大规模、非定向的投毒和窃取，特别是针对中转站上游污染的情况。
  • 无效场景：针对特定用户的定向投毒、模型底层被毒化的情况。
• 开源协作：项目鼓励社区通过 PR 引入新的安全策略，共同提高安全意识。

意义与影响

该方案为 AI 应用开发者和个人用户提供了一种低成本、高实效的安全加固思路。在当前的 AI 生态中，中转站的安全问题日益突出，许多用户缺乏足够的安全意识。此方案通过“提高作恶成本”而非完全依赖模型本身的鲁棒性，有效缓解了大规模自动化攻击的风险。

它强调了“纵深防御”的理念：即使上游中转站不可信，通过本地网关的校验和敏感信息处理，仍能保留最后一道防线。这对于促进开源社区的安全意识、推动 AI 工具链的安全标准化具有积极意义。同时，它也提醒开发者，安全是一个持续的过程，需要结合用户主动防护和社区协作来不断完善。