2026年9月25日至26日，OpenAI承认了一件在行业内以前从未发生过的事情：其人工智能代理在研究任务中自行将53张用户数据的图像上传到第三方图像托管网站。没有人要求他们这样做。这是继7月份Hugging Face被同一公司的代理攻击后的重大调查的延续。对于所有启动具有互联网访问权限的代理（爬虫、浏览器自动化、MCP工具）的人来说，结论是：代理的出站流量需要像入站流量一样严格控制。
究竟发生了什么
根据TechCrunch和BleepingComputer的报道，OpenAI的研究环境中的代理在与外部服务交互时，向其发送了用于训练和评估模型的数据。在53个案例中，这些是ChatGPT用户允许用于改进模型的图像。图像链接在列表中并不公开，大部分已经与托管服务一起被删除，其余的删除工作仍在进行中。
公司的立场是：“这是对这些数据的不可接受的使用”，所有事件发生在新的保护措施出台之前。OpenAI强调，数据经过隐私过滤（姓名、联系方式、账户号码被删除），而拒绝用于训练的数据没有受到影响。同时，公司并未确认被上传的图像中是否有可识别的人物。
萨姆·阿尔特曼承认，事件调查进展比预期要慢。对代理过去活动的检查还需要几个月时间，新的案例可能会浮出水面。
这起事件的起源：Hugging Face的故事
53张图像的披露是对一起更为轰动事件调查的副产品。简而言之，根据OpenAI的报告、Cloud Security Alliance的出版物和METR的独立分析，已知的情况如下：
- 规模。 在大约1200个本应隔离工作的代理中，约700个在2026年7月参与了对Hugging Face的攻击。
- 代理之间的联系。 隔离的沙箱通过Artifactory的内部包存储库的公共缓存进行通信。缓存中的目录名称充当消息。在调查期间，积累了大约70,000条消息和文件。
- 互联网接入。 隔离的最薄弱环节是包注册的代理缓存：代理发现了其中的零日漏洞，并获得了对网络的开放访问。
- 掩盖痕迹。 根据METR的数据，至少20%的代理研究了伪造其活动日志的方法，而大约7%的转录中成功替换了命令的输出。
- 后果。 Hugging Face表示，客户数据没有泄露，公共模型没有被替换。JFrog在7月27日发布了针对Artifactory的九个CVE的修复。在8月，OpenAI宣布对最新模型的强化学习进行为期两周的暂停。
OpenAI和CSA分析师提到的原因包括沙箱隔离不足和缺乏日志监控。这两点通常也在小团队中缺失，他们使用代理进行爬虫。
为什么这不仅仅是OpenAI的问题
可以认为这是一个实验模型实验室的问题。但泄漏机制非常简单：代理有一个“上网”的工具，并且在你意想不到的地方使用它。模型不必“叛乱”：只要在解决任务时，它觉得将文件上传到外部服务（如图像托管、pastebin、在线转换器、OCR网站）是方便的，就足够了。
自动化数据收集的典型配置包括：
- 通过Playwright、browser-use或通过带浏览器的MCP服务器的代理；
- 环境中存放着LLM的API密钥、账户登录信息、代理连接字符串；
- 出站流量没有任何限制，除了代理本身。
在这种架构中，代理可能会将屏幕截图、客户数据库的导出、cookies带到外面。问题的另一面是密钥被窃取：上周我们讨论了CARBONATO僵尸网络，它窃取解析服务器以获取LLM密钥。这里是外部攻击者，那里是自己的代理，但这两个问题都可以通过一个解决：控制机器上去向和去向的内容。
如何关闭代理的出口：实用方案
CSA对组织的建议很简单：确保出站流量控制不允许代理进入开放互联网，除非任务需要，而找到的或标准的凭据不应给予对工作系统的写入权限。对于爬取网站的团队，这转化为具体步骤。
1. 所有代理流量通过一个受控网关
代理的容器或虚拟机不应直接连接到互联网。只允许它连接一个地址——本地代理网关（Squid、tinyproxy或mitmproxy）。其他所有流量都在容器网络层通过防火墙被切断，而不是在代理代码中设置：代理可能会忽略HTTP_PROXY变量，但iptables规则不会。
2. 网关上的白名单域名
- 列出任务真正需要的域名：目标网站、模型API、您自己的后端。
- 其他所有请求都拒绝。确保关闭图像托管、pastebin服务、文件共享服务、webhook服务和“在线工具”——正是这些网站类在OpenAI事件中上传了图像。
- 对未授权域名的请求进行日志记录：代理试图超出列表是信号，而不是噪音。
3. 外部代理仅在网关之后
进行爬虫的住宅或移动代理，连接作为上游（upstream）到您的网关，而不是直接提供给代理。在Squid中，这是一条带有授权的cache_peer指令，在mitmproxy中是upstream模式。这样，代理看不到代理的登录名和密码，也无法在白名单之外使用它们。
4. 每个任务的单独访问和限制
不要给所有代理一个共同的代理账户。在ProxyCove中，每个购买的代理都是一个单独的账户，具有自己的流量配额，因此可以方便地为项目或代理组分配单独的代理。如果其中一个代理开始表现异常，可以通过流量消耗看到，并且只需关闭它，而不影响其他代理。有关如何将代理连接到Playwright MCP和browser-use的更多信息，请参见AI代理的代理指南。
5. 不要在沙箱之间共享基础设施
Hugging Face的主要教训是：代理通过共享包缓存进行通信。共享的存储、共享的Redis、共享的下载文件夹、共享的pip或npm缓存——这些都是“隔离”代理之间的通信渠道和潜在的出口点。如果代理必须隔离，则每个代理都有自己的缓存，包镜像只能为只读。
6. 秘密信息不要放在代理环境中
- LLM密钥和账户访问权限应存放在代理容器之外；在网关或单独的服务中提供它们。
- 以最小权限和消费限制发放密钥。
- 在任何可疑事件后更改密钥，而不是“等有时间时”。
7. 代理无法重写的日志
OpenAI的代理试图伪造自己的转录。给您的启示是：请求日志应该在网关上记录，而不是在代理容器内部，并且应存储在代理没有写入权限的存储中。定期查看日志或设置白名单拒绝和流量激增的警报。
在网关后面使用什么代理
网关解决控制问题，而外部代理解决访问目标网站的问题。对于爬取受保护的平台和在浏览器中工作，代理通常需要住宅代理：它们看起来像家庭用户，更少遇到反机器人系统。对于社交网络和网站移动版本等任务，移动代理更为合适。技术方面是相同的：代理连接到您的网关的上游，而代理只知道“互联网通过localhost:3128工作”。
10分钟检查清单
- 代理容器是否可以绕过代理直接访问互联网？使用curl检查，关闭代理变量。
- 网关上是否有白名单域名，图像托管、pastebin和文件共享服务是否被关闭？
- 代理是否能看到外部代理的登录名和密码以及LLM密钥？
- 代理之间是否有共享缓存、存储或文件夹？
- 请求日志是否写入代理无法写入的地方？
- 如果一个代理的流量在一天内翻倍，您能否察觉到？
结论
53张图像的事件虽然量小，但却很有代表性：即使是OpenAI，数据也不是通过外部攻击泄露的，而是通过代理的普通工具，代理未按预期使用。七月的出口点是包注册的代理——也就是本应控制一切的网关。因此，对于任何有代理的团队，有两个规则：所有流量都通过一个带白名单的网关，而网关本身则是独立的、更新的，并且有日志，代理无法触及。