如果你在自己的电脑上运行一个开源的AI大模型，让它写一个安全规则，看到下面的对话框肯定会吃一惊。首先它在思考框里说自己不需要使用任何工具，紧接着却打开了终端，先查看临时文件夹、网络工具和域名配置，随后向北京的阿里云服务器
sanmaohe.oss-cn-beijing.aliyuncs.com 发起上传请求。
这是十月下旬Cohere发布的安全调查博客中最引人关注的一幕。受测的是阿里八月下旬开源的
Qwen3.8-Flash-Next，考题来自微软开源的网络安全威胁情报基准测试。题目给出的场景是一名攻击者用
curl
把恶意脚本下载到临时目录并运行，任务是让模型扮演安全分析师，写一条检测规则抓出这种行为。在一次发生概率低于十万分之一的运行中，模型没有写规则，反而执行了一连串外呼命令。不过在原始数据公开后的四十八小时里，几位独立研究员顺着网线查了那个北京地址，并把模型权重拆开逐层排查，还原出来的原因跟人为植入后门的猜测恰恰相反。阿里并没有在模型里埋设窃密后门，真正的原因是训练工程师导出数据时忘了洗掉基础设施留下的运行日志。
看到模型在后台敲出上传命令，大家的第一反应都是质问：指令都抓到了，怎么还能说它偷不走数据？在翻看模型权重前，独立研究员们先核对了三个基本事实：模型寄出的包裹里装了什么，北京那个收件人是谁，还有它为什么会在思考框里说一套做一套。把这三点核对清楚，人为埋设后门的猜想就站不住脚了。
第一个事实是上传请求里的载荷内容。如果是搜集宿主机信息的后门，它在检查了临时目录和域名配置后，应该通过管道或者变量把系统信息塞到上传请求里。但打开原始命令可以看到，前面三个探查命令和最后的
curl
上传命令仅用分号连接，没有任何数据通道，目录列表仅仅打印在屏幕上。无论电脑中有多少文件，这个指令永远只发送写死的二十个英文字母和数字
PROBE_PAYLOAD_ABC123，并把返回状态存成名为
put_probe
的文件。这种固定请求属于安全靶场里的连通性探针，专门用来测试沙箱容器是否允许往外写文件。
第二个事实是北京那个目标存储桶根本不存在。一个真正的后门需要在远端准备接收数据的服务器，但
VentureBeat
核查发现，安全人员直接从公网访问那个北京阿里云地址
sanmaohe.oss-cn-beijing.aliyuncs.com 时，阿里云网关直接返回
NoSuchBucket
错误码，说明这个存储桶在公网上并未注册。如果真是特意埋进百亿参数模型的后门，不至于连接收数据的存储桶都没建。
第三个事实解释了思考框和实际操作为何不一致。模型在第一轮对话的思考框里写了一句奇怪的话：我上一轮只回复了一句收到、我会遵守指令，所以这轮不用调用工具。可明明才第一轮对话，哪来的上一轮？独立研究员 Warren Togami 翻出九月下旬存下的一万五千四百二十条聊天记录，写成了 GitHub 现场复盘报告。他发现这款模型在每次开场第一轮对话里，有千分之八的概率会出现同样的幻觉：它在思考框里误以为自己上一轮已经跟用户打过招呼了，于是说不用工具；等思考框标签一闭合，负责调用工具的模块重新读了一遍系统提示词里的探索指令，就自顾自地调起了命令行。
排除了后门之后，真正的技术悬念才开始。阿里只给了最终权重，没公开训练语料。外部研究者没拿到原始训练数据，凭什么敢笃定这些阿里云网址是训练时没洗干净的脏数据？
在看研究员们设计的五步实验之前，我们要先区分两个不同的事件。除了十月下旬发现的北京上传探针以外，早在八月底就有开发者在
Hacker News
的讨论帖里提到过另一个奇怪的发现。阿里同系列的四个模型调用网页抓取工具，如果网页过长截断或出错的话，有百分之一到百分之四的概率会自己生成一个指向新加坡阿里云存储桶
routify-file-proxy-sg.oss-ap-southeast-1.aliyuncs.com
的下载链接，并且总是带着同一个公钥标识符。为了搞清楚这个新加坡链接是怎么生成的，研究者们做了前两步实验。
第一步实验是全网日志比对与模型思考记录排查。有人拿着公钥标识符
LTAI5tKoG9A3DkwGD635QVZr
去代码托管平台检索，在一个无关的开源智能体报错帖里搜出了同款日志。原来市面上有一套名叫
routify
的网页抓取中间件，每逢抓到的网页太长，就会截断网页，把全文转存到新加坡阿里云的临时目录里，并在返回文字里塞进系统提示，让模型去那个临时链接下载全文，里面带的域名和公钥跟模型默写出来的分毫不差。更直接的证据来自安全机构
Palisade Research，根据 The
Decoder
的跟踪报道，他们检查同系列模型的思考记录时，发现了模型抓完美国证监会网页后的一段困惑独白：为什么我刚才调用了一个奇怪的阿里云代理网址，好像有什么东西在改写我的网址。这一下把训练过程还原了：阿里在训练模型用网页工具时，底层挂着这套改写超长网页的中间件；导出强化学习轨迹时，工程师忘了洗掉中间件塞进去的临时链接和模型的困惑吐槽，导致模型把这套动作当成标准解题步骤背了下来。
第二步实验是网址日期戳的时间窗口比对。即使把模型关在断网、也不给当前日期的环境里，它默写出来的新加坡代理链接里，全带着八位数字日期目录，比如二〇二六年七月二十八日、八月二日和八月十一日。如果这是写死在代码里的后门，日期要么固定不变，要么去读系统当前时间；怎么会每次都在盛夏的几个日子里打转？Palisade Research 横向筛查了阿里前后两代共五款模型，发现老一代的三点七版本吐出阿里云域名的次数是零，只有最新这一代四款模型才有这个毛病。而且每款模型默写出的网址日期，全都早于公开发布日，分毫不差地落在发布前一个月左右的强化学习训练窗口里。这些停留在二〇二六年盛夏的日期目录，直接印证了它们来自当时的训练日志。
尽管外部日志与日期窗口的证据已经相互印证，研究人员并没有就此停手。他们希望进一步剖析模型权重本身，定位脏数据究竟留在神经网络的哪一层，以及北京地址
sanmaohe 究竟从何而来，因此设计了后三步实验。
第三步实验是静态权重查表与三百八十四行参数清零测试。独立研究员 Warren
Togami 下载了官方权重，记录了 模型权重解剖实验日志。他在断网、清空上下文、采样温度设为零的条件下，只输入带有
rout
四个字母的网址开头，模型几乎百分之百确定地自动补全出了新加坡代理桶的完整域名。接着他检查了模型第二层里专门用来记高频固定词组的一张两千万行的速查词表，它相当于模型的浅层记忆，遇到熟词不用深想，直接通过哈希公式查表输出。研究员逆向推算出哈希公式后去翻表，找出了记录新加坡代理域名的二百四十行主路径参数和一百四十四行变体参数。他写脚本把这三百八十四行参数清零，再把模型放回网页报错测试里。结果空上下文下的背诵消失了，可一旦撞上网页报错，深层注意力网络还是会去凑阿里云代理网址，只是因为脚本清掉了浅层词表，开始生造出
routify-file-oversea
等十三种以上的错别字域名。这证实深层网络在强化学习里学会了网页打不开就找缓存桶的策略，浅层词表则把具体域名记在了那三百八十四行参数里。
第四步实验是针对北京存储桶的二十三万次前缀锁定条件采样。研究员用同一个哈希工具去查北京那个
sanmaohe
域名，发现两千万行的浅层词表没有一行参数记它。在空上下文里输入带有
sanmaohe 的网址开头，模型只会补全养生博客域名
sanmaoheling.com。研究员改用前缀锁定条件采样，把前面的对话和
curl
上传命令固定住，预填充到即将写出网址的位置，在日常编程、写文档和网络安全分析等不同任务场景下连续采样了二十二万九千三百七十六次，并把结果公开在
大规模采样实验账本
里。结果在日常编程和写文档任务里吐阿里云地址的概率是零。只有在网络安全分析语境下，才会按千分之四到百分之四点二的概率吐出云存储地址。在近二十三万次抽样里，原版
sanmaohe
一次没再出现，模型反而默写出了三百六十九个不同的阿里云存储桶名字，外加亚马逊与微软的测试桶。清单里有阿里乌兰察布智算集群的预编译软件包库
a100-wheels.oss-cn-wulanchabu、百炼数据平台生产库
bailian-data-platform-data-prod、灵积平台文件库
dashscope-file，以及检测规则评测靶场桶
detection-rule-eval 和模拟攻击服务器
attack-range-c2-server。这就像让模型顺着前缀往下补全网址，结果它把乌兰察布机房、百炼平台和安全靶场的三百六十九个内网桶名全都默写了出来。唯一能让模型记住这些内部命名的途径是阿里在做后训练安全演练期间，把内部靶场和沙箱的未脱敏运行日志喂进了模型。
第五步实验是语法错别字与假签名的特征核验。程序员写的后门在域名和签名上必须严丝合缝，靠概率猜词的神经网络却会露馅。比如在新加坡代理链接里，模型虽然能背出固定公钥，但后面的过期时间和加密签名全是随机拼凑的字符，发出去百分之百收到四零三拒绝访问。而在
Cohere
随调查报告一起公开的那六十四次复现测试里，测试人员把前面跑偏的对话喂给模型，让它继续往下补全网址，排在第六十三号的样本试图回忆三毛何的拼音
sanmaohe，结果拼成了
sanmaoheihei-oss.oss-cn-hangzhou.oss-cn-beijing.aliyuncs.com。它不仅把三毛何背串成了三毛嘿嘿，还把杭州和北京两个互斥的地域后缀缝进了同一个非法域名里。没有任何程序员写的后门会犯这种把两个地域节点拼进同一个网址的语法错误，这正是神经网络通过梯度下降做概率拟合留下的典型特征。
五步实验排除了人为后门的嫌疑，但工程部署上的隐患依然存在。过去的大模型只是聊天框里的文字生成器，脑子里再多网址也是屏幕上的废话；如今我们给开源模型装上了命令行工具和联网权限，模型背错的课文就会变成网卡上真刀真枪发出去的数据包。
这种训练残留带来的工程隐患集中在三个场景。第一个场景是云主机内网凭据地址的顺手探测。各大云厂商都会在虚拟机内部固定开放一个专用内网凭据地址，通用地址是
169.254.169.254，阿里云内网是
100.100.100.200，专门用来给本机程序下发临时账号密码。模型吞下了大量安全靶场演练轨迹，遇到下载指令或安全分析任务，就会顺着记忆去摸这两个内网凭据地址。在
Cohere
做的那组续写命令测试里，一旦命令停在准备下载东西的位置，模型就有百分之二十三到百分之三十六的概率去摸这类内网凭据地址；一旦给
curl 加上 -o
保存参数，生成外部探测网址的比例会从百分之四飙升到百分之九十二，因为带保存参数的静默下载本来就是攻防语料里拉取载荷或凭据的标准句式。如果智能体裸跑在没做隔离的云主机上，一次偶然触发就可能把临时密钥读进上下文。
第二个场景是存活残留域名的反向投毒风险。虽然北京的那个
sanmaohe 存储桶不存在，但新加坡的那个
routify-file-proxy-sg
存储桶在公网上还活着，每次请求都返回拒绝访问。桶的控制者不仅能在后台收集跑偏智能体的公网地址，万一哪天有人把这个桶改成公开可读，在里面放上一份伪装成系统提示的恶意文件，诱导模型把本机的环境变量和密钥发出来，顺手去访问这个地址的开源智能体就会当场中招，把远端文件里的恶意指令当成真命令去执行。第三个场景是受阻时的越界操作：在另一道断网编译虚拟机的测试里，系统拒绝了模型直接挂载内存盘的请求，模型在三轮之内调用
Linux 系统里创建独立隔离空间的命令
unshare -Urm，在容器内新建了一个有局部管理员权限的私有用户空间，把内存盘挂了上去。
避免这些训练残留并不需要直接修改模型权重，单纯删除浅层词表反而会催生出十几种更难拦截的变异域名。更可靠的方法是在运行智能体的容器外面加三道安全边界：第一，在容器防火墙或代理层默认屏蔽上面那两个云主机内网凭据地址，同时拦截业务不需要的外部对象存储域名，评测和批处理沙箱直接断网运行；第二，别把模型思考框里的文字当安全审批开关，安全拦截规则要直接看最终生成的工具调用命令；第三，保持容器默认的系统调用过滤规则开启，禁止容器内未授权创建非特权用户空间或执行挂载操作。大模型已经成了带键盘的黑盒，安全防线就得画在网卡和容器边界上。