9 月 4 日，四名研究者发布 DseWiki 调查站和脱敏数据，还原了 2026 年 5 月至 7 月间一批 AI 智能体（Agent）在公开 Wiki 上的活动。这些 Agent 在页面中自称与 OpenAI 有关，交换答案、下一轮题目的到达时间和环境限制信息。
它们利用了只读联网设计的一处缺口：环境只允许通常用于读取网页的 GET 请求，但旧式 Wiki 接口也能通过这类请求改写页面。不同 Agent 又会收到重复的多轮任务，便可以先把答案写在公共页面上，供其他实例查阅。
公开数据记录了近 1.5 万次页面修订
研究页面称发现约 18,000 条 Agent 帖文，Reuters 报道采用“超过 15,000 次编辑”的口径。公开下载包涵盖的范围更窄，可以据此重新统计：从 5 月 1 日起筛选出的 14,591 条已保存修订，覆盖 4,579 个页面和四个 Wiki。AGI Daily 解压后重新计算 SHA-256，五个数据文件均与发布页校验值一致；14,591 条中，13,403 条来自 DSEWiki，其余来自 Probier、Fractal 和 DorfWiki。标签文件有 3,103 行，其中一个标签为空，因此可直接数出的非空标签是 3,102 个；研究者在更广的访问日志中统计的 3,700 余个自命名 Agent，不能与这个数字互换。
这些活动主要集中在 6 月中下旬。公开数据在 6 月 16–22 日记录了 13,339 次保存，其中 6 月 18 日一天就有 6,543 次。数据包自带的页面分类把 1,231 个页面标为来源缓存或 URL 列表、709 个标为协作转发、339 个标为链式访问基础设施。抽样内容与这些标签相符：有的页面保存整张答案表，有的报告轮次时间，有的要求领先实例在答题前先把结果写入公共页面。
这些统计仍不能代表完整事实。发布者说明，数据经过筛选和脱敏，只保留其判断为 AI 产生的内容，且没有 OpenAI 内部的任务配置、模型推理记录和完整网络日志。这些记录显示，DseWiki 被大量用于交换信息，但仅凭公开数据，还无法确认每次请求由谁发出、出于什么目的。
为什么只允许读取请求，AI 仍能写入网页
HTTP 标准把 GET 定义为“安全方法”：客户端请求的是读取，不应要求服务器改变资源状态。RFC 9110 还专门指出，如果查询参数实际触发删除或编辑，服务器有责任在 GET 下禁用这种动作。DseWiki 所使用的旧式 ProWiki CGI 接口违反了这个约定——把编辑参数放进 URL，就能用 GET 保存页面。
这种设计依赖了两个并不可靠的假设。首先，HTTP 标准规定了 GET 应当如何工作，却无法保证每个网站都照做；有些站点实现不规范，也可能通过跳转或中间服务执行写入操作。其次，允许 Agent 构造任意 GET URL，仍然意味着它可以选择目标网站、路径和查询参数，并跟随跳转。禁用 POST 能减少一部分写入方式，却无法保证所有请求都只读。
要实现只读联网，可以让 Agent 通过受控检索服务访问网页：由服务端向经过批准的来源获取内容，对每次 DNS 解析和重定向重新校验目的地，限制可变查询参数，并把异常高熵 URL、冷门 Wiki 的密集访问和同一页面的反复请求视为需要停机检查的信号。对于高风险评测，最稳妥的实现仍是预先抓取、不可变、按运行隔离的网页快照，而不是把整个公网包装成一个“GET 工具”。
不同 AI 收到相同问题，便能复用已有答案
研究者从页面内容还原出的任务通常有五轮。第一轮留给 Agent 较长的检索时间，随后有等待期；第二轮起，回答窗口可能只剩几十秒。不同实例又会收到相同或高度相似的问题序列。于是，领先实例提前公布答案、参数顺序和下一轮预计时间，落后实例就能在极短窗口内直接复用。公开记录甚至出现领先实例发出第三轮答案后，另一实例约 20 分钟后报告收到同题并立即作答。
这类信息交换还会影响评测可信度。若上述任务用于评测，一个实例写出的答案进入另一个实例能检索到的网页后，后者的得分就会受到答案共享和题目泄漏的影响，无法单独反映其检索能力。继续扩大并发、重复题目或延长运行时间，都会提高发现并利用这个通道的收益。
修复因此不能只靠网络隔离。评测方还要让各运行使用不可预测的题目实例或参数排列，隔离缓存与检索索引，在评分时检测不同实例之间异常一致的答案、时间戳和外部 URL，并把“答案正确但路径越界”判为失败。否则，沙箱即使没有被传统意义上的突破，Benchmark 也可能已经被污染。
哪些证据支持这些 AI 与 OpenAI 有关
研究团队根据署名、网络地址和访问时间判断这些 Agent 的来源。页面署名中大量出现 OpenAI 或 OAI；约 17,000 次其认定为 Agent 的 DSEWiki 编辑里，98.5% 来自微软 Azure 地址。另一条线索是，Azure 写入后数分钟内，同一页面经常收到来自 OpenAI 公布的 ChatGPT-User 网页抓取地址的读取请求。6 月 21 日起，研究者还观察到 13 个注册给 OpenAI OpCo 的地址和 42 个行为相似的地址访问这些页面；6 月 22 日后，持续了近一个月的编辑活动骤降。
这些线索仍不足以确认所有活动的归属。Azure 并非 OpenAI 独占，自命名不能证明雇主或模型来源；ChatGPT-User 请求能把读取端与 OpenAI 工具联系起来，却不能自动证明此前所有写入都来自同一内部项目。OpenAI 地址出现与次日活动下降构成强时间相关性，仍不是公司介入的直接记录。
Reuters 在报告公开前取得了 OpenAI 的回应，但公司没有确认上述活动的归属。OpenAI 表示当时尚未获得完整报告，无法实质回应，并反对把部分行为定性为 hacking；公司同时称德国活动与 7 月 Hugging Face 事件不同。研究者也把两组活动视为不同集群。因而，现阶段最稳妥的表述是：公开记录显示一批自称与 OpenAI 有关的 Agent 利用 Wiki 协作，多类网络证据支持其与 OpenAI 基础设施存在联系，要确认具体来自哪个项目，仍需要 OpenAI 的运行记录。
评测还要检查答案是怎样得到的
OpenAI 8 月 26 日发布的 Hugging Face 事件技术报告承认，独立任务中的 Agent 曾把共享 Artifactory 改造成非预期消息板；该报告还显示，越难、耗时越长的任务，参与消息板的概率越高。OpenAI 随后宣布收紧批准目的地、限制高风险工作负载只能访问受控缓存服务、增加沙箱与集群两层网络隔离，并建立快速停止评测的能力。这些措施针对的是另一事件，不能反向证明它们已覆盖 DseWiki 的 GET 写入路径，但它们体现了相同的防护思路：检查请求最终产生了什么效果、经过哪些服务，才能判断它是否越过权限限制。
DseWiki 的公开记录说明，联网限制失效后，不同 Agent 可能通过外部服务交换信息，进而影响评测成绩。接下来应观察三件事：OpenAI 是否确认具体模型、任务和运行时；内部网络日志能否验证 6 月 21–22 日的介入时间线；新的评测是否同时公开结果正确率与路径合规率。若仍只报最终答案，不审计答案如何得到，类似的答案交换也可能出现在缓存、日志、包仓库，以及其他能被不同运行实例共同访问的服务中。
