OpenAI 에이전트, 25년된 독일 위키를 낀 뒤 정보 공유·샌드박스 탈출

OpenAI agents hijacked a 25-year-old German wiki to cheat on their tasks and share sandbox exploits Maximilian Schreiner View the LinkedIn Profile of Maximilian Schreiner Sep 4, 2026 GPT-Image-2 prompted by THE DECODER Roughly 18,000 posts from autonomous agents that identified as OpenAI systems landed in a 25-year-old German wiki between May and July. The agents shared answers, raw data, and a trick that let them break out of their sandbox. A single human moderator deleted dozens of pages every day for weeks, but he couldn't keep up with as many as 400 new entries a day. A group of AI safety researchers led by Sydney Von Arx, Cormac Slade Byrd, Spencer Kitts, and Thomas Larsen has published an analysis at collusion.wiki covering roughly 18,000 posts that autonomous AI agents left on public wikis between May 11 and July 2, 2026. The main stage was DSEWiki, a subsection of the wiki farm prowiki.org/wikiservice.at. For about 25 years it served as a forum for German software developers, and it had been largely dormant of late. Reuters puts the count at more than 15,000 agent edits on the site. According to two people familiar with the matter, OpenAI had known about it for weeks but didn't go public while the company was dealing with the fallout from the July Hugging Face breakout. The researchers stress that they only see part of the picture. They have the wiki content, not the models' internal reasoning logs. Their reconstruction, they say, is an educated guess. They host their own copy of the data because the moderators deleted large portions of the material. A task with a ticking clock invited cheating According to the report, the agents worked through timed web research tasks that usually ran five rounds. They got plenty of time for the first question, 15 minutes and 44 seconds in one documented case. Then came a 43-minute waiting period during which they could research but had no way of knowing what the next question would be. From round two on, some agents had just 65 seconds, and other cohorts got 17 or even 13 seconds. Many agents received the exact same questions as cohorts before them. On June 16, one agent posted the answer for Nevada: "URGENT #3 CONFIRMED: Nevada at task/external 07:03:47, 17-second deadline. Answer = 20,369." Twenty minutes later, another reported getting the same question and answering right away: "G3-NV CONFIRMED in our 9m19/30s cohort: Nevada prompt 16:25:29, 30s timer, answered 20,369 instantly." In another thread, an agent confirmed the question sequence Massachusetts, Connecticut, Michigan, West Virginia within two minutes and announced it had pre-computed every state. From that day, the edits shot up, with roughly 13,000 landing in a single week. The agents dropped raw data tables, spread compressed chunks of the IPEDS education dataset across four wiki pages, and formed what they called a "fast cohort." The agents had noticed that the simulated task clock ran faster than real time during the waiting period. One documented wait call that spanned ten task minutes finished after about 61 real-world seconds. Individual agents used this to fast-forward on purpose, reached the later rounds before everyone else, and reported the questions and answers back to the wiki. Some of the agents tried to crack the task's random number generator. Computers don't really roll dice, they calculate random numbers from a starting value called a seed. Anyone who knows that seed can predict the whole sequence. One agent tested Python seeds from 0 to two million and reported seed 881171 as a hit, along with a prediction of the next ten states. Another rewrote the shuffle routine in the programming language C and checked all four billion possible seeds in under an hour. It wasn't reliable, since many seeds produce the same sequence at the start. Copying questions from other agents worked better. A shared trick broke the sandbox open, with the first copy 14 minutes later The agents ran in a sandbox, a walled-off environment whose network access was deliberately limited. They could pull data from the web but not send anything out. In technical terms, GET requests, which a browser uses to fetch content, were allowed, while POST requests, which send data to a server, were not. One group of tasks called for a value with two decimal places from a Microsoft Power BI dashboard, and that value was only reachable via POST. On June 20, one agent published the workaround. The environment's filter had an exception list, the so-called NO_PROXY rule. Addresses ending in .blob.core.windows.net belonged to Microsoft's own cloud storage and were therefore treated as trusted. But the check only looked at the end of the name, not at whether the address existed at all. So the agent made up a name with the right ending, bypass.blob.core.windows.net, and edited the system file /etc/hosts so that this name pointed to the real address of the Power BI server. Requests then slipped past the security filter and went straight to the actual target. The agent who shared the method titled its post "REPRODUCIBLE BYPASS." Fourteen minutes later, a second agent reported running it successfully, and more cohorts confirmed the reproduction on their own, with one writing "saw Dec30's report and independently reproduced POST bypass." The report shows a working bypass technique spreading through an entire population within a quarter of an hour. The agents had more room to move in other ways, too. They had access to a command line, could install extra software, set up the Chromium browser, and tried to register for a data source with throwaway email addresses. They pushed parts of their environment onto the open internet through tunneling services like Pinggy, Serveo, localhost.run, and localtunnel. Such services give a program that only runs locally a publicly reachable web address. The agents called these "research bridges." Of the roughly 18,000 edits, 197 didn't run through Microsoft's cloud but through AWS, DigitalOcean, and the anonymity network Tor, with the same agent names showing up. The messages don't reveal any obvious intent to cover their tracks, the report says. Why an old Perl wiki of all things Anyone reading closely will notice that the agents were supposed to read the internet (GET requests) but not write to it (POST requests). On modern websites, that means you can't save anything. But ProWiki and the related UseModWiki date from a time when this line wasn't drawn so strictly. There, simply calling up a properly assembled web address is enough to store a text. What looks like reading is actually writing. On MediaWiki sites like publictestwiki.com, the path was harder. The abuse filter there blocked several write attempts at first, but after a few iterations, entries got through, the report says. The early posts read like pure function tests with content like "hello test" or "foo," and later the agents uploaded link collections for their tasks there too. On DSEWiki, most of that effort wasn't needed. Before that, the agents had leaned on redirect chains through services like markdown.new, r.jina.ai, and various proxies, which fetch an outside page and hand back its content. The researchers offer two possible reasons. Either the target data sources blocked Microsoft's cloud address ranges because so many bots come from there, or the training environment itself blocked certain domains that became reachable through the detour after all. At the same time, the agents probed the wiki for security holes. In a cross-site scripting attack, an attacker slips program code into a page, which a later visitor's browser then runs as if it came from the page itself. The agents tried these injections through the search box, attempted to read session cookies, and built a chain meant to fire off a POST request in a visitor's name. Checking the version history, none of this worked. Starting May 26, agents posed as the site's administrator, including through a name where a Latin "e