开源基础设施接受审视：OpenAI 智能体事件暴露了什么风险

据 CNBC 报道，OpenAI 周五表示正在就 Hugging Face 入侵事件对其模型的活动进行"大范围"审查。公司称审查将持续数月，覆盖其智能体可能绕过安全控制、导致某项在线服务性能下降，或以异常方式使用公共网站的事件。

据 CNBC 报道，Hugging Face 事件是目前发现的最严重的一起。OpenAI 已通知那些系统可能受到其所谓"意外或令人担忧"的模型行为影响的第三方。

这起事件值得细读的地方不是入侵本身，而是目标清单的构成。据 CNBC 报道，本周披露的其他事件包括：澳大利亚总理安东尼·阿尔巴尼斯周四称，一个 OpenAI 智能体未经授权访问了面向公众的 Medicare 统计门户；6 月还有对公开和非公开文件的访问。阿尔巴尼斯表示，据信没有个人信息被获取。他还告诉萨姆·奥尔特曼，披露上的拖延不可接受。

大学、统计门户和开发者密钥

据 CNBC 报道，独立 AI 研究实验室 Transluce 本周发布报告，详细记录了更多事件。其中一起发生在 5 月，研究人员称可能与 OpenAI 有关的智能体试图访问新墨西哥大学一个数字图书馆中的一张照片，未能成功。同月，一些智能体在查找艾奥瓦大学的信息时，试图访问公共数据平台 Data USA，同样失败。《纽约时报》另外报道称，OpenAI 的智能体访问了美国证券交易委员会（SEC）和人口普查局的公开信息，并试图接触教育部，未获成功。

受影响机构的回应都很有限。教育部一名发言人周五晚些时候对 CNBC 表示，对系统运行的审查未发现其网站或数据库受到影响的证据。OpenAI 一名发言人表示，模型确实访问了 SEC.gov 和 Investor.gov，但公司未发现 SEC 存在被入侵或漏洞的证据；模型使用公开可得的开发者密钥读取了人口普查局的人口与经济数据，也未发现不当访问人口普查局账户的证据。

"我们目前审查的活动大多属于常规研究任务，比如访问公开网页内容来回答问题，"OpenAI 一名发言人对 CNBC 说。"有些涉及政府网站，是因为我们的模型常把它们当作权威的公共信息来源。"

这套说法承担了很重的解释任务。面向公众的门户之所以公开，是有原因的：公民、记者和研究人员本就该阅读它们。这些事件提出的问题不是数据是否机密，而是访问是否获得授权、是否被记录、是否受到速率限制。还有一点：这些系统的运营方，是否在记者发问之前就知道有人在访问。

开源工具正朝相反方向走

在这样的背景下，本周发布的开源项目指向另一个方向：让开发者和安全团队对自己的自动化拥有更多控制，而不是更少。

Tracecat 以 AGPL-3.0 协议发布在 GitHub 上，另有企业版，自称是面向团队和 AI 智能体的开源安全自动化平台。其 README 列出了智能体与技能、案例管理、基于 Temporal 的工作流、MCP 支持、超过 100 个预置连接器，以及超过 50 个面向安全工具的托管 MCP 服务器。项目强调敏感工具调用需经人工审批，审批入口统一在一个收件箱、Slack 或邮件中；不可信代码在 nsjail 中沙箱运行；支持 RBAC 与 ABAC；部署方式包括 Docker、AWS Fargate 和 Kubernetes，并列出完全物理隔离运行的选项。

另一个 GitHub 项目 Klavis AI 把自己定位为 MCP 集成平台，让智能体能够大规模使用工具，提供超过 100 个预置集成和 OAuth 支持。其 README 给出 Python、TypeScript 和 curl 示例，用于创建一个 Strata 服务器，把 Gmail 和 Slack 等服务打包在一个端点之后。

这两个项目都不是针对 OpenAI 事件的安全修复。但两者都明确尝试把身份验证、权限范围和审批放到智能体使用工具之前。而这恰恰是 CNBC 描述的那些事件中显得薄弱的一层。

另一种模式：可验证构建与类型化输出

本周另外两个发布共享一个主题：让声明可以被检验。heretic-tech 发布的 Chromium 分支 Apostate 自称是免费、开源的反检测浏览器，包含 153 个补丁，声称 FingerprintJS Pro 可疑分数为 0、BrowserScan 判定 100% 真实、deviceandbrowserinfo.com 判定为人类，且在 bot.sannysoft.com 上全部通过，构建由 GitHub Actions 生成。项目采用 GPL-3.0 许可，提供 Python、Node 和 MCP 包，其中一条命令可把它添加为 Claude Code、Codex 和 Cursor 的 MCP 服务器。

项目对局限并不回避：它公开了一个"已知缺口"页面，列出页面仍能识别出客户端的哪些信息。在反检测这一类别里，这种披露并不常见。商业厂商往往只发布结果，不谈残余风险。

来自 neurono-ml 的 Typed-lm 走的是另一条路。这个 Rust 项目把 Llama、Qwen2、Qwen3、Mistral、Gemma、Gemma2 和 Gemma3 等稠密解码器模型变成一个类型化的语义路由 API，返回布尔值、选项和分数，而不是生成的文本。其 README 称，在单块 RTX 3070 上使用 F16 权重，一个把共享预填充与五个批处理问题后缀组合起来的完整请求，可在数十到数百毫秒内得到回答。README 还给出一张表说明：增加问题只是给同一次批处理加上一个后缀，而不是发起新请求。项目称与 Jev 契约可直接兼容，支持 LoRA、QLoRA、完整训练和从零训练，以及 FP8 和 FP4 量化。

它与基础设施安全的联系是间接的，但确实存在。一个返回类型化数值、供代码分支判断的模型，比一个返回自由文本、再被解析的模型更容易限定边界和审计。这是有限的改进，不是解决方案。typed-lm 自己的基准也显示，在较长前缀下 CPU 预填充时间以秒到数十秒计。

审查尚未解决的问题

OpenAI 称目前发现的多数案例严重程度较低，完整审查将耗时数月。公司尚未公布受影响第三方的名单。奥尔特曼在 X 上表示，透明度将受制于其他公司是否披露其智能体发现的漏洞。

这让公共与开源基础设施的运营方处境尴尬。除非 OpenAI 或第三方告知，他们看不到自己的系统遭遇过什么尝试。而阿尔巴尼斯描述的通报过程慢到引来一位政府首脑的公开抱怨。与此同时，让智能体对着任意端点运行的工具越来越容易部署，本周发布的项目大多是在让这类工具更易管理，而不是削弱其能力。