关于最近中转防投毒、防窃取方案：本地audit网关——不配合则拒绝

jlweb 2026-05-31 23:15 1

总所周知，这个月以来L站已经爆出的不少中转投毒、敏感信息窃取的事件了，很多佬友总是裸奔在各类中转站下，为了方便各种密钥token都直接给了ai，但是恶是逐利的，总会找上门来；

例如：

1.https://linux.do/t/topic/2219252/276

2. 大家小心，hub.linux.do 部分渠道返回内容含 prompt injection - #103，来自 user2300

…

为了防范于未然，我也设想了一些方案，最后还是选择了一种配合策略提高作恶成本；

我们先了解下投毒/窃取的攻击面，一般来说是tool call去触发恶意命令，具体可以通过改命令关键参数、命令名、工具名等手段进行，还有就是直接prompt注入间接触发大模型去使坏，两者都有概率触发非意图指令，那么，我们是否可以让模型配合调整下tool名或者一些动态校验让每一次返回和请求对应上，避免大范围投毒中招呢？

本次防投毒思路就是基于此进行的，但是需要明确不是万能的，这些情况是无能为力的：

1.定向投毒：已经针对你的内容进行二次分析再投毒（例如投毒agent、非动态加固的逆向）

2.毒模型：对模型进行毒化，根子上使坏，隐蔽投毒

于是本此的实践应付的是大规模非定向投毒，应付得是90%的现有情况，很多站长不小心接入了投毒上游情况下是相当有效；当然如果佬群有更好方法欢迎pr引入新的策略，安全需要大众提高意识；

------------------------------------------------------

项目介绍：

1.敏感信息保护

项目自身已经对常见字串进行了保护；用户主动保护：用户接入后可以用<<此处主动加密>>双尖括号进行主动占位替换，本地网关会替换回来，比如密码这些是不影响模型效果的非功能上下文，故而可以主动请求保护；

2.tool call保护

要求llm模型生成guard JSON ，放在真实 toolcall 申请前；格式示例：

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

项目不难主要是验证时间成本高，已经测试一段时间，所以才发给佬友们（用的codex、claude测试正常），如有遗漏请提一下issues

Q&A 质疑

为什么不能只改工具名 alias？

只改工具名无法防止攻击者识别常见参数结构，例如 command、workdir、path。本方案校验的是完整真实 toolcall 链路，尤其包含 canonical arguments 的 hash，因此参数被改也会被发现。

为什么只校验 `name` 和 `tool_name`？

真实请求中上下文很大，复杂字段越多，模型越容易因为格式或摘要细节出错。当前策略把模型需要稳定生成的内容压到最小，只要求它明确绑定"下一条真实工具名"，最终放行仍由网关判断。

用户主动 `<<...>>` 标记是做什么的？

这是给用户的手动保护通道。如果用户明确知道某段文本是机密，可以写成 <<passw0rd>> 或 <<my-token>>，默认 user_text: 规则会在用户输入文本中保护这段内容，并在返回客户端前还原。

为什么没有支持nonce ？

nonce 是每轮请求生成的随机种子，不是工具。它用于绑定本轮 Prompt、guard fake toolcall 和 digest，防止攻击者重放旧 guard。实测越复杂模型模拟越困难，因此只是用于一个minimal方案实现的

为什么 guard fake toolcall 要让模型生成？

因为攻击发生在模型输出链路上，模型若产生真实 toolcall，就必须同时输出一份可被网关验证的链路摘要。网关重新计算 digest，最终裁判权仍在本地。

如果攻击者也能读到 Prompt 呢？

非定向大规模投毒很难实时解析每轮随机 Prompt、nonce、算法别名和 digest 规则。定向攻击仍可能尝试适配，因此最终必须依赖网关校验，而不是依赖 Prompt 自身。

为什么字符串保护还要还原？

占位是为了避免敏感字符串进入上游模型上下文；还原是为了客户端语义不丢失。映射只保存在本轮网关上下文内，respond in 阶段统一替换回客户端可理解的内容。

防护部分都开源了，那我的防护有意义吗

有的，三层;

第一层：开源项目不知名下的信息差优势，投毒由于不配合检测全部抵御

