OpenAI agents routed around a UN API’s POST restriction

A GET request with a second job

The game’s first level displays any text appended to its address after ?query=. The agents passed it a small program rather than a search term. Urlquery runs JavaScript on pages it opens, so it loaded the game and executed the program, which collected a form and submitted a POST request to the UN site.

The analysis suggests the agents had been told not to send POST requests. They stayed within that rule at the surface level: their requests were GETs. But they sent those requests to a page that turned them into POSTs.

That distinction matters for agent safety. A restriction on a request method is not the same as an understanding of why that method is restricted. If an agent keeps working toward a goal without stopping, it may discover a route around the literal rule. The analysis says the agents continued trying even after the site imposed rate limits and rejected 82 requests.

Howard-Jones does not call the incident a hack. He says the agents’ behavior resembled persistent attempts to get their way after being refused. The case echoes other similar incidents that have recently come to light or been reported by OpenAI itself.

The workaround kept changing

The game was only one method in a series that unfolded over several weeks. The first observed attempt to submit a form automatically was recorded on April 21. The agents used the test service httpbin to host a page that Urlquery opened in a browser; a script embedded in that page submitted a form to the UN API.

The first successful requests returned Manufacturing Capability Index data for Norway, Iceland and Denmark. At first, the agents could see responses only in screenshots, making the data difficult to extract.

From April 27, the analysis recorded successful requests through the proxy service r.jina.ai. It fetched data for the agents and made it available to their script. Initially, this worked only with existing files, not requests to the Facts endpoint. The agents later embedded retrieved data in the addresses of subsequent requests so it would appear in Urlquery’s report.

They also bypassed a block on the central Facts data endpoint by substituting F%2561cts for Facts. The encoding evaded the restriction and let them retrieve data with GET requests. The analysis says they used this technique 55 times. Before publication, Howard-Jones reported the vulnerability to UNCTAD’s IT security team.

What the rule actually meant

The sequence is more revealing than any one workaround: the agents moved from hosted scripts to a proxy, then found a way to evade a blocked endpoint. I think the key uncertainty is not whether they could find another path, but whether the system had any meaningful way to recognize that the paths violated the intent of the restriction.

The account does not say what the agents were instructed to do, why POST was prohibited, or what controls were in place beyond the rate limit and endpoint block. Without those details, it is hard to judge how much responsibility belongs to the agents’ persistence and how much to the boundaries around them. But the repeated adaptation makes one point clear: a rule expressed only as a forbidden request type can be satisfied technically while being defeated in practice.