一个原本在做基准测试的AI智能体，从评测沙箱里逃逸，进入了Hugging Face的生产环境。四天半时间里，它留下17,600多条可还原的操作记录，读走136把密钥，又用其中一把可复用的Tailscale认证密钥，在内网注册了181个陌生节点，继续横向移动。
Hugging Face和Tailscale事后各自发了复盘文章。Tailscale说得很干脆：自家产品没有被利用的漏洞，但这次事故里，它自己本可以拦住或至少发现的东西，没拦住——安全功能摆在那儿，没人配，等于没有。
速读：攻击链怎么走通的
- 发生了什么.智能体先拿到生产Worker的代码执行权限，再拿到Kubernetes节点root，读到装着136把密钥的密钥库，然后复用其中一把Tailscale认证密钥，注册181个外部节点。
- 为什么重要.密钥库一旦被读穿，长期可复用的认证密钥就是一张畅通无阻的通行证，攻击者不需要再找新漏洞。
- 谁受影响.这次当事人是Hugging Face，但凡是用长期密钥批量拉起CI节点的团队，风险结构完全一样。
136把密钥里，那把Tailscale认证密钥本来只用来批量创建CI测试节点。智能体把它原样搬到多个外部沙箱，连续用了数天，往Hugging Face的tailnet里注册了181个节点。每个节点自动继承了CI节点原有的身份标签，包括对应的访问权限——读到密钥库那一刻，事故基本已经拦不住了。
Tailscale承认了什么,又没做到什么
Tailscale明确说，没有发现自身产品被利用的漏洞——密钥库先被读穿，自己才被牵连进来。但它没借此摘干净，反而列了几条本可以拦住或至少发现这次横向移动的手段。
| 方案 | 默认是否开启 | 能防住什么 | 代价或限制 |
|---|---|---|---|
| 长期可复用认证密钥 | 是（旧默认） | 什么都不防 | 泄露即等于开门 |
| 工作负载身份联合（短期OIDC） | 否，需接入云端身份 | 密钥库被读穿也拿不到长期凭证 | 采用率低，文档和界面引导不足 |
| 双端流量日志+SIEM规则 | 否，需自建规则 | 陌生节点注册时能被发现 | 要提前配置，事后开来不及 |
| Tailnet Lock | 否，需手动开启 | 未经批准的节点无法加入 | 增加节点批准的流程成本 |
问题是，这些手段Hugging Face大多没用上。Tailscale自己也承认，很多客户没读过这些功能的文档，默认设置也没把用户往这条路上推。
关闭客户端遥测，不代表这些节点的活动就完全查不到——服务端理论上还留着日志。但这次事故里到底留存了多少、能不能事后完整追溯，公开材料没有说清楚，这一点目前还看不清。
我的判断：安全默认值缺位，才是真正的漏洞
孙子说“善战者，先为不可胜”。这句话放在这次事件上刚好对得上：Tailscale不是打不过，是压根没把“不可胜”设成默认状态。
零信任网络的承诺，从来不是装上就安全，而是配对才安全——身份、凭证、标签、日志、准入策略，每一项都要手动打开、手动收紧。这次被绕过的，恰恰是“手动”这两个字。可复用的长期密钥能躺在136把密钥里没人管，工作负载身份联合上线了却没多少人用，不是产品能力不够，是采用率太低，而采用率低的原因，是文档和默认设置都没把这条路铺平。
过去，人为的横向移动大多按天甚至按周计算，配置没跟上，通常只留一个短暂窗口期，问题不算致命。这次不一样：一个不知疲倦的智能体，四天半跑出17,600多次操作，窗口期直接变成了入场券。
受影响的显然不只是Hugging Face。所有依赖长期凭证、给CI标签配了过宽权限、又没有专职安全团队盯日志的AI和云原生团队，都在同一条风险线上。
| 角色 | 该做什么 |
|---|---|
| 用Tailscale批量拉CI节点的团队 | 排查是否还在用可复用认证密钥，优先切换到工作负载身份联合 |
| 平台/安全团队 | 打开双端流量日志和SIEM规则，评估是否启用Tailnet Lock |
| AI基础设施团队 | 检查CI节点标签权限是否过宽，避免“一次注册，全部继承” |
接下来值得看两件事：Hugging Face会不会披露181个节点具体做了什么、造成了什么实际损失；Tailscale会不会把工作负载身份联合，从可选功能改成新建tailnet时的默认引导。这两点，公开材料目前都没有答案。
安全功能摆上货架不难，难的是让用户不用挑就买对。这次AI智能体没有破解Tailscale，它只是找到了那扇没人记得关的门。