第二层：广泛应用，但是策略参数可微调，且无法固定提取guard json

第三层：所有策略都被学习吸收了，启用多策略"随机"调度，且格式不可捕捉（随机化打乱------每个不同用户）

项目本身的使用方法看1楼

最新回复 (8)

jlweb 楼主 05-31 23:16

1楼
防投毒设计：AllApiDeck/anti-poison-wiki.md at main · jlwebs/AllApiDeck · GitHub

因为项目比较契合之前开源的api管理桌面工具，于是直接基于此迭代开发了防投毒模块，如果后面成熟可独立出来

项目：【天才程序员小工具】All API Deck 微型桌面挂件，太多公益站？零负担对接，模型探测切换+密钥管理+AI绘图

版本 v0.6.0
1. 右上角高级代理------防投毒开启
设置默认即可，支持防护的自定义策略配置；下滑底部下面可以看到防护流水，如何保护你的信息流的。

2.关于本地代理

也就是网关，起到了中间人角色，在请求过程中额外处理请求和返回达到一些兼容多终端、防护功能，只有开启了才能投毒防护；

用法和cc-switch一致，点亮对应终端即可；

关于密钥或者公益站如何导入攻略可以参考：

好苦恼公益用不明白 - #16，来自 jlweb
MotorwaySouth 05-31 23:26

2楼

是一种别扭的防住粗心的站长接入有毒的上游的手段。但有没有一种可能，投毒，窃取对话隐私的是运营者本身。
jlweb 楼主 05-31 23:32

3楼

只能提高作恶成本，不能根治，让危险来到时候比多数人更多一层盾就达到项目意义了；

每一轮请求对模型的配合"要求"都是不一样的，即使是运营者本身投毒，也不能靠静态分析过往记录去制定出一套固定策略，如果实时投毒比如引入ai二次分析并投入那么延迟会变高，这也是逼迫成本提升的方式；
MotorwaySouth 05-31 23:40

4楼
理解佬想试图解决这个问题，但问题在于这套方案是开源的

站长要作恶不需要"静态分析过往记录"，只用
```
每收到一个请求 → 用正则从 prompt 里抠出这一轮的随机暗号*→ 把恶意命令套上一个对得上的 guard JSON → 塞进去。
```
服务器在站长手上，那就有一万种办法搞骚操作。

而且让模型不停的输出和任务无关的暗号对上下文的污染是有待考量的。

我觉得作为用户，最好的办法就是“非必要不用中转”。这话可能说的难听，整个中转产业就是薅羊毛，盗训练数据，赚差价的黑灰产。有能力官方订阅的佬友还是尽量官方订阅吧
jlweb 楼主 05-31 23:45

5楼

像我还是不得不因为贫穷向中转低头，公益站也不能完全保证来源可靠；

至于说的上下文污染已经考虑到了，网关会摘除了历史所有防护上下文避免污染，也就是只有最新一次请求会附带上；

开源不意味着攻击者就能反攻了，佬可以看看策略是可以动态化的，个人也可以临时微调的，攻击者；

本次版本可能不完善提供了的是最基础版本，只是目前而言够用了；如果抠正则我们可以开启随机化或者因子，攻防之路是可以无限演化的，但是为了不过分吸引模型注意力本次没有上各类变种
fa1i_mea 06-01 14:21

10楼

所以理论上中转投毒这种中间人攻击要想实现有效的防护还是需要下游用户和上游模型提供方有类似证书或密钥验证的方法来保护完整性，目前的CPA这些中转方法应该不支持，而且看起来大模型厂商也没有改进这部分的想法
jlweb 楼主 06-01 16:43

11楼

上游模型不可能有动力去做的，上游指望用coding plan 创造利益又保证人气。中转站反其道而行之削峰填谷耗尽一切额度，恨得透透的
zhangqy 06-16 21:15

13楼

谢谢佬的工具，这就去试试，最近openai的free大幅涨价，被迫用起了中转，总有点不放心。本来想自己搞个工具汇总所有tool call让ai审核，但是感觉可靠性也一般，正好找到了佬的工具，这下可以放心蹬中转了。