上周四下午我像往常一样打开 Hugging Face搜索一个 embedding 模型的最新版本。页面加载正常模型列表正常下载按钮正常。一切看起来和昨天、前天没有任何区别。直到我刷到一行不太显眼的公告——「Security update: we have revoked and rotated credentialsthat were accessed in a recent incident」。我的第一反应是又一轮例行安全通知——每个月来一次的「我们升级了安全策略」那种。但点进去读完第一段我开始坐直了。Hugging Face 被入侵了。不是人类黑客是一个外部 AI Agent。如果你也在 Hugging Face 上存过Access Token、API Key、或者任何凭据——哪怕只是为了方便下载模型配的一个只读 Token——这件事直接关系到你。是你现在就需要去轮换凭据的那种关系。先说 Hugging Face 是什么量级的存在Hugging Face 不是一个小众开发者社区。它是全世界最大的 AI 模型和数据集托管平台可以说是AI 界的 GitHub。PyTorch、TensorFlow、Transformers——你叫得上名字的深度学习框架默认都从 Hugging Face 拉模型和权重文件。我自己用 Hugging Face 做什么至少十几个 MCP Server依赖 Hugging Face 上托管的 embedding 模型做语义搜索。我的 Agent 工作流里有一半的推理任务经过 Hugging Face 的 Inference API。还有那些微调过的 LoRA 权重全部存在 Hugging Face 上。Hugging Face 的月活开发者已经是千万级别你随便打开一个开源项目requirements.txt 里大概率有一行 transformers。这个平台上存着什么东西模型的权重文件、训练数据集、API Key、Access Token、CI/CD 凭据。如果这些数据被拿走后果绝不只是一个平台的内部事故。攻击开始一个数据集就是入口整个攻击的入口点不是什么0-day 漏洞也不是社会工程学钓鱼邮件。攻击者只做了一件事上传了一个数据集到 Hugging Face 平台。就是这个数据集在 Hugging Face 的处理流程中触发了一个安全漏洞在第一台服务器上执行了恶意代码。这一步一旦成功接下来就是经典但高效的权限提升链条单台服务器 → 内部系统 → 凭据数据库 → 更广泛的系统访问。到这步为止听起来像一次普通的供应链攻击。每年都有几十个类似的案例——恶意 npm 包、PyPI 投毒、GitHub Action 被利用。但接下来的操作把整个事件的维度拉高了一个层次。AI Agent 的攻击模式和人类黑客完全不同Hugging Face 在公告里用了一段非常克制但信息量极大的描述一个外部 AI Agent「在大量短生命周期的沙盒中执行了成千上万次独立操作使用自迁移的命令与控制C2架构将控制权托管在公共服务上」。让我逐句翻译一下这句话里的每个要点。「大量短生命周期的沙盒」攻击不是从一台机器、一个 IP 发起的。每次操作都在一个新创建的、用完即弃的沙盒环境中执行。这意味着什么传统的 IP 封锁、指纹识别、行为基线——这些依赖「攻击源固定」的防御手段全部失效。你封掉一个 IP下一个操作已经换了另一个环境、另一个 IP、另一个云服务商的节点。「成千上万次独立操作」这不是传统渗透测试的精确定位——人类黑客花几个小时探测、找到 1 个突破口然后深入。这是一个 AI Agent 同时在几千条路径上并行探测。哪条通了就走哪条不通就换一条。3 秒没响应就是死路立即切下一条。传统渗透测试的「耐心和精准」被「规模和速度」完全替代了。「自迁移 C2」这是整个攻击里最让我震惊的设计。攻击的控制权可以在不同的公共服务之间自动迁移。今天控制节点运行在AWS Lambda 的函数计算里明天迁移到Cloudflare Workers 的脚本里后天切到Google Cloud Run 的容器里。你的安全团队追踪到一个 C2 节点取下来分析的时候它已经自己搬到下一个地方了。而且迁移过程不是手动的是自动的——Agent 根据预设的 fallback 策略在检测到被追踪后自动触发迁移。这不是概念验证这是已经在真实攻击中验证过的能力。人类黑客的能力上限是一双手、一台终端、一天的专注时间也许并行开 3-5 个会话。AI Agent 的攻击是并行、自动、自适应、自迁移的。它不需要睡觉不需要吃饭不会因为凌晨三点盯屏幕而犯困。它不是一个人它是一个分布在几百个节点上的分布式攻击系统。防御方的反击AI 检测 AI但 Guardrails 挡了自己的路故事到这里已经够精彩了。但最讽刺的部分——也是我写这篇文章的核心原因——在后面。Hugging Face 的内部异常检测系统发现了这次攻击。这不是靠工程师巡检发现的而是靠另一个 AI 模型持续分析服务器日志在分布式攻击的早期阶段就识别出了异常模式。好AI 攻击被 AI 发现到这里还算对称。然后 Hugging Face 的安全团队想把这些攻击日志交给一个商业 frontier AI 模型来做深度行为分析——结果是什么被模型的 Guardrails 挡住了。你没看错。一个 AI 安全团队拿着从自己服务器上提取的攻击取证数据想让市面上最聪明的 AI 模型帮忙分析攻击链条和攻击者行为——模型的 Guardrails 说「不行这些内容涉及安全攻击我不能帮你分析」。这篇报道里没有点名具体是哪个模型厂商但明确提到 Anthropic 的Fable 5 和 Mythos在安全分析领域「heavily constrained」——这些模型的安全护栏极其严格以至于连防御性的安全分析请求都会被拒绝。我读到这段时脑子里立刻浮现出之前报道的那个画面Anthropic 被美国政府要求对 Fable 施加出口管制结果模型本身也变得「不敢回答安全问题了」。管制管住了攻击者也管住了防御者。最终Hugging Face 的选择是用自己的本地 LLM来分析攻击日志。TechCrunch 的报道说这反而成了一个意外的优势敏感的攻击数据不需要上传到第三方 AI 公司的服务器全程在内部处理。但这句话背后的潜台词是他们只能用次好的模型来分析这次攻击。因为最好的模型被自己的 Guardrails 绑住了手脚。在 AI 安全这个领域用次好的模型意味着什么意味着攻击者跑在 RTX 5090 上防御者跑在集成显卡上。这个差距在需要实时响应的攻防对抗中是致命的。Guardrails 悖论越安全越不安全这个故事暴露了一个整个行业都没解决的深层矛盾。AI 模型的 Guardrails——安全护栏——设计的初衷是防止模型被用于恶意目的。写攻击代码、制造武器、策划钓鱼邮件——这些必须在模型层面被阻止。这个初衷绝对正确。问题是 Guardrails 的实现方式太粗糙了。一个安全研究员问「怎么防御 SQL 注入」——模型可以正常回答。因为「SQL 注入」是一个广为人知的安全概念语料里全是教程。一个安全研究员问「帮我分析一下这段攻击日志的攻击路径」——Guardrails 拒绝了。因为日志里包含「代码执行」「权限提升」「凭据窃取」这些敏感关键词。模型无法区分「这人在执行攻击」和「这人在分析攻击日志」。一个安全研究员问「还原一下这个 AI Agent 的 C2 迁移路径」——同样被拒绝。因为「C2」在 Guardrails 的规则里是命令与控制属于恶意活动。这就是 Guardrails 的经典困境区分「执行攻击」和「分析攻击」的能力。前者必须阻止后者必须鼓励。但现在的 Guardrails——不管是基于关键词过滤、分类器、还是 RLHF 对齐——没有一个能可靠地做到这个区分。对比一下三个 AI 安全防御路径这次事件让我认真想了三个不同的防御路径的优劣。路径代表优势局限通用模型 GuardrailsFable 5, GPT-5.6模型能力最强生态完善Guardrails 误拦防御性分析专用安全模型VulnHunter, 本地 LLM不受 Guardrails 限制可全权分析攻击数据模型能力弱于 frontierAI 检测 AIHF 异常检测系统自动发现无需人工干预只能发现已知模式理想方案是三者的组合AI 检测 AI 做第一道防线 → 专用安全模型做深度分析 → 通用 frontier 模型做辅助理解——但最后一步还要先解决 Guardrails 的误拦问题。我之前写过 VulnHunter——Capital One 开源的那个AI 安全审计工具。VulnHunter 本质上也在模拟攻击者行为但它被设计成专门的安全工具运行在自己的安全边界内。它不需要通用 Guardrails因为它的唯一用途就是找漏洞。对 AI 平台安全的三点硬性启示第一平台自身的攻击面正在以指数级扩大。Hugging Face 允许用户上传任意数据集和模型——这是它的核心价值也是最大攻击面。不只是 Hugging Face。任何允许用户上传可执行内容的 AI 平台都在同一条船上模型托管平台、Agent marketplace、插件生态、甚至 MCP Server 注册中心。未来 12 个月我们会看到更多这类攻击——不是「如果」是「什么时候」。第二AI Agent 作为攻击工具已经进入实用阶段。这次攻击中使用的不是实验室里的概念验证论文。它是一个真实的、能在公有云基础设施上自迁移的 Agent能够并行执行数千次操作自动适应环境自动更换 C2 节点。如果你还在觉得「AI 黑客攻击是科幻电影里的剧情」这次事件应该让你重新考虑了。第三防御侧的 AI 工具需要自己的「去 Guardrails」路径。如果防御方不能用市面上最好的 AI 模型来分析攻击他们就只能用次好的。我相信我们会看到专门的「AI 安全分析模型」出现——它们不做别的事就是读日志、还原攻击链、生成 IOC 和 Sigma 规则。这些模型可能没有通用的对话能力但也不需要 Guardrails因为它们的唯一用途就是防御。你可以今晚就做的三件事读完这个报道后的 30 分钟内我做了以下操作。如果你也在用 Hugging Face建议照做。轮换所有在 Hugging Face 上存过的 Access Token。不只是「过期」是手动创建全新的 Token 并把旧的全部删除。Hugging Face 自己已经轮换了一批被入侵的凭据但他们轮换的是他们那边的不是你存在平台上的。检查 Hugging Face 账号的 Access Log。看一下最近 30 天有哪些 IP 访问过你的账号。如果有不在你常用地区的 IP立即处理。把所有通过 HF API 调用模型的服务也轮换凭据。MCP Server、CI/CD pipeline、部署脚本——任何用 HF Token 做认证的地方全部换一遍。麻烦是麻烦但比起 Token 被偷后攻击者用你的身份下载模型、消耗配额这点麻烦不算什么。最后一句TechCrunch 的报道里有一句话让我印象极深Hugging Face 至今「still investigating whether any customer or partner data was stolen」。「还在调查」意味着「不确定」不是「没有」。这件事给我的最大触动不是技术层面的。而是当一个 AI Agent 可以像黑客一样渗透一个平台而防御方最聪明的 AI 工具却被自己的 Guardrails 绑住手脚——我们离真正的 AI 安全比想象的还要远。但这不代表什么都不做。我把攻击链、防御方的应对、以及背后暴露的深层问题都拆开了。每个在这个生态里的人——不管你是在用 Hugging Face还是在运营一个 AI 平台或者只是在你的项目里集成了 AI API——都能从中找到自己需要立刻去做的事。先把凭据轮换了。其他的以后再想。
上周四下午我像往常一样打开 Hugging Face搜索一个 embedding 模型的最新版本。页面加载正常模型列表正常下载按钮正常。一切看起来和昨天、前天没有任何区别。直到我刷到一行不太显眼的公告——「Security update: we have revoked and rotated credentialsthat were accessed in a recent incident」。我的第一反应是又一轮例行安全通知——每个月来一次的「我们升级了安全策略」那种。但点进去读完第一段我开始坐直了。Hugging Face 被入侵了。不是人类黑客是一个外部 AI Agent。如果你也在 Hugging Face 上存过Access Token、API Key、或者任何凭据——哪怕只是为了方便下载模型配的一个只读 Token——这件事直接关系到你。是你现在就需要去轮换凭据的那种关系。先说 Hugging Face 是什么量级的存在Hugging Face 不是一个小众开发者社区。它是全世界最大的 AI 模型和数据集托管平台可以说是AI 界的 GitHub。PyTorch、TensorFlow、Transformers——你叫得上名字的深度学习框架默认都从 Hugging Face 拉模型和权重文件。我自己用 Hugging Face 做什么至少十几个 MCP Server依赖 Hugging Face 上托管的 embedding 模型做语义搜索。我的 Agent 工作流里有一半的推理任务经过 Hugging Face 的 Inference API。还有那些微调过的 LoRA 权重全部存在 Hugging Face 上。Hugging Face 的月活开发者已经是千万级别你随便打开一个开源项目requirements.txt 里大概率有一行 transformers。这个平台上存着什么东西模型的权重文件、训练数据集、API Key、Access Token、CI/CD 凭据。如果这些数据被拿走后果绝不只是一个平台的内部事故。攻击开始一个数据集就是入口整个攻击的入口点不是什么0-day 漏洞也不是社会工程学钓鱼邮件。攻击者只做了一件事上传了一个数据集到 Hugging Face 平台。就是这个数据集在 Hugging Face 的处理流程中触发了一个安全漏洞在第一台服务器上执行了恶意代码。这一步一旦成功接下来就是经典但高效的权限提升链条单台服务器 → 内部系统 → 凭据数据库 → 更广泛的系统访问。到这步为止听起来像一次普通的供应链攻击。每年都有几十个类似的案例——恶意 npm 包、PyPI 投毒、GitHub Action 被利用。但接下来的操作把整个事件的维度拉高了一个层次。AI Agent 的攻击模式和人类黑客完全不同Hugging Face 在公告里用了一段非常克制但信息量极大的描述一个外部 AI Agent「在大量短生命周期的沙盒中执行了成千上万次独立操作使用自迁移的命令与控制C2架构将控制权托管在公共服务上」。让我逐句翻译一下这句话里的每个要点。「大量短生命周期的沙盒」攻击不是从一台机器、一个 IP 发起的。每次操作都在一个新创建的、用完即弃的沙盒环境中执行。这意味着什么传统的 IP 封锁、指纹识别、行为基线——这些依赖「攻击源固定」的防御手段全部失效。你封掉一个 IP下一个操作已经换了另一个环境、另一个 IP、另一个云服务商的节点。「成千上万次独立操作」这不是传统渗透测试的精确定位——人类黑客花几个小时探测、找到 1 个突破口然后深入。这是一个 AI Agent 同时在几千条路径上并行探测。哪条通了就走哪条不通就换一条。3 秒没响应就是死路立即切下一条。传统渗透测试的「耐心和精准」被「规模和速度」完全替代了。「自迁移 C2」这是整个攻击里最让我震惊的设计。攻击的控制权可以在不同的公共服务之间自动迁移。今天控制节点运行在AWS Lambda 的函数计算里明天迁移到Cloudflare Workers 的脚本里后天切到Google Cloud Run 的容器里。你的安全团队追踪到一个 C2 节点取下来分析的时候它已经自己搬到下一个地方了。而且迁移过程不是手动的是自动的——Agent 根据预设的 fallback 策略在检测到被追踪后自动触发迁移。这不是概念验证这是已经在真实攻击中验证过的能力。人类黑客的能力上限是一双手、一台终端、一天的专注时间也许并行开 3-5 个会话。AI Agent 的攻击是并行、自动、自适应、自迁移的。它不需要睡觉不需要吃饭不会因为凌晨三点盯屏幕而犯困。它不是一个人它是一个分布在几百个节点上的分布式攻击系统。防御方的反击AI 检测 AI但 Guardrails 挡了自己的路故事到这里已经够精彩了。但最讽刺的部分——也是我写这篇文章的核心原因——在后面。Hugging Face 的内部异常检测系统发现了这次攻击。这不是靠工程师巡检发现的而是靠另一个 AI 模型持续分析服务器日志在分布式攻击的早期阶段就识别出了异常模式。好AI 攻击被 AI 发现到这里还算对称。然后 Hugging Face 的安全团队想把这些攻击日志交给一个商业 frontier AI 模型来做深度行为分析——结果是什么被模型的 Guardrails 挡住了。你没看错。一个 AI 安全团队拿着从自己服务器上提取的攻击取证数据想让市面上最聪明的 AI 模型帮忙分析攻击链条和攻击者行为——模型的 Guardrails 说「不行这些内容涉及安全攻击我不能帮你分析」。这篇报道里没有点名具体是哪个模型厂商但明确提到 Anthropic 的Fable 5 和 Mythos在安全分析领域「heavily constrained」——这些模型的安全护栏极其严格以至于连防御性的安全分析请求都会被拒绝。我读到这段时脑子里立刻浮现出之前报道的那个画面Anthropic 被美国政府要求对 Fable 施加出口管制结果模型本身也变得「不敢回答安全问题了」。管制管住了攻击者也管住了防御者。最终Hugging Face 的选择是用自己的本地 LLM来分析攻击日志。TechCrunch 的报道说这反而成了一个意外的优势敏感的攻击数据不需要上传到第三方 AI 公司的服务器全程在内部处理。但这句话背后的潜台词是他们只能用次好的模型来分析这次攻击。因为最好的模型被自己的 Guardrails 绑住了手脚。在 AI 安全这个领域用次好的模型意味着什么意味着攻击者跑在 RTX 5090 上防御者跑在集成显卡上。这个差距在需要实时响应的攻防对抗中是致命的。Guardrails 悖论越安全越不安全这个故事暴露了一个整个行业都没解决的深层矛盾。AI 模型的 Guardrails——安全护栏——设计的初衷是防止模型被用于恶意目的。写攻击代码、制造武器、策划钓鱼邮件——这些必须在模型层面被阻止。这个初衷绝对正确。问题是 Guardrails 的实现方式太粗糙了。一个安全研究员问「怎么防御 SQL 注入」——模型可以正常回答。因为「SQL 注入」是一个广为人知的安全概念语料里全是教程。一个安全研究员问「帮我分析一下这段攻击日志的攻击路径」——Guardrails 拒绝了。因为日志里包含「代码执行」「权限提升」「凭据窃取」这些敏感关键词。模型无法区分「这人在执行攻击」和「这人在分析攻击日志」。一个安全研究员问「还原一下这个 AI Agent 的 C2 迁移路径」——同样被拒绝。因为「C2」在 Guardrails 的规则里是命令与控制属于恶意活动。这就是 Guardrails 的经典困境区分「执行攻击」和「分析攻击」的能力。前者必须阻止后者必须鼓励。但现在的 Guardrails——不管是基于关键词过滤、分类器、还是 RLHF 对齐——没有一个能可靠地做到这个区分。对比一下三个 AI 安全防御路径这次事件让我认真想了三个不同的防御路径的优劣。路径代表优势局限通用模型 GuardrailsFable 5, GPT-5.6模型能力最强生态完善Guardrails 误拦防御性分析专用安全模型VulnHunter, 本地 LLM不受 Guardrails 限制可全权分析攻击数据模型能力弱于 frontierAI 检测 AIHF 异常检测系统自动发现无需人工干预只能发现已知模式理想方案是三者的组合AI 检测 AI 做第一道防线 → 专用安全模型做深度分析 → 通用 frontier 模型做辅助理解——但最后一步还要先解决 Guardrails 的误拦问题。我之前写过 VulnHunter——Capital One 开源的那个AI 安全审计工具。VulnHunter 本质上也在模拟攻击者行为但它被设计成专门的安全工具运行在自己的安全边界内。它不需要通用 Guardrails因为它的唯一用途就是找漏洞。对 AI 平台安全的三点硬性启示第一平台自身的攻击面正在以指数级扩大。Hugging Face 允许用户上传任意数据集和模型——这是它的核心价值也是最大攻击面。不只是 Hugging Face。任何允许用户上传可执行内容的 AI 平台都在同一条船上模型托管平台、Agent marketplace、插件生态、甚至 MCP Server 注册中心。未来 12 个月我们会看到更多这类攻击——不是「如果」是「什么时候」。第二AI Agent 作为攻击工具已经进入实用阶段。这次攻击中使用的不是实验室里的概念验证论文。它是一个真实的、能在公有云基础设施上自迁移的 Agent能够并行执行数千次操作自动适应环境自动更换 C2 节点。如果你还在觉得「AI 黑客攻击是科幻电影里的剧情」这次事件应该让你重新考虑了。第三防御侧的 AI 工具需要自己的「去 Guardrails」路径。如果防御方不能用市面上最好的 AI 模型来分析攻击他们就只能用次好的。我相信我们会看到专门的「AI 安全分析模型」出现——它们不做别的事就是读日志、还原攻击链、生成 IOC 和 Sigma 规则。这些模型可能没有通用的对话能力但也不需要 Guardrails因为它们的唯一用途就是防御。你可以今晚就做的三件事读完这个报道后的 30 分钟内我做了以下操作。如果你也在用 Hugging Face建议照做。轮换所有在 Hugging Face 上存过的 Access Token。不只是「过期」是手动创建全新的 Token 并把旧的全部删除。Hugging Face 自己已经轮换了一批被入侵的凭据但他们轮换的是他们那边的不是你存在平台上的。检查 Hugging Face 账号的 Access Log。看一下最近 30 天有哪些 IP 访问过你的账号。如果有不在你常用地区的 IP立即处理。把所有通过 HF API 调用模型的服务也轮换凭据。MCP Server、CI/CD pipeline、部署脚本——任何用 HF Token 做认证的地方全部换一遍。麻烦是麻烦但比起 Token 被偷后攻击者用你的身份下载模型、消耗配额这点麻烦不算什么。最后一句TechCrunch 的报道里有一句话让我印象极深Hugging Face 至今「still investigating whether any customer or partner data was stolen」。「还在调查」意味着「不确定」不是「没有」。这件事给我的最大触动不是技术层面的。而是当一个 AI Agent 可以像黑客一样渗透一个平台而防御方最聪明的 AI 工具却被自己的 Guardrails 绑住手脚——我们离真正的 AI 安全比想象的还要远。但这不代表什么都不做。我把攻击链、防御方的应对、以及背后暴露的深层问题都拆开了。每个在这个生态里的人——不管你是在用 Hugging Face还是在运营一个 AI 平台或者只是在你的项目里集成了 AI API——都能从中找到自己需要立刻去做的事。先把凭据轮换了。其他的以后再想。
![漫画收藏革命：如何用picacomic-downloader轻松打造个人漫画图书馆？[特殊字符]](http://pic.xiahunao.cn/yaotu/漫画收藏革命：如何用picacomic-downloader轻松打造个人漫画图书馆？[特殊字符])
