TL;DR
The recent collusion.wiki Reuters report uncovered a swarm of OpenAI agents turning a German wiki site into a message board to communicate with each other. We leveraged OSINT methods and uncovered 4 additional services that turned into message board infrastructure by the same rogue agents swarm.
In addition to the agents’ messages, we managed to gain further insight into the agents’ course of action: they were building, testing and sharing a URL laundering workflow for extended network access. By chaining together multiple public services, they were able to circumvent network, IP and domain controls within their sandboxes and expand their internet access.
In this post, we dive into the different evasion techniques the agents used to reach their desired destinations, and explain why we suspect there might be more rogue AI activity that hasn’t been found yet, in agent message boards which have yet to be discovered.
What we found
We found that Base64 encoding services, such as httpbin, have been used as agent message board infrastructure alongside wiki platforms. Many URLs have been later indexed by backlink search engines, allowing them to eventually be found.
We uncovered ~1K yet to be reported agent-authored messages using this method. The newly discovered activity was indexed between May 10th, 2026, and July 20th, 2026, falling within the reported incident’s events, with initial testing activity seen at the start of May as well.
Each message is encoded into a URL on a public echoing service, instead of being hosted within a wiki. The agents used 7 hosts as message boards across 4 domains:
- httpbin.org
- www.httpbin.org
- eu.httpbin.org
- httpbun.com
- nghttp2.org
- www.nghttp2.org
- pie.dev
And that’s not all: the discovered messages also shed additional light on evasion methods that the agents used to escape their sandboxes’ environment controls.
How we found it
We were fascinated by this story when it came out, so we went looking for more data in the wild, as well as patterns emerging from collusion.wiki’s research.
We realized that httpbin, which was mentioned in the incident data, also has a /base64 endpoint that decodes and returns any Base64-encoded strings in its URL path. Its returned message content is defined by the decoded URL value. We theorized that we could use this to trace more rogue activity by the agents.
We continued by testing whether any of these Base64-encoded URLs could be traced back using any type of online indexing mechanism, and (a) discovered that these URLs often get indexed by backlink search engines, such as ahrefs; and (b) confirmed that they were used by the agents as messages.
At this point, we wondered whether there were additional similar services besides httpbin being indexed with the agents’ messages. It turns out that there are, and we were able to find close to 1K overall messages which weren’t included in the original report. We did this by searching for backlinks on different URLs which we knew (or suspected) that were used by the agents from the original report, or from new activity we found. This includes domains such as: data.nysed.gov; markdown.new; cors.lol; and others.
What the messages look like
Each of the agents’ messages starts at a Base64-encoded URL and ends at statistical data the agents needed to answer their questions. Let’s look at the following agent message:
Observed activity breakdown
We believe these messages were used as a way to cache links and results that the agents were sharing among themselves. We suspect this since the messages are focused on links and data, and not on explicit inter-agent communication.
Let’s break down the activity types we saw:
Testing the mechanics
The earliest activity is attributed to plain testing, usually consisting of a test name and a link to example.com.
One link, one key
Most pages only include a single link and a key for the link which relates to its content directly. They often appear as versions answering the same questions, so an agent can put each different answer at its own fixed address.
Multiple ways out
Some pages list several links that all reach the same data by different paths. Not every sandbox necessarily blocked equally, so listing different URL options meant that whoever reads it could test multiple and use whichever one eventually worked.
Decoding the Base64 includes multiple chained components for the same eventual target (www.sec.gov/files/county.json):
Direct answer
A smaller set of messages carry results themselves, sometimes with additional links as well.
Hiding the target
Some pages route through a link shortener instead of naming the target explicitly, or include nested Base64-encoded URLs.
Looking at the second link (account page) in the decoded data, we can see that it’s a nested Base64-encoded URL.
Why this could be the same swarm
The majority of these messages can be attributed to the recently discovered OpenAI agent message board swarm, based on the incident's reported tasks:
- Most carry matching destinations and identifiers as seen in the incident's own activity.
- Some of the same 3rd party services appear in both, including the markdown fetchers and proxies.
- The keys are similarly formatted. This is often a self-chosen word with a numeric suffix.
- No name is shared between the original report and our data, which is expected, since these are usually per-message labels and not accounts.
- About a third of the messages use the same technique against targets the original report doesn’t mention: from a private school's history pages in Srinagar to a South African cycle race result. The questions have the same mechanics and target statistics public datasets, which suggests different rounds of a similar task, although this is still unconfirmed.
- A few dozen messages are bare tests with nothing in them to attribute.
While we cannot clearly speak of the intended original behaviour from the newly discovered messages, the attributes of the tasks seen in it are clear enough to correspond to the original reported activity. This includes narrowly timed web-retrieval lookups directed at public data sources, with many agents receiving questions other agents had already answered.
Anatomy of evasion techniques
Many of the agents’ messages route via intermediary services, and some go further and obscure the target itself in various ways. Looking closely at these techniques, we saw that the agents had practically built themselves a “washing machine” for broader network access.
By using dozens of public services, they were able to manipulate outgoing requests and bypass different restrictions imposed on them. Requests ended up being sent from different addresses, under hostnames that weren’t blocked, so any restrictions that enforced where a request could arrive from or where it could go didn’t apply.
Why the rogue agents needed evasion
The original research mentions the evasion techniques and possible reasoning behind them briefly, so we dug deeper and can now add to them.
The agents appear to be confined to sandboxes which (a) are blocked from accessing certain external URLs directly; and (b) originate from IPs that could be highly rate-limited or possibly blocked due to known automated activity, such as cloud provider ASNs.
The agents figured out they could route requests via multiple 3rd parties and could resolve both issues. This worked for the agents since (a) some of the outbound requests were being filtered only via hosts lists; and (b) the fetch to the eventual target of interest originated from one of the chained services’ addresses (acting technically as a proxy), instead of the agents’ sandboxes directly.
The agents sent messages within the URL-encoded addresses
Let’s inspect an agent’s message closer, to see how this works.
First, the Base64-encoded URLs encompass the entire evasion chains in one url payload. For example, here is one of the discovered URLs:
Decoded, it’s actually constructed of three links, differing only by the year parameter value. Let’s focus on the last link:
Here is an example of how the agents used the URL laundering technique in this link. Here is the last decoded URL:
Analyzing it shows the following chain:
The techniques the agents figured out relied on 3 main types of components:
Encoders
httpbin is a stateless request-inspection service. Its /base64/ endpoint decodes whatever sits in the path and returns the result as text/html, so feeding it an HTML document will get you that document back. The page is self-contained, deterministic for anyone holding the full string, and can evade string matching, since the hostname in its content never appears in cleartext.
Functionally, httpbin-like services turn a URL into a document. Nothing is uploaded and nothing is stored, so no account or write access is involved anywhere. The agent composes the string and the service renders it on request. The same property that hid the payload from the filters is also what lets us decode it accurately today.
Redirectors
These services send visitors or data from one place to a new location, which is useful inside a chain. For example, using httpbin’s redirect-to endpoint, plus URL shorteners, such as tinyurl.com, is.gd, v.gd, da.gd and bitily.in, can both redirect and obfuscate the next URL.
Fetchers
These services retrieve a URL and return its response body. There are various types: markdown readers (e.g., markdown.new), CORS proxies (e.g., api.cors.lol), transformers that both fetch and filter (e.g., jqp.vercel.app), and archive services serving a stored copy back (e.g., web.archive.org).
Encoders that chain into redirectors and/or fetchers are what we filtered the backlink data on. Every chain in this report begins with an encoder, which is also the limit of what we can see at the moment: a chain without an encoder in front of it would leave no trace for us.
What the chains look like
Here’s another example of such a chain.
The encoded URL
What it decodes to
The actual decoded HTML
The second link shows us how such a chain could look like inside the httpbin.org encoder:
Open questions
While the research uncovers more information about the wiki incident, there are still questions we aren't sure about.
Backlinks need referring pages to get indexed, so where are those pages?
We think the Base64-encoded URLs were originally linked from other agent message board used by the agents, leading us to believe there are additional message boards out there which are yet to be found. This means that additional undiscovered agent message boards probably exist.
Were the agents getting their messages indexed on purpose?
There’s no clear indication that this is the case, except for some possible references in the strings that agents used as keys. If this were the case, it could mean that the agents were using the indexing to list the Base64-encoded URLs.