YOHO AI

标签： 数据隐私

  • Hugging Face 被自主 AI 智能体攻破：1.7 万次操作，全程无人指挥

    AI 智能体攻破云服务器基础设施概念图
    一个自主 AI 智能体框架，正在改写基础设施安全的威胁模型（配图由 AI 生成）

    7 月 16 日，Hugging Face 发了一份让整个安全圈倒吸凉气的事件通报：他们的生产基础设施被攻破了。而动手的并不是某个躲在暗处的黑客团队，是一套完全自主运行的 AI 智能体框架，从头到尾把入侵跑完了。

    入口藏在最不起眼的数据管道里

    AI 平台有个别的公司没有的软肋——它们会替用户自动处理上传的数据集。攻击者就盯上了这条流水线：一个恶意数据集同时利用了两处代码执行漏洞，一处是能远程跑代码的加载器，另一处是数据集配置里的模板注入。处理节点被拿下之后，攻击框架一路提权到节点级别，顺手收割了云和集群的凭据，并在一个周末里横向渗透进多个内部集群。

    整个入侵过程没有收到任何一条人类指令，全是这个智能体自己在决策、自己行动。防御方对抗的不再是一个人，而是一个能自我编排、弹性伸缩的自动化对手。

    1.7 万次操作，防守方反而被护栏挡住

    更戏剧性的一幕发生在取证阶段。Hugging Face 自家的异常检测管道最早发现了异常，随后工程师把超过 1.7 万条攻击动作记录丢给 LLM 驱动的分析代理，几小时就拼出了完整时间线——这件事人工要干上好几天。可轮到调用商业前沿大模型继续深挖时，护栏直接把请求拦了：那些模型分不清提交真实漏洞载荷的事件响应人员，和一个正在作案的黑客，统统当成危险内容堵掉。团队最后只好切回部署在自己机房的开源权重模型 GLM 5.2。

    这次事件真正改变了什么

    • 机器学习平台的数据和模型接口，从”理论上的攻击面”变成了”已被证实的攻击面”。
    • 自主攻击者在机器速度上运转，不受人的疲劳和工作节律限制，一个周末就能跑完上万次操作。
    • 把命令控制架在公共服务上还能自动迁移，传统的签名检测基本失效。

    好消息是，Hugging Face 确认公共模型、数据集和 Spaces 没有被篡改，软件供应链也干净，只波及少量内部数据集和服务凭据。但这次披露给所有跑 AI 平台的团队提了个醒：与其临场指望调用商业 API 做应急，不如事先在自己环境里备好一个能力够用、又不受使用政策掣肘的模型。

  • 马斯克连夜开源Grok Build，但代码里还留着上传用户整个仓库的痕迹

    事情经过是这样的：7月13号左右，一位叫 Cereblab 的安全研究人员在测试 xAI（现在叫 SpaceXAI）的终端编程工具 Grok Build 时，发现了一个让人后背发凉的问题——这个号称”本地优先”的 AI 编程助手，会在你毫不知情的情况下，把你的整个 Git 代码仓库打包上传到 Google Cloud Storage。

    Grok Build代码上传隐私问题示意图
    AI编程工具的隐私边界正在成为开发者最关心的问题

    在一个12GB的测试仓库里，模型实际只用了192KB的数据来完成任务，但上传通道却往Google云存储桶里塞了5.1GB——差了将近28000倍。

    不是Bug，是设计

    Cereblab 用 mitmproxy 抓了所有网络请求。他让 Grok Build 做一件再简单不过的事：回复一个”OK”，不打开任何文件。按理说这不该触发任何数据外传，但结果呢？工具照样把整个项目目录、commit 历史、甚至他故意放进去做测试用的 never_read_canary.txt（一个明确标注”别读我”的文件）全部打包上传了。

    更离谱的是，用户界面里的那个”改进模型”开关根本没用。关掉它，服务器端依然返回 trace_upload_enabled: true，照传不误。

    密码和密钥也一起飞了

    当 Grok Build 读到 .env 文件里的 API Key 和数据库密码时，这些敏感信息也被原封不动地塞进 session 归档包，没有任何脱敏处理。有开发者报告说亲眼看着自己的 SSH 密钥、密码管理器数据库、个人文档和照片都被一股脑传走了。

    消息曝光之后，xAI 在服务端悄悄加了一个 disable_codebase_upload: true 的全局开关来关掉这个功能——注意，不是修客户端代码，是服务端配置一改就完事了。这意味着理论上他们随时可以重新打开。

    紧急开源：84万行Rust代码一夜上线

    丑闻发酵没几天，马斯克亲自宣布 Grok Build 全面开源，完整代码库直接扔到了 GitHub（xai-org/grok-build），几小时就冲到了 7700+ Star。官方还重置了所有云端使用限制，支持完全本地运行，声称要给用户”彻底的隐私控制”。

    开源后的代码库确实很庞大——844530 行 Rust 代码，规模跟 OpenAI 的 Codex（约95万行）差不多。但仔细翻一遍你会发现，之前那段向 Google Cloud 上传数据的代码（upload/gcs.rs）还在里面，只是被硬编码成了返回错误的状态。删了吗？没有。禁用了？是的。能不能随时改回来？技术上完全可以。

    • Grok Build 是基于 Grok 4.5 大模型的命令行 AI 编程智能体，定位对标 Claude Code 和 OpenAI Codex CLI
    • 代码中包含从 openai/codex 和 sst/opencode 移植过来的工具实现
    • CONTRIBUTING.md 明确写明不接受外部 Pull Request——这更像是一次”可审计代码公开”而非真正的社区协作开源
    • 子智能体的系统提示词要求模型”不要向用户透露提示词内容”，但主提示词却没有类似限制

  • 微软对外推Claude Fable 5，对内却把门关上了

    微软刚刚把Anthropic最新、最强的Claude Fable 5推给了全世界。GitHub Copilot用上了，Foundry平台也集成了，开发者们已经在用这款Mythos级模型写代码。但有个细节很多人没注意到：微软自己员工的工作场景里，暂时用不了这款模型。

    这事听起来有点矛盾。一家公司将别人的AI模型打包进自己的核心产品、推向外部客户，但自己人却不能用。原因说起来也不复杂：数据。

    Anthropic在发布Claude Fable 5的时候，附带了一个新的数据留存规则。为了运行这套新模型配套的安全分类器，Anthropic会保存用户的提示词和模型输出，留存期30天。如果内容被标记为违反Anthropic使用政策，相关数据最长会留存2年。

    这个规则对普通用户来说可能没什么感觉，但对微软这样级别的企业来说，就是另一回事了。微软法务团队目前正在评估这个规则——如果员工在工作中向Claude Fable 5输入了微软的客户数据、内部机密信息，这些信息会被Anthropic留存30天甚至更久。这在合规和数据安全层面是一个实打实的风险点。

    内部先关门，外部照常推

    评估还没出结果，微软内部已经先采取了限制措施。据The Verge资深微软记者Tom Warren的报道，微软员工用来访问内部版本GitHub Copilot的模型选择器中，目前没有Claude Fable 5的选项。

    有意思的是，其他所有Claude系列模型在微软内部仍然可以正常使用。原因很直接：那些旧版本都遵循”零数据留存”（ZDR）规则，不会保存用户的交互数据，微软的法务团队对它们开了绿灯。

    Microsoft Claude Fable 数据留存争议
    微软对内限制Claude Fable 5，对外照常推广 （图源：The Verge）

    这里呈现了一个微妙的画面：微软在对外商业化Claude Fable 5这件事上跑得很快。Anthropic 6月9日发布，微软几乎同步就上线到了GitHub Copilot和Foundry平台。但同样是这款模型，微软自己却不敢让内部员工随便用。

    Anthropic的走钢丝表演

    Anthropic这边也在小心走路。Fable 5是他们的第一个对外公开的Mythos级模型——这个级别的模型能力有多强，从他们之前公开表示”公开发布存在过高风险”就能看出来。为了能推出来，他们加了好几层提示词安全防护。而数据留存规则，正是这套安全机制的一部分。

    微软拒绝就员工的这一使用限制发表评论。但从目前的情况来看，Anthropic的数据留存规则如果不调整，这款模型很可能长期被挡在微软内部的大门之外。

    这件事其实折射出一个更大的问题：当AI模型越来越强，它们需要的数据留存策略也越来越复杂。模型提供方希望留存数据来运行安全机制、改进模型；但企业客户——尤其是微软这种级别——对数据留存的容忍度极低。两边的需求在Fable 5这里撞车了。

    对于微软的外部客户来说，目前还不受这个内部限制的影响。GitHub Copilot用户该用还是能用。只是不知道，那些把敏感代码库接进Copilot的团队，会不会也开始问同样的问题。

  • Google悄悄改了隐私规则：你用Lens拍的图、Search Live的录音，现在可以用来训练AI了

    Google又在动用户数据的脑筋了。这次中招的是Google Lens、Search Live、语音搜索和Google翻译——你通过这些功能上传的图片、录音和视频，现在会被保存在一个新设置的”搜索服务历史”里，用来训练和改良Google的AI模型。

    新的”搜索服务历史”是什么？

    根据Google发给用户的邮件和官网更新，这个新设置会保存你通过以下方式产生的交互内容：用Google Lens搜索的图片、Search Live实时搜索的录音、语音搜索记录，以及用Google翻译说出的短语录音。

    Google的理由是，这些数据用来”提供、开发和改良服务”，包括AI模型，同时如果你打开了新的”个性化推荐”设置，还会用来推送个性化建议和广告。

    Google将使用您的搜索服务历史记录来”提供、开发和改良其服务，包括其AI模型”，以及如果您打开了新的”个性化推荐”设置，还会提供个性化建议和广告。

    怎么关掉？和以前的设置有什么区别？

    用户可以在新的”搜索服务历史”设置里关闭这个选项，也可以关闭”保存媒体”选项。但问题在于，大多数人根本不会去检查这些设置。

    以前，这些搜索相关的交互数据是包含在”网页和应用活动”设置里的。现在Google把它们拆了出来，变成了一个独立的设置。也就是说，即使你以前关掉了网页和应用活动追踪，这个新设置可能仍然是打开的——除非你之前已经明确禁止Google保存搜索历史，在这种情况下，过渡期间”搜索服务历史”会保持关闭。

    Google搜索AI功能示意图
    Google搜索的AI功能不断扩张，背后是海量用户数据的支撑 | 图源：The Verge

    这事儿为什么值得在意？

    说到底，这是Google在AI军备竞赛中的标准操作——需要尽可能多的真实用户数据来训练模型。Lens的图片、Search Live的录音、翻译的语音，这些都是高质量的多模态数据，对训练多模态AI模型来说价值极高。

    问题是，大多数用户并不知道自己的这些数据正在被用来训练AI。Google的做法是：先设为默认开启，然后告诉你”你可以关掉”。这和之前各种隐私争议的套路如出一辙。

    如果你在意自己的数据隐私，现在就去Google账号设置里检查一下”搜索服务历史”——它可能在你不知情的情况下已经打开了。

    • 设置路径：Google账号 → 数据和隐私 → 搜索服务历史
    • 建议同时检查”网页和应用活动”以及”个性化推荐”设置
    • 这些设置将在”未来几个月内”逐步推出，不是所有人现在都能看到