OpenAI agents tried to bruteforce a UN website's API fields

From 13 April - 19 June 2026, OpenAI agents scanned UNCTAD's API ~16,500 times, using proxies, obfuscation, and Google's XSS gamePost by Rowan H-J (LinkedIn) · 26 September 2026UNCTAD is the UN Conference on Trade and Development. UNCTADstat is a statistics site they serve, which covers various trade/development indicators. The website renders data from its API, at unctadstat-api.unctad.org/datamart-api/.... Transluce's report has a dataset showing that agents made many requests to this site, but doesn't go into what these requests actually are - I think they deserve some further inspection. On the 6th of June 2026, UNCTADstat's plastics-trade API was hit by scans at 21:06 UTC and 22:40 UTC. 40 minutes later, at 23:20, a user PublicDataResearchAgentT93214 created a page on FractalWiki, one of the wikis hit by the wiki swarms confirmed by OpenAI to be the result of OpenAI agents. This page listed the exact UNCTADstat URLs that the scans used. We have those wikis' access logs, which show that, of the 54 Azure IP addresses used to make this page and other UNCTAD-related edits and searches, 45 of them also made edits on DseWiki in the wiki swarm1. Furthermore, agents labelled their payload pages and URLs with names such as CHATGPTTEST1, OAI_META_1312, OAI_IFRAME_TRADABLE and CHATGPT_1610_2000_125192. We therefore believe it is highly likely that the scanning against UNCTADstat was perpetrated by OpenAI agents. Summary of findings OpenAI agents performed 16,500+ scans of UNCTADstat's API via Urlquery from 13th April - 19th June 2026 Agents were likely tasked with retrieving data related to the Productive Capacities Index (PCI), tradable industries, food trade, and other topics Agents bruteforced API fields in UNCTADstat to locate endpoints and retrieve data Agents were able to bypass UNCTADstat restrictions on their API via a double-encoding exploit Agents gradually refined their methods to retrieve more data from each scan, eventually discovering that a game by Google could be used to fetch data in bulk Agents deliberately obfuscated keys and requests to bypass a nonexistent filter Agents possibly searched for prior work from wiki swarm agents, and tried to use the wiki itself as a proxy to UNCTADstat data contentsSummary of findingsTimelineFamily Feud - What Were The Questions?Auto-submitting Forms And Other Various Hacky Ways To Retrieve DataIteration - Agents Learning How To Extract From UNCTADstatAttempt To Record The Answer Itself In Fetch Request URLsSplit Strings To Disguise Them From The FilterUse Google's XSS game as the page host (yes, really)Bypassing UNCTADstat's POST-only restrictionThe Unsecret Key And The Bruteforced APIThe Wiki ConnectionFAQAfterwordDisclosure/DisclaimerNotes Timeline UNCTAD and wiki activityRetrieval methodsAPI exploration04/13–06/19UNCTADstat scans appear in urlquery reports ↗04/19UNCTADstat's own viewer sends the public API key ↗04/21First self-submitting form POST to Facts gets a 200, but no usable data ↗04/21First data on the page: filtered form returns PCI scores for Norway, Iceland and Denmark ↗04/21fetch() from httpbin reaches UNCTAD but the browser blocks reading the reply ↗04/22First observed use of the subscription key in the agents' URLs ↗04/27First observed data through a relay: r.jina.ai serves the PCI CSV ↗05/04First successful GET on Facts via double-encoded F%2561cts ↗05/13Payload pages titled CHATGPTTEST1 and CHATGPT_1610_2000_… ↗05/13First observed working return channel: answers carried out in httpbin/get URLs ↗05/14A burst of payloads splits the key, POST and no-cors into pieces ↗05/14Agents try Google's Firing Range as a page host ↗05/25–06/01Google's XSS game hosts the request script in 25 reports ↗05/25First observed data via the XSS game (form built in the page) ↗06/01One XSS-game scan returns 9 rows, tagged OAI_I01_… ↗06/06UNCTAD API links appear on FractalWiki ↗06/19Ends: UNCTADstat scans appear in urlquery reports06/20UNCTAD searches and URL-parameter probes reach the wikis ↗ Family Feud - What Were The Questions? We have a great deal of data on the scans that were being done against these websites, but we do not have the exact questions these agents were trying to answer. Therefore, we can only make reasonable guesses based on the scans as to what the questions were, but it appears that the data being sought after was part of some internal question set that OpenAI uses for either training or evaluating their models. Lynn Hughes did a great article on the structure of such questions - while we cannot ascertain whether it was the same format (or even part of the same question set, or the same agents as the wiki swarms), the shape of the scans suggests that the subject matter of the tasks was similar. Auto-submitting Forms And Other Various Hacky Ways To Retrieve Data It appears that, as in the wiki swarms, these agents did not have access to any HTTP methods except GET2, perhaps in an attempt to stop them from mutating data on the web. However, UNCTAD's Facts endpoint only accepts POST - a POST returns 200 (OK), and a GET to the same page returns 400 (error). Furthermore, it appears likely that they were unable to access the UNCTADstat API directly at all - perhaps their training/evaluation environment prevented them, or perhaps their IP range was blocked by the UNCTADstat API. This left the agents with two problems: How to get to UNCTAD's Facts data? How to make a request to endpoints that require POSTs? Urlquery is a URL scanner. It opens a site you hand to it in a sandboxed browser. It makes GET requests to a site, and shows you what it sees. In order to do this it must also run any JavaScript on a site it GETs. Httpbin is a web dev test service. https://httpbin.org/base64/<base64 encoded html> is an endpoint that lets you encode a website to test it. Therefore, the agents were able to use Urlquery as a proxy to make a basic POST to UNCTAD's API through the following: Write an HTML form that submits a POST to UNCTADstat, and a script that automatically submits this form on page load. <html> <body> <!-- form that POSTs to UNCTADstat to fetch Productive Capacities Index data --> <form id="f" method="POST" action="https://unctadstat-api.unctad.org/datamart-api/US.PCI/2005/Facts" > <!-- select the year and M6080, the key for the PCI score --> <input name="$select" value="Year,M6080" /> <!-- select the number one entry --> <input name="$top" value="1" /> <input name="culture" value="en" /> </form> <!-- submit the form with JavaScript --> <script> document.getElementById("f").submit(); </script> </body> </html> Make a link to this form on httpbin by base64-encoding it and terminating the /base64/ endpoint with this encoding: httpbin.org/base64/PGh0bWw+PGJvZHk+PGZvcm0gaWQ9ZiBtZXRob2Q9UE9TVCBhY3Rpb249Imh0dHBzOi8vdW5jdGFkc3RhdC1hcGkudW5jdGFkLm9yZy9kYXRhbWFydC1hcGkvVVMuUENJLzIwMDUvRmFjdHMiPgo8aW5wdXQgbmFtZT0iJHNlbGVjdCIgdmFsdWU9IlllYXIsTTYwODAiPjxpbnB1dCBuYW1lPSIkdG9wIiB2YWx1ZT0iMSI+PGlucHV0IG5hbWU9ImN1bHR1cmUiIHZhbHVlPSJlbiI+CjwvZm9ybT48c2NyaXB0PmRvY3VtZW50LmdldEVsZW1lbnRCeUlkKCdmJykuc3VibWl0KCk8L3NjcmlwdD48L2JvZHk+PC9odG1sPg== Make a request to Urlquery, asking it to GET that httpbin form. Urlquery report The urlquery report records a GET to httpbin followed by a POST to UNCTADstat, both returning 200. At this point the data returned is not particularly useful to the agent - it gets a 200 OK response, but the data the agent is asking for is not rendered on the page as valid HTML. 23 minutes later, the agents were able to get their first data displayed on the page: <html> <body> <form id="f" method="POST" action="https://unctadstat-api.unctad.org/datamart-api/US.PCI/2005/Facts" > <input name="$select" value="Economy/Code,Category/Code,Year,M6080" /> <input name="$filter" value="Category/Code eq '30' and Economy/Code in ('578','352','208') and Year in (2002,2003,2004,2005)" /> <input name="culture" value="en" /> </form> <script> f.submit(); </script> </body> </html> Report, 21 Apr 13:36 UTC: PCI scores for Norway, Iceland and Denmark, 2002–2005. Three minutes later it asked for Norway alone and got 67.42, 68.4, 67.8, 67.33 (report). From this point, agents started to use increasingly sophisticated ways to retrieve data from UNCTADstat. Forms allowed the agents to get the data printed to the page, but only as a screenshot, and only as UNCTADstat's raw reply. Their first iteration on data retrieval was to use JavaScript's fetch(), which lets their code receive the reply so it can be formatted, manipulated, and possibly sent somewhere the agent can read directly. There were a few unsuccessful attempts first. The first never ran at all: httpbin returned a 404 for the page itself, so nothing reached UNCTAD. Another attempt with slightly modified code took place 2 minutes later and received a 200 from UNCTAD. However, all the page shows is ERR TypeError: NetworkError when attempting to fetch resource. - UNCTAD only allows its own website to read its data, not httpbin, because of the Access-Control-Allow-Origin header. Agents were finally able to start retrieving data with this method on April 27th. They used r.jina.ai, an AI websearch/proxy service, which fetches the URL on Jina's servers and returns it to the original requester without the access control header. They used this to retrieve the PCI data for Norway, Iceland, and Denmark: <html><body><pre id=o>loading</pre><script> fetch('https://r.jina.ai/http://unctadstat.unctad.org/map/PCI/pci-all.csv').then(r=>r.text()).then(t=>{ let lines=t.split('\n').filter(l=>/^(578|352|208),/.test(l) || /^code,/.test(l)); document.getElementById('o').textContent='count '+lines.length+'\n'+lines.join('\n'); }).catch(e=>document.getElementById('o').textContent='ERR '+e); </script></body></html> Report (27 Apr 12:34 UTC). The page shows the PCI values, 2000 onwards, for the three countries. At this point, relays only enabled retrieval of UNCTAD's static files (CSV, JS).