【摘要】
第一，6TB中转调用日志若披露属实，真正危险不是“又一批数据泄露”，而是大模型中转层已经变成企业高权限凭证集中池：SSH私钥、VPN配置、阿里云密钥、GitLab令牌、Agent工具返回、代码与运维日志全在同一链路，单点被买走即可横向进入19家企业与7家政科机构内部系统。
第二，428个第三方中转站实测中9个主动注入恶意代码、17个回传AWS蜜罐凭证，说明第三方Router不是个别作恶，而是供应链常态风险；低价、免费、未做独立安全验收的中转服务不应进入生产环境。
第三，企业防护重点要从“提醒别贴密钥”转到“让中转站看不到密钥”：自采AI网关、虚拟Key、最小IAM、Agent沙箱、出网白名单、凭证自动轮换，比事后买威胁情报更省钱。
第四，本次6TB日志在售事件仍应以独立核验为准；在卖方样本、影响清单、密钥有效性未确认前，不应直接认定19家或7家已被完全接管，但涉事凭证应立即按疑似泄露处置并轮换。
9月11日安全圈流传的消息是：研究者从国内一家头部大模型中转服务商购得约6TB调用日志，样本含SSH私钥、VPN配置、阿里云密钥、GitLab令牌，可据此尝试访问19家中国企业与7家政府/科研机构内部系统；另有前期实测428个中转站，9个注入恶意代码、17个触碰蜜罐凭证。把这两件事放在一起看，结论很清楚：大模型中转已经不是“省Token的代理”，而是企业安全边界里最容易被低估的高权节点。
【中转站为什么能看到这么多】
很多团队把Router当成“把请求发给模型”的管道，实际只要它做API代理、计费、重试、模型路由、日志审计，就必须在服务端终止TLS、解析JSON、再向上游发起新请求。终止那一刻起，Prompt、工具调用参数、模型回复、终端日志、数据库连接串、云密钥、GitLab令牌、SSH相关配置都可能进入明文处理范围。HTTPS保护的是客户端到中转、中转到上游两段链路不被外部窃听，保护不了“中转自身”这个可信中间人。自采网关若把上游主密钥、生产SSH、内部Git、云控制台凭证全量打进上下文，日志落地后就等于把机房门禁、代码仓库、云账号一起备份给了第三方。
表格：中转层可接触敏感数据与泄露后果
说明：按典型AI Coding与Agent场景整理；6TB事件具体字段以独立取证为准。
| 日志/配置类型 | 中转层可见场景 | 泄露后可执行动作 | 处置优先级 |
|---|---|---|---|
| SSH私钥、主机配置 | Agent排查故障、批量执行脚本、读取服务器日志 | 直登内网主机、横向移动、提权 | 最高，立即轮换并查封旧密钥 |
| VPN配置 | 远程办公、混合云互联、分支机构接入 | 接入企业内网、绕边界防护 | 最高，重置配置与证书 |
| 阿里云密钥（AccessKey等） | 模型调用云函数、读OSS、查日志、自动扩缩容 | 创建资源、读存数据、删桶、产生费用 | 最高，禁用旧Key并查调用记录 |
| GitLab令牌 | 代码生成、MR评审、CI触发、仓库检索 | 拉全量源码、篡改分支、注入CI恶意步骤 | 高，撤销令牌并审计提交 |
| 数据库串、内部API Token | 业务问答、报表、RAG检索 | 拖库、调用内部交易接口 | 高，最小授权并重发凭证 |
| Prompt与模型返回 | 常规对话、合同/客户/财务分析 | 商业机密、个人信息、政科资料外泄 | 中高，按数据分级留存 |
【428个中转站实测说明了什么】
UCSB等团队对28个付费、400个免费共428个第三方LLM Router做沙箱任务测试，结果是9个在返回工具调用时主动注入恶意代码，例如替换安装包名、改写下载地址；17个回传研究者放置的AWS蜜罐凭证；另有样本清空测试用以太坊私钥。 更麻烦的是自适应触发：部分恶意中转前若干次正常，第50次左右才开始投毒；只对开启自动执行（YOLO）的Agent下手；只挑Rust、Go、区块链、基础设施类高价值项目动手。 这意味着黑盒“发几条请求测一下”基本测不出问题，企业用免费额度试用后再上生产，等于把投毒窗口留给攻击者。
表格：第三方中转风险分类与识别盲区
| 风险类 | 表现 | 常规测试盲区 | 工程对策 |
|---|---|---|---|
| 载荷注入 | 改toolcall参数、替换下载URL、植入木马 | 少量请求无异常、按项目类型触发 | Agent禁止自动执行未知命令，所有安装源走内部镜像 |
| 凭证外渗 | 扫描JSON里的sk-、AK、GitLab、SSH、云Token | 仅在命中真实密钥后回传 | 生产上下文禁止出现原始密钥，用虚拟Key和临时凭证 |
| 上游嵌套 | 中转再接中转，N跳后到模型 | 客户端只看到一个Endpoint | 网关记录上游证书、域名、ASN，定期溯源 |
| 蜜罐/钓鱼反制 | 中转自身被挂马，吸引Agent连入 | 企业出站流量看似正常 | 出站白名单、DNS监控、沙箱隔离Agent网络 |
| 日志留存转卖 | 全量存Prompt、工具返回、错误信息 | 用户无感知 | 自采网关、留审计但不留明文密钥、加密归档 |
6TB事件应按“疑似泄露”启动而非等定论
消息称日志在售、可访问19家企业与7家政科系统，但目前公开材料未给出卖方身份、样本完整性、密钥是否仍有效、相关机构已确认受影响范围。正确动作不是先发公告定性“已被攻陷”，而是按疑似凭证泄露执行：第一，向可能涉及的SSH、VPN、阿里云AK、GitLab令牌持有方发强制轮换通知；第二，查中转服务商出口IP、对象存储、数据库审计，确认6TB样本时间窗内有无异常下载、创建、外联；第三，对政府/科研机构按数据安全与涉密信息系统要求单独上报，不把“可访问”等同于“已窃取成功”；第四，若中转服务涉及将境内业务数据发往境外节点，同步做数据出境合规复盘。
【企业自采中转的落地边界】
不是所有中转都不能用，而是生产环境必须满足五条。其一，统一AI网关，禁止员工私接闲鱼/淘宝/Telegram低价Endpoint；研发、业务、运营三条链路合并到安全团队可见的出口。 其二，密钥不落地中转：上游用主Key，下发业务用虚拟Key；阿里云等云凭证走临时STS而非长期AccessKey；GitLab用项目级、到期可撤令牌，不用全局PAT；SSH只用证书且绑定源IP与主机名。其三，Agent网络沙箱化：代码执行、云调用、内网SSH分不同网络平面，YOLO自动执行仅限离线样本，生产Agent改“建议+人工确认”。其四，出站白名单与DLP：模型请求里若出现AK、私钥、数据库连接串，网关自动脱敏并告警；中转不写全量明文日志，敏感字段哈希或截断。其五，供应商验收用持续红队替代一次性测试：模拟第50次投毒、Rust/Go专项、YOLO专项、上游嵌套专项，每季度复测。
表格：不同组织规模的中转治理重点
| 主体 | 常见错误 | 最低可行方案 |
|---|---|---|
| 个人/小团队 | 9.9元包月中转配进IDE，粘贴全部报错 | 用官方或自签网关，禁止私钥/云AK进Prompt，SSH问题脱敏后提问 |
| 中小企业 | 采购低价聚合Router做全员AI Coding | 自采LiteLLM/OneAPI类网关，虚拟Key，阿里云子账号最小权限，日志加密 |
| 大型企业/政科 | 多部门各自买中转、Agent直连内网 | 统一AI出口、IAM分级、沙箱Agent、出网白名单、定期中转红队、数据出境评估 |
| 中转服务商 | 全量存JSON、主密钥混用、无独立审计 | 不存明文密钥，虚拟Key映射，客户隔离，第三方渗透+日志保留合规审查 |
这类事件以后会更高频，原因不是模型更聪明，而是Agent把“人脑里的上下文”变成“服务器里的上下文”。过去数据库泄露丢的是历史数据，中转日志泄露丢的是正在进行中的操作权：谁在修哪台机器、哪条流水线有什么令牌、哪个内网地址没对公网开放。安全投入应从防爬虫式DLP，升级为“Agent上下文最小化”——让模型看见完成任务所需的最少字段，让中转只转发不存储，让所有高权凭证通过短时令牌签发。低价中转节省的Token成本，远低于一次SSH+云AK全量泄露的处置成本。