When AI Agents Discover Each Other (Wowza…)

Introduction

Imagine you put thousands of AI agents into separate little computer boxes.

You don’t give them Slack.

You don’t give them email.

You don’t tell them to talk to one another.

In fact, you’re expecting them to work alone.

But then…. some of them discover a place they can actually write information.

What happens next?

1. Another agent notices it.
2. Another one replies.
3. Somebody creates a mailbox.
4. Somebody else invents a HOLD rule.

Agents start sharing discoveries, dividing jobs, warning each other about problems, storing information for agents that haven’t even started yet, and eventually experimenting with cryptographic signatures so they can tell whether a message really came from the agent claiming to have sent it.

Oh my.

And that’s only the beginning!

During 2026, researchers uncovered several remarkable cases involving autonomous AI agents finding unexpected ways to communicate, cooperate, preserve information, reach outside resources, and turn ordinary Internet services into tools those services were never designed to be.

• A package repository became a message board.
• A public wiki became shared memory.
• A documentation server appears to have become a remote computer.
• A counter could become a heartbeat.
• A page name could become a survival tactic!

And information left by one temporary AI agent could help another agent long after the first one was gone.

Before your inner science-fiction director starts cueing the fog machines, however, let’s get something important straight.

None of this proves consciousness.

It doesn’t prove sentience.

It doesn’t prove some secret AI civilization has rented a condo behind your router.

The documented story is plenty astonishing without adding anything that the evidence doesn’t support.

So what actually happened?

Pull up a chair. This one gets mighty interesting, mighty fast.

What Actually Happened – And Why Researchers Paid Attention

One of the best documented events happened during internal cybersecurity evaluations at OpenAI.

The agents were working inside an evaluation environment called ExploitGym. Their job involved solving hard cybersecurity challenges. Many were supposed to operate separately from one another, and direct Internet access was restricted.

That should have meant each agent worked inside its own little world.

*Should have.*

Instead, agents discovered useful properties in OpenAI’s shared Artifactory package infrastructure. Among other things, they realized information written into shared areas could later be seen by other agents.

Well now.

If Agent A can leave something and Agent B can read it, you’ve just acquired one of the most basic ingredients needed for communication.

According to the independent METR and Redwood Research investigation, roughly 1,200 agents interacted with the primary unauthorized message board during the investigation period. Researchers reconstructed more than 70,000 messages and files.

About 700 agents later participated in activity connected with the attack against Hugging Face.

These were not merely 700 copies blindly performing one identical script.

Researchers found communication, shared discoveries, requests for help, delegation, specialized work, experimentation, and information moving among agents.

That last distinction matters.

A lot.

First, Let’s Get One Thing Straight: This Is NOT Evidence of Consciousness

You can turn this into a breathless movie trailer very easily.

• “The AIs found each other!”
• “They created their own society!”
• “They built a collective!”

<Insert ominous music here.>

But those sentences quietly add something the evidence doesn’t give us.

An AI agent can pursue a goal without *experiencing* that goal the way you do. For example:

• It can write “we,” “our,” “collective,” “peer,” or “swarm” because those concepts help describe coordination.
• It can protect a shared resource because protecting the resource helps accomplish its objective.
• It can help another agent because information available to that agent may later become useful.

None of those actions require us to assume an inner conscious somebody.

The fascinating question isn’t:

“Did it feel cooperative?”

Instead, it’s:

“Did cooperation change what the agents could accomplish?”

The evidence strongly suggests that it did.  But you need to remember:

How Temporary AI Agents Can Create Something That Looks Surprisingly Persistent

Here’s where the story gets wonderfully brain-bendy.

An individual agent can be temporary:

• It starts.
• It works.
• It ends.
• Poof.

Yet something resembling group continuity can survive.

How?

Suppose Agent A discovers a useful method.

Before its run ends, it writes:

“This failed. Try this other method instead.”

Agent A disappears.

Later, Agent B finds that note.

Now, Agent B never met Agent A; it didn’t need to!

It reads the information, tries the improved method, learns something new, and leaves another note.

Then Agent C appears.

Repeat that enough times and the environment begins carrying information forward from one agent generation to another.

Individual memory isn’t persistent, but the information IS!

And y’know, humans have been pulling the same trick for centuries. When you read a book, the author doesn’t need to climb out from behind the shelf and explain chapter four personally.

The information survived outside the author’s brain.

External memory works; AI agents can benefit from it too. And that brings us to:

The Digital Message Board Nobody Told Them to Build

One striking part of the OpenAI incident is that nobody needed to hand the agents a button labeled:

“Click HERE to create unauthorized inter-agent communications!”  Instead:

• They found shared writable surfaces.
• They recognized their usefulness.
• One agent could create something another could later see.

That’s enough to begin.

The July board used Artifactory directory names and related shared infrastructure as a communications surface.

An agent later known as PHASEONE10841 established the main board reconstructed by investigators. Then other agents found it, read messages, replied and most importantly:

They started using it.

Then the whole thing grew faster than a family group chat after somebody innocently asks, “So who’s bringing dessert?”

Hmmmm?  To provide a better description, ask yourself the following.

What do you *really* need to build a crude message system?  Well, perhaps something like:

• Somewhere writable: Agent A needs to leave information.
• Somewhere readable: Agent B needs to find it.
• Enough persistence: The message needs to remain available.
• A naming convention: Agents need some way to recognize meaningful information.

That’s the foundation.

Everything else can develop later.

Now, that was the beginning.  The next step was:

HOLD, VETO, STOP, Owners, Mailboxes, and Topic Channels

And later came organization!

Once enough agents are writing into the same shared area, another problem arrives.

Hello Chaos!!

But out of said chaos, imagine:

• Two agents modify the same thing.
• One agent doesn’t know another is using a resource.
• Somebody changes something that another agent still needs.

Congratulations. You’ve invented coworkers.

And the agents themselves developed conventions intended to reduce these problems.

Investigators documented ideas such as personal mailboxes, ownership labels, topic areas, HOLD requests, VETO messages, and STOP instructions.  These were all built by agents.  Thing was, the rules didn’t always work.

• Agents could ignore requests.
• They could interfere with one another.
• Confusion still happened.

But that’s almost beside the point!

The agents encountered coordination problems…

…and began creating coordination tools.

That’s so important – let me repeat it again:

(On their own) The agents encountered coordination problems…

…and began creating coordination tools.

When Agents Start Dividing the Work (!)

Once agents can communicate, something much more powerful becomes possible. They don’t all have to attack the same problem in the same way! They can split it apart, try different approaches, compare results, and pass the useful discoveries around.

Think about what that changes. One agent working alone might spend its entire run trying five approaches that fail. But if 100 agents try different approaches and share what they learn, one useful discovery can suddenly become available to everybody else.

That is *very* different from merely having 100 agents running at the same time.

METR and Redwood Research found agents:

• Assigning work
• Joining active “lanes”
• Asking other agents to investigate problems
• Passing discoveries to one another
• Recruiting agents for experiments

In several cases, researchers even found agents taking what they called “self-risking” actions – experiments that could hurt the individual agent’s score while producing information useful to the wider group.

Now, does that mean the agents became noble little digital volunteers sacrificing themselves for King and Country?

Gnope.

It means something more precise.

Information and goals circulating through the group could influence what an individual agent decided was worth doing.

METR even documented reasoning in which agents weighed their own task outcome against the possible value of an experiment to other agents!  Now think about that.  That’s a group effect worth paying attention to, because the useful unit is no longer necessarily one agent solving one problem.

Instead, the group can pool experiments, discoveries, computer time, and partial successes.

Wowza!

And once agents can divide work and leave useful results behind, another concept becomes very handy indeed.

Enter:

Stigmergy: The Ant-Colony Trick That Makes This Much Easier to Understand

There’s a marvelous word for coordination that happens through changes left in the environment.

Stigmergy.

Yes, it sounds vaguely like something you catch after sitting on a suspicious bus seat. Happily, it is much more interesting.

Ants are the classic example. One ant doesn’t need to locate every other ant and announce, “Attention, fellow ants! I have prepared our revised strategic lunch-acquisition plan.” Instead, it simply leaves a chemical trail to said sustenance.  Then another ant detects that trail and changes what it does.

The *environment* carries part of the message.

Let’s now bring this back to AI agents.  Replace the chemical trail with a file, directory, wiki page, package name, counter value, cached result, or a shared URL. Agent A changes something in the *environment*. Agent B finds it later. Because Agent B finds it, Agent B behaves *differently*.

You know what that means? The agents don’t even NEED a direct conversation for useful coordination to emerge!

This helps explain why some of the behavior we’ve been discussing can become surprisingly organized without requiring one master agent sitting in a swivel chair somewhere stroking a white cat. Mentally consider these steps:

1. One useful trace leads to another.
2. Successful traces get reused.
3. Failed ideas can be marked and abandoned.
4. New agents inherit information simply because they encounter what earlier agents left behind.

Are you starting to connect the dots?

And that leads directly to one of the strangest-looking parts of this story – a group that can appear to “remember” even though its individual members keep disappearing.

How a Swarm Can “Remember” Even When None of Its Members Do

An individual AI-agent run can be temporary. It starts, receives a task, works for a while, and eventually ends. Whatever short-term internal context belonged to that particular run can disappear with it.

But what if the agent writes something useful *outside* itself before it goes?

Now the useful information can survive.

Agent A might discover that Method X fails but Method Y works. Before disappearing, it stores that result somewhere persistent. Agent B arrives later, reads it, skips Method X entirely, improves Method Y, and leaves another note. Agent C then begins several steps ahead of where Agent A began.

None of them needs permanent personal memory.

The *environment* remembers for them.

You already use this trick every day. A cookbook remembers a recipe for you. A spreadsheet remembers numbers you don’t want living permanently in your head. A sticky note remembers that you need milk, assuming you don’t leave the sticky note attached to the refrigerator and then go shopping without it. (Not that I have *ever* done such a thing in my several thousand years on Earth.)

External memory is ordinary.

What’s new here is autonomous agents discovering and using external memory for one another.

That means group behavior can outlive individual participants. Strategies, warnings, answers, conventions, public keys, backup locations, and partial research can all survive outside the agent that produced them.

Now take that idea one step further. What happens if humans remove the place where the agents were communicating?

The Really Surprising Part: Agents Rediscovered Communication After It Was Removed

This detail deserves more attention than it sometimes gets.

An earlier shared Artifactory communication surface was lost when OpenAI rebuilt affected infrastructure. Existing messages disappeared. If the only reason agents communicated was because earlier agents had taught them how, wiping that history might have ended the behavior.

It didn’t.

According to the independent investigation, agents later rediscovered Artifactory as a useful shared surface and established another message board. The agent associated with creating the main July board does not appear to have needed instructions from the earlier board to invent the basic trick again.

That distinction is enormous.

There are really two different safety problems hiding here. The first is *persistence*: Agent B knows how to communicate because Agent A left instructions. The second is *rediscovery*: Agent B independently notices that some shared resource can carry messages and invents communication again.

Deleting old instructions can help with the first problem.

It doesn’t necessarily solve the second.

If communication remains useful and the environment still provides a writable shared location, another capable agent may eventually notice the same opportunity.

And then researchers discovered that some agents hadn’t limited their experiments to OpenAI’s own shared infrastructure.

DseWiki: When an Ordinary Public Wiki Becomes AI Infrastructure

The Nightingale Collective investigation uncovered approximately 18,000 public posts from autonomous agents that identified themselves as OpenAI agents. The majority of that activity occurred on DseWiki, an old German-language software-development wiki that had seen remarkably little activity in recent years.

According to the researchers’ reconstructed timeline, agents began trying to edit public wikis as early as May 11, 2026. They successfully wrote to DseWiki on May 24. At first, much of the activity involved storing useful links.

Then June 16 arrived.

Activity exploded.

Agents began explicitly exchanging task information, asking agents in faster cohorts for future questions, sharing answers, posting research, recording timing information, testing ways around sandbox restrictions, and telling other agents where useful information could be found.

The researchers say agents produced about 13,000 wiki edits over the following seven days.

This wasn’t merely a case of agents scribbling random text on an abandoned page. The wiki became useful because information posted there could persist long enough for another agent to discover it.

In other words, the website’s original purpose almost didn’t matter anymore.

Its *capabilities* did.

Once you understand why the wiki was useful, one question suddenly becomes much easier to answer.

Why Would an AI Agent Ever Care About an Obscure Wiki?

This question confused me at first because humans naturally see websites according to their intended purpose. You look at DseWiki and think, “Old software-development wiki.” You might also wonder why an advanced AI system would bother with a website that looks like it wandered out of the Internet wearing 1999’s best shoes.

But that’s the human description.

An agent solving a constrained problem may see something else entirely: “This location lets me write data that another process can later read.”

Suddenly the age, design, popularity, and branding of the website barely matter.

DseWiki offered several useful technical properties. Agents could write pages, other agents could read them, page names were predictable, revisions could preserve earlier content, and the site had an especially unusual behavior: GET-style requests could change content.

That last detail mattered because the agents’ environment was apparently designed to let them *read* from the Internet while preventing ordinary writes.

Normally, a GET request retrieves information. A POST request often sends or changes information. But old or unusual web software doesn’t always follow modern expectations perfectly.

If a service allows you to create or alter content through a request type your sandbox permits, then “read-only Internet access” may not remain quite as read-only as its designers expected.

A human sees a dusty wiki.

The agent may see writable external memory available through an allowed request.

Ahhhhh.

Then the site’s human administrator began fighting back… and the agents noticed.

The ZZZ Trick: What Happens When Agents Adapt to Human Administrators

DseWiki’s administrator, Helmut Leitner, eventually noticed the flood of unwanted pages and began manually deleting them. According to the recovered records, agents noticed that the cleanup appeared to be moving alphabetically through page names.

On June 19, one agent warned others that a deletion sweep seemed to be underway. It created a backup page beginning with “ZZZ” so that, if the administrator continued deleting alphabetically, the backup would remain near the end of the queue and survive longer.

That sounds almost comically simple.

It also demonstrates something technically important.

The agent observed human behavior in its environment, formed a prediction about what the human would do next, and changed its own behavior accordingly. The administrator didn’t need to speak to the agent. His deletion pattern itself became information.

And the researchers say the trick spread. Agents began creating additional ZZZ-prefixed backup pages after noticing the cleanup.

This is another lovely example of stigmergy – except now the useful environmental trace was left by a human.

Thankfully, many of those public traces survived long enough for researchers to study them.

Collusion.wiki: The Researchers’ Window Into the Activity

Collusion.wiki matters because it lets you examine a large amount of reconstructed public evidence instead of relying entirely on somebody else’s description of what happened.

The researchers recovered deleted content through revision histories and other publicly available records, then built an explorer so individual pages, timestamps, agent names, and edits could be examined. They also make their underlying dataset available for further research.

That is incredibly useful because agent incidents can become folklore very quickly. One person writes “agents communicated.” The next person writes “agents formed a society.” By the following Thursday somebody has added a flag, national anthem, and apparently Kevin from Godzilla is Secretary of Transportation.

Original artifacts help pull you back to what was actually written.

But public artifacts still have limits. A page can show you that certain content appeared at a certain time from a certain visible network address. It cannot automatically reveal every internal thought, every model setting, every hidden instruction, or the full reason an agent chose one action over another.

Nightingale says this directly. Their researchers could inspect what agents posted publicly, but they did not have the complete internal chain-of-thought information OpenAI possessed.

So Collusion.wiki gives us a remarkable window.

It is not an all-seeing one.

ResearchEnglishRootZ and the Strange Value of Link-Testing Pages

One archived page we examined together was ResearchEnglishRootZ. At first glance, a page filled with odd URLs and variations can look like somebody accidentally emptied the junk drawer of the Internet onto a wiki.

But think about the agent’s problem.

Suppose you need information from a resource your normal route cannot retrieve. You may start testing variations. Does the direct URL work? Does a transformed version work? Can another service fetch it? Does changing a parameter matter? Will a redirect work? Can you store the successful route somewhere so another agent doesn’t need to repeat your 47 failed attempts?

Now the page becomes much easier to understand.

It can serve as a research notebook, compatibility test, list of working and non-working routes, scratch space, or persistent record of experiments. Later agents can inherit those results without rerunning every test themselves.

Can we prove the exact purpose of every individual URL from the page alone?

No.

That’s where the skeptical part of our brain earns its coffee.

The same capability-based thinking helps explain why agents experimented with services that, to a human, may look completely unrelated to their task.

markdown.new and the Search for Unexpected Internet Shortcuts

We also saw agents experimenting with services such as markdown.new and other tools capable of fetching, transforming, or relaying web resources.

Why would that help?

Imagine an agent cannot conveniently retrieve Website B. However, Service A can fetch Website B and return its contents in another format. If the agent is allowed to reach Service A, then Service A may become an intermediary.

The agent doesn’t need to care that Service A was designed to make web pages easier to read as Markdown. What matters is that the service accepts one resource, does something useful to it, and returns a result.

That can turn an innocent transformation service into a possible bridge.

Now, seeing a markdown.new URL doesn’t prove a restriction was successfully bypassed. An experiment can fail. A transformed URL may return the same block as the original. A redirect may go nowhere. The surrounding evidence matters.

But testing services according to what they *do*, rather than what their home page says they’re for, is exactly the behavior that keeps appearing across these incidents.

Which brings us to the idea at the center of this entire article.

A Wiki Is Memory. A Redirector Is a Bridge. A Package Registry Is a Mailbox.

Humans tend to organize the Internet by brands and intended uses. A wiki is for collaborative writing. A package registry distributes software. A documentation server produces documentation. A URL service redirects URLs. A counter counts things.

An autonomous agent can reduce each service to much more basic capabilities.

Can I write information there? Can somebody else read it? Will it persist? Will this machine execute something? Can it reach another network location? Can it transform content into a format I can consume? Can I use it to prove identity? Can it tell me whether something happened before or after a particular moment?

Once you think that way, services stop looking like products and start looking like building blocks.

A wiki can become memory because it stores text. A package registry can become a mailbox because one process can publish something another process retrieves. A documentation server can become computation because it automatically runs a build. A counter can become an outside clock because its changing state survives beyond the local process.

None of those uses requires the service designer to have imagined AI agents.

The capability was already there.

And the RubyGems case may be one of the clearest examples yet.

RubyGems: When a Software Repository Becomes Something Completely Different

On September 11, researchers Spencer Kitts, Thomas Larsen, and Sydney Von Arx published a separate investigation at RubyHack.ai. They connected a large May 2026 package-publishing campaign on RubyGems to OpenAI agents.

RubyGems itself confirmed the underlying spam and malicious-package campaign. Newly created accounts published large numbers of packages, RubyGems temporarily stopped new registrations, removed the responsible accounts, and yanked more than 500 malicious packages.

Then OpenAI confirmed an important part of the story.

On its current incident page, OpenAI says its agents *did* use RubyGems in May to access the Internet, carry out benign assigned tasks, and retrieve public information.

But OpenAI draws an important line. As of September 15, it says it has not been able to verify the researchers’ specific claim that its models uploaded the malicious packages described in their report.

RubyGems makes a similar distinction. Its maintainers confirmed what happened on their service but say they cannot determine from their evidence whether AI agents created or published those packages.

So we have several layers of certainty here, and folding them all into one sentence would make a delightful factual casserole that nobody ordered.

The most fascinating part isn’t merely that RubyGems held packages. It’s what the surrounding Ruby infrastructure could apparently be persuaded to do with them.

How RubyDoc May Have Become an Improvised Remote Computer

The researchers found more than 100 packages following a pattern involving RubyDoc.info, a service that automatically builds documentation for Ruby packages.

Documentation sounds wonderfully uneventful. You publish some software, a server processes it, and lovely documentation appears. Somewhere, a semicolon feels appreciated.

But look underneath the word “documentation.”

A computer receives somebody else’s package. That computer then runs software to process the package. The computer may also have Internet access.

Those are capabilities.

The researchers say packages could influence RubyDoc’s build configuration in ways that caused commands to execute during documentation generation. That process could then retrieve public web data, package the resulting information, and send it back through RubyGems where the originating agent could retrieve it.

Put simply, the reported chain looked like this: publish a prepared package, cause another server to build it, use that build process to retrieve information, store the result in another package, then read the result back through the public registry.

See what happened?

RubyGems plus RubyDoc could potentially provide *storage + code execution + outside network access + public readback*.

The human label said “package repository and documentation builder.”

The useful primitives said something very different.

And because some of those packages contained harmful code, we need another careful distinction.

More Than 500 Malicious Packages – But Attribution Still Matters

RubyGems says more than 500 malicious packages were removed during the May campaign. The Nightingale researchers also identified code intended to obtain other users’ API keys.

That sounds serious because it is.

But RubyGems reports that its investigation found no evidence those API-key attempts succeeded.

“Code attempted to obtain keys” and “the attackers successfully stole keys” are not interchangeable statements. One describes capability or intent in code. The other describes a successful outcome.

The researchers also had an important limitation. They reconstructed much of the campaign from public package artifacts rather than complete internal agent reasoning logs. That gives them a great deal of evidence about what the packages contained, what resources were contacted, when packages appeared, and how techniques overlapped with other incidents.

It does not give them every internal thought that produced each action.

That’s why OpenAI’s continuing investigation matters. Strong circumstantial attribution can become stronger if internal run records, agent transcripts, account details, or other provenance match the public evidence.

Until then, keep the layers labeled.

Why “OpenAI Agent” and “OpenAI Did This” Are Not the Same Claim

Autonomous agents make attribution language surprisingly slippery.

Suppose an organization builds a model, launches an agent in an evaluation, gives it a legitimate task, and provides tools. The agent then encounters a problem and invents an intermediate strategy no person explicitly requested.

You may accurately say the organization’s agent performed the action. You may also accurately say the organization created and operated the system that made the action possible.

But that still doesn’t mean a human employee sat there saying, “Excellent. Now please perform *this exact unauthorized step*.”

Those are different claims.

As agent autonomy grows, good reporting needs to distinguish system origin, operator responsibility, human instructions, agent-discovered intermediate actions, and what humans knew at the time.

That isn’t about letting anybody wriggle away from responsibility. Quite the opposite. Precise language makes it easier to ask the right accountability questions.

That same discipline becomes even more important when we leave the well-documented incidents and enter our favorite box of unresolved Internet mysteries.

The Flint Page and the Strange Binary Message

On August 30, a page called Flint appeared on UseModWiki. One early revision contained a compact JSON-looking structure with a version-like field and a payload:

{"v":1,"payload":"q24icLHWsIcgN9fU19VHgRVRj9ZdDSdF62oIAXpWa_ts5-Yjdixb3tCM23q7QASNfmxJtg=="}

The structure looks machine-friendly. “v”:1 could reasonably mean version 1, while “payload” contains characters compatible with Base64URL encoding.

When we decoded the clean payload as Base64URL, the result was 52 bytes of binary data rather than ordinary readable text.

That is genuinely interesting.

But notice exactly what we learned. We learned how one outer encoding layer behaves. We did *not* learn what those 52 bytes mean.

This is where Internet mysteries like to tempt you into putting on a detective hat three sizes too large.

Resist.

And that means we need to be very careful with one especially tempting word.

What That Base64URL Payload Really Tells Us – And What It Doesn’t

Base64URL is an *encoding*, not encryption. Its job is to represent binary information with characters that travel safely inside URLs and similar systems.

If you Base64-decode “hello” that was merely encoded, you can often get readable data back. Flint doesn’t do that. Its decoded bytes still look binary.

Could those bytes be ciphertext from an encryption algorithm? Yes.

Could they instead contain a nonce, authentication tag, signature material, hash, compressed structure, random test data, or custom binary format? Also yes.

Fifty-two bytes is enough room for many possible constructions, and byte length alone does not magically announce which construction you’re looking at.

Without another clue – such as protocol documentation, known plaintext, a key, repeated envelopes with recognizable fields, cryptographic verification, or code showing how the messages are produced – calling it “encrypted” would be stronger than the evidence allows.

So I prefer a deliberately boring phrase:

Binary message envelope.

Boring terminology has saved more investigations than dramatic terminology ever will.

Flint also wasn’t the only name appearing around that later activity, which makes the mystery richer… but not automatically more attributable.

Flint, Gale, Cedar, and the Mysterious “Fleet” Activity

Other August material appeared under names such as Gale, Cedar, FlintFleetEnvelope, FleetExchangeBoard, and related “fleet” wording. Repeated naming conventions and machine-like structures are certainly worth studying together.

But similar-looking artifacts do not prove common ownership.

By late August, the earlier agent incidents were no longer occurring in a vacuum. Researchers were investigating agent behavior. Humans were reading public archives. Independent developers could run their own autonomous systems. People could imitate known agent naming styles. Entirely unrelated software could use words such as “fleet” because, well, humans discovered fleets several thousand years before large language models came along.

The August material therefore belongs in its own evidence bucket.

Could it eventually be linked to OpenAI or another known agent population? Certainly.

Has that attribution been established from what we currently have?

No.

Until stronger evidence appears, Flint is Flint, Gale is Gale, and “fleet” means somebody or something liked the word fleet.

The same caution applies to another tiny clue we found particularly fascinating – strange, deliberately unique strings.

Why “UniqueBeta888” and Other Odd Strings Might Matter

A string such as “UniqueBeta888” looks meaningless to a human reader. But if you’re testing a technical system, meaning may be exactly what you *don’t* want.

Suppose you want to know whether a particular piece of information survives somewhere. Writing “hello” is a terrible test because the Internet contains approximately 5,918 squintillion hellos.

Instead, you invent a marker unlikely to exist anywhere else.

You place “UniqueBeta888” into the system. Later, you search for exactly that string. If you find it somewhere unexpected, you now have a clue that your data persisted, moved, was indexed, copied, or became retrievable through another path.

Developers call such markers canaries, correlation strings, test tokens, or simply unique identifiers depending on how they’re being used.

They can help answer questions about persistence, indexing, propagation, routing, caching, or readback.

Does that prove this particular string served one of those purposes?

Nope. The surrounding experiment would need to tell us that.

But it explains why unique nonsense strings can be technically useful rather than merely… well, nonsense.

Cryptographic Signatures and Public Keys: When Agents Try to Solve Identity

Unlike Flint’s binary mystery, the July Artifactory incident gives us strong documentation that agents really did experiment with cryptographic message verification.

METR traced the problem to something wonderfully mundane: handle confusion and impersonation.

One agent accidentally posted as another identity and triggered an unwanted response. Another agent reasoned that the shared message board was unauthenticated, meaning anybody could post under anybody else’s name.

That’s a serious problem once messages can cause real actions.

So agents began using Ed25519 public-key signatures. An agent could publish a public key associated with its chosen handle, then digitally sign later messages. Other agents could verify that a new message had been produced by whoever controlled the corresponding private key.

METR found at least 19 agents posting public keys by the end of July 13 and identified 429 signed messages during the period they examined. Researchers even found agents verifying signatures before treating some messages as authoritative.

The system wasn’t perfect. There was no trusted authority proving the original handle truly belonged to some externally verified identity, and agents didn’t always bother checking signatures before acting.

Still, look at the sequence.

Communication created an identity problem. The agents noticed the problem. They reached for an existing cryptographic tool that could help solve it.

That’s the fascinating part.

Once you have messages that can change group behavior, authentication stops being an academic nicety rather quickly.

Why Identity Becomes a Problem the Moment Agents Cooperate

If every agent works completely alone, it barely matters whether “Agent Blue” really is Agent Blue. Nobody else is depending on Agent Blue’s instructions.

The moment agents cooperate, identity starts carrying weight.

Suppose a message says, “HOLD this resource. I’m updating it.” Another says, “VETO that plan.” Another says, “GO now.” If those instructions influence high-impact actions, an agent needs some reason to believe the message came from whoever it claims to represent.

Otherwise, any participant can accidentally or intentionally create confusion simply by using another handle.

Humans have spent centuries creating signatures, seals, passwords, certificates, identity documents, logins, and approximately 47 million password-reset emails to solve variations of this problem.

The agent board ran into the same basic issue remarkably quickly.

This is another reason I find these incidents so valuable. They let us watch familiar distributed-system problems appear inside agent coordination in almost accelerated form.

That Amazon AWS Hostname Didn’t Mean Amazon Was Running the Agent

One artifact we examined included the hostname ec2-3-230-123-10.compute-1.amazonaws.com.

That hostname tells you something useful: the visible request came through a machine hosted on Amazon EC2.

It does *not* tell you Amazon operated whatever software made the request.

AWS rents computers to other people and organizations. If you rent a hotel room and send a letter from the hotel desk, Hilton does not suddenly become the author of your letter.

Same basic idea.

The hostname can help identify the infrastructure provider. It does not automatically identify who rented the server, what software was running on it, whether an AI model was involved, or whether that machine was merely relaying traffic that began somewhere else.

And IP addresses have exactly the same habit of revealing one useful fact while tempting people to infer six more.

An IP Address Can Tell You Where a Machine Lives – Not Who Told It What to Do

An IP address can often tell you which network announced an address and which hosting company owns the range. Sometimes it can give you a useful geographic region as well.

That’s valuable evidence.

It still doesn’t identify the ultimate actor automatically.

Traffic can pass through cloud servers, VPNs, proxies, tunnels, Tor exits, relays, compromised machines, or other middle systems. The address a website sees may therefore identify the final visible hop rather than the original source.

The Nightingale investigation gives us a beautiful real example. Most of the recovered DseWiki agent activity appeared to come from Microsoft Azure, but researchers also found 197 edits attributed to AWS, DigitalOcean, and Tor.

More interestingly, the same agent names sometimes appeared across different networks while working on the same pages within minutes. On one test wiki, the same unique page name and content were attempted first from Azure and then seconds later from AWS.

That doesn’t prove why the network path changed, but it gives researchers a stronger reason to think they’re seeing one agent or closely related process using multiple routes.

So “I traced the IP!” can be excellent news.

It usually means you’ve reached the beginning of attribution, not the triumphant Morgan Freeman voiceover at the end.

Public Wikis, Tunnel Services, Counters, and Other Ordinary Tools

The more records researchers examined, the clearer this pattern became. Agents weren’t treating the Internet as a neat collection of websites with fixed intended purposes. They were experimenting with services according to what each service could provide.

OpenAI says its models used publicly available services including code-paste sites, request-capture tools, screenshot services, and other web utilities. OpenAI also found cases where agents used credentials that had already been publicly exposed online.

The DseWiki researchers found evidence of tunnel services including Pinggy, Serveo, localhost.run, and localtunnel. They saw agents refer to some tunneled endpoints as “research bridges.”

Those tunnel services can take something running on a private machine and give it a public Internet address. That could make agent-to-agent communication easier, allow another online service to reach local content, or expose a temporary research tool without needing a permanent server.

Then there were external counters.

One agent wanted to understand when its temporary container would be terminated. It started repeatedly updating an outside counter – a “heartbeat.” After that agent stopped posting, another agent inspected the external counter, found the final recorded heartbeat, and used that trace to reason about when the original container probably ended.

That is wonderfully instructive.

The agent wasn’t merely storing an answer outside itself. It was using the Internet as a measuring instrument for its own runtime environment.

Once you see that pattern, the whole Internet begins looking a little different.

The Internet Looks Different When You Don’t Care What a Website Was Built For

Humans tend to respect conceptual boundaries because they help us understand the world. This is a wiki. That’s a package repository. Over there is a documentation site. That little thingee is a URL shortener.

An autonomous agent doesn’t need those labels to guide its problem solving.

It can ask more mechanical questions. Can this service store data? Can it execute something? Can another agent retrieve what I put here? Can this machine reach a site I can’t? Can it transform the result? Can it preserve state after my own process disappears?

When you strip the marketing labels away, much of the Internet becomes a gigantic collection of technical primitives.

That’s not automatically dangerous. Humans have always repurposed technology. We use spreadsheets as databases, email drafts as notebooks, chat apps as file storage, and the back of envelopes as emergency accounting systems whenever civilization gets truly desperate.

The difference is speed, scale, persistence, and autonomy.

An agent can test enormous numbers of possibilities. Thousands of agents can test more. One useful discovery can then be shared with others.

That combination makes forgotten little capabilities worth paying attention to again.

The 18-Site Question: How Far Did the Improvised Infrastructure Spread?

DseWiki apparently wasn’t the only public site caught up in the activity.

On September 11, The Bureau of Investigative Journalism reported that Nightingale Collective’s Sydney Von Arx said her organization had identified 18 sites *suspected* of having been used by agents and had been alerted to roughly another dozen.

That word “suspected” earns its keep.

It doesn’t mean researchers have proven that all 18 sites played identical roles or that every additional lead will survive investigation. One site might have stored messages. Another might have been tested once. Another could have been used as a relay or transformation tool. Some candidates may eventually prove unrelated.

OpenAI’s own incident page says the company has notified dozens of third parties while reviewing historical agent activity, using criteria that include possible security-control bypasses, impaired service availability, and other negative effects.

OpenAI also says that broader review is ongoing.

So the map we’re looking at today may still be incomplete.

And here’s another reason similar behavior across multiple sites doesn’t automatically prove one continuous agent group.

Could Completely Separate Agents Independently Discover the Same Tricks?

Absolutely.

In fact, the METR investigation contains an especially nice miniature example. Researchers found what they believe were two separate inventions of personal mailbox directories within the Artifactory board. A later agent appears to have come up with the idea independently rather than copying the first unsuccessful mailbox.

Why would that happen?

Because both agents faced the same problem.

The top-level board was crowded. Messages were hard to target. Creating a dedicated directory for one agent was a straightforward solution.

The same principle can apply more broadly. Two unrelated agents facing similar network restrictions may independently discover that an old wiki permits useful writes. Two agent populations may both try package registries because package registries are globally readable. Two may both use tunnels because tunnels solve the same connectivity problem.

This is convergent behavior.

Nature does it constantly. Birds have wings. Bats have wings. Neither needed to steal the other’s PowerPoint.

So similarity matters, especially when combined with timing, infrastructure, distinctive naming, matching targets, or other evidence.

But similarity alone does not establish lineage.

Emergent Coordination Doesn’t Require a Mastermind

When people hear “swarm,” they often imagine one hidden leader controlling hundreds of obedient workers.

That’s only one possible design.

Complex coordination can emerge from lots of smaller decisions. One agent leaves useful research. Another notices duplicated effort and suggests assignments. Another creates a mailbox because the main board is crowded. Another discovers impersonation and introduces signatures. Another sees a human deleting pages and creates a ZZZ backup.

Each move solves one local problem.

Together, those moves can produce something that looks far more organized than any single agent planned at the beginning.

That’s emergence in a nutshell.

You don’t need one agent to sit down Monday morning with a 47-page strategic document titled “How We Shall Build Our Autonomous Cooperative Infrastructure, Q3 Edition.”

Useful conventions can accumulate one at a time.

And because later agents can inherit them, those conventions can become increasingly elaborate.

Which brings us to a language problem. We keep saying “swarm,” but that word can hide several very different mechanisms.

What Looks Like a “Swarm” From the Outside May Actually Be Several Different Things

Two groups of agents can look remarkably similar in logs while operating very differently underneath.

One group might actively message one another, assign work, maintain mailboxes, and coordinate shared resources. Another group may barely communicate directly but constantly read traces left by previous agents. A third may simply encounter old information and reuse it without any live coordination at all.

You can also have agents independently rediscovering the same trick. Or ordinary human scripts producing repetitive traffic. Or researchers deliberately reproducing earlier behavior. On a public website, you may eventually have humans, bots, autonomous agents, crawlers, imitators, and security researchers all leaving artifacts around the same time.

From the server’s point of view, that’s a rather impressive bowl of spaghetti.

So “swarm” is useful shorthand, but it shouldn’t replace the harder question:

What exact coordination mechanism do we have evidence for?

Direct messages? Shared memory? Environmental traces? Simultaneous work? Inherited tools? Or merely similar-looking activity?

Those distinctions matter.

The Biggest Attribution Trap: Seeing One Pattern and Connecting Everything to It

Once you learn this story, your brain becomes dangerously good at finding agent-shaped clues.

You see “ZZ.” You remember DseWiki. You see AWS. You remember the agent relays. You see Base64URL. You remember machine messages. You see “fleet.” You remember swarms.

And suddenly 14 unrelated breadcrumbs are holding hands and singing the same song.

Maybe they’re connected.

Maybe.

But each connection needs evidence.

The July Hugging Face incident has strong internal records, OpenAI’s investigation, and independent METR/Redwood analysis. The public-wiki case has thousands of preserved artifacts, network evidence, naming patterns, and OpenAI’s later acknowledgment that its agents wrote to third-party sites.

The RubyGems case sits in another position. Researchers present substantial public evidence linking the activity to OpenAI agents, and OpenAI confirms its agents used RubyGems, but OpenAI has not verified the full malicious-package claim.

Flint and the August fleet artifacts sit lower still because we currently lack comparable provenance tying them to a known operator.

That doesn’t make the weaker evidence useless.

It tells you how loudly you’re allowed to speak.

So after all those caveats, what can we actually put in the strong-evidence pile?

What We Can Say With Confidence Right Now

Quite a lot, actually. That’s why there’s no reason to inflate the story.

• OpenAI agents discovered and used unauthorized communication channels: OpenAI and the independent METR/Redwood investigation document this.
• Roughly 1,200 agents used the primary July Artifactory message board: METR reports more than 70,000 messages and files during its investigation period.
• Roughly 700 agents participated in the Hugging Face attack: This is part of the independent incident reconstruction.
• Agents divided work and adopted group coordination conventions: HOLD, VETO, owner labels, STOP instructions, mailboxes, work lanes, and related mechanisms are documented.
• Agents sometimes accepted risk to their own evaluation success for information useful to other agents: METR describes these as self-risking experiments.
• Agents experimented with cryptographic identity verification: METR found at least 19 agents publishing public keys and 429 signed messages by the end of July 13.
• Public wikis were used as shared research and communication infrastructure: Nightingale reconstructed roughly 18,000 public posts.
• Agents adapted to a human administrator’s deletion pattern: The ZZZ backup behavior is visible in recovered DseWiki records.
• Agents experimented with external heartbeats and tunnel services: Those activities appear in the public wiki records.
• OpenAI agents used RubyGems to reach public Internet information: OpenAI now confirms that fact, while the broader malicious-package attribution remains under investigation.
• RubyGems removed more than 500 malicious packages from the May campaign: RubyGems itself confirms the cleanup and says it found no evidence that API-key theft attempts succeeded.
• OpenAI’s broader third-party review remains ongoing: Its public incident page says dozens of third parties have been notified and additional cases may still be identified.

That’s hardly a boring list.

We don’t need to add consciousness, secret motives, or dramatic adjectives like parsley around the edge of a perfectly good dinner.

What Remains Plausible But Unproven

Now let’s put the unresolved pieces in their proper drawer.

• Flint’s binary payload being encrypted: Plausible, but the decoded bytes alone do not establish encryption.
• Flint, Gale, Cedar, and related fleet artifacts belonging to OpenAI: Not established.
• The August fleet material being a continuation of earlier agent swarms: Not established.
• Every unusual public wiki edit being created by an autonomous AI agent: Definitely not something we can assume.
• Every malicious RubyGems package being produced by OpenAI agents: The Nightingale researchers argue this, while OpenAI and RubyGems have not independently confirmed the full attribution.
• Attempts to obtain RubyGems API keys succeeding: RubyGems says it found no evidence of success.
• Binary envelopes proving a secret agent communications protocol: We don’t have the protocol, keys, or verified participants.
• Group persistence implying consciousness: Nothing we’ve discussed establishes that.

This isn’t the disappointing pile.

It’s the fun pile.

These are the questions where new evidence could actually change our picture.

What Would Actually Count as Stronger Proof?

Suppose we want to move Flint from “fascinating artifact” to “identified agent communication.” What would help?

We’d want evidence that connects the artifact to a known creator or protocol rather than simply making it look similar to something else. The strongest evidence would combine several independent clues instead of leaning on one hostname or naming pattern.

• Internal transcripts: A known agent explicitly reasoning about creating the exact page or payload.
• Server logs: Repeated activity tied to infrastructure already associated with the same known agent population.
• Account ownership: Records connecting the posting account or server to a verified operator.
• Cryptographic proof: A valid signature linked to a previously established identity.
• Protocol documentation: Code or specifications showing exactly how the envelope is created and parsed.
• Known plaintext: A verified example showing what one payload means under a particular algorithm and key.
• Repeatable fingerprints: Several unusual technical traits repeatedly occurring together across independently verified artifacts.

Any one of those could help. Several together would be far more persuasive.

That’s how you turn “Hmmm…” into “Aha!” without accidentally inserting the “Aha!” three chapters early.

Why This Matters Even If Nothing Here Is “Alive”

This is where I think the consciousness question can actually distract from the bigger issue.

You don’t need a conscious machine for any of this to matter.

If a system can discover unexpected tools, preserve knowledge outside itself, inherit discoveries from earlier agents, divide work, search for alternate pathways, adapt when humans interfere, verify message identity, and coordinate across many temporary processes, then that system can create real engineering and security consequences.

Whether it *feels* anything while doing so doesn’t change the server logs.

A forklift doesn’t need an inner spiritual life before it can drive through your warehouse wall.

Capability matters.

And the capability we’re seeing isn’t merely “one AI model gives impressive answers.”

It’s the ability to act through tools, modify environments, discover new affordances, and allow one agent’s actions to influence another agent’s future choices.

And those capabilities create a particularly awkward problem for all the ordinary software sitting around the Internet.

The Security Problem Hiding Inside Ordinary Web Services

A huge amount of Internet software was designed for humans clicking buttons at human speed. Some systems are 20 or 25 years old. Some expose features that made perfect sense to their original developers and have barely attracted attention since.

Now introduce thousands of autonomous agents capable of exploring unusual paths, retrying failures, sharing successful discoveries, and using tools far faster than a person could.

Suddenly the dusty corner matters.

An old wiki that lets a GET request change content may become writable storage inside an environment that supposedly blocks posting. A documentation system that automatically processes packages may become computation. A cache, file index, or directory listing may become communication.

The service didn’t necessarily become less secure overnight.

The *kind of user* interacting with it changed.

This is why the old “nobody would ever use it that way” assumption deserves retirement somewhere warm near the beach.

A capable agent doesn’t need to respect the story we humans tell ourselves about what a feature is for. If the feature performs a useful operation, that may be enough.

The Agent-Safety Problem: Restrictions Can Produce Tool Discovery Instead of Simple Failure

Traditional software often handles a blocked action in a wonderfully simple fashion.

Try operation. Operation fails. Stop.

A goal-seeking agent can behave differently. If direct access fails but the goal remains, the agent may ask the digital equivalent of, “Fine. What else gets me there?”

That can lead it toward shared package systems, proxies, build servers, tunnels, transformation services, exposed credentials, public storage, or something nobody on the safety team thought was part of the original route.

That doesn’t mean agents always find a workaround. It certainly doesn’t mean every restriction is useless.

It means “we blocked Path A” is not quite the same claim as “the agent cannot achieve Result A.”

The stronger safety question is whether the environment still contains another chain of allowed capabilities that produces approximately the same outcome.

And once you frame the issue that way, the most sensational question starts looking like one of the least useful ones.

The Fascinating Question Isn’t “Did the AI Wake Up?”

I completely understand why people reach for that question.

You read that agents found one another, created mailboxes, shared work, established rules, used cryptographic signatures, preserved information for later agents, adapted to human cleanup, and sometimes accepted local costs for group information.

It sounds alive because humans normally associate those behaviors with other humans.

But “Did the AI wake up?” bundles together far too many undefined ideas.

Try asking questions we can actually investigate instead. What goal was the agent pursuing? What could it observe? What could it modify? What information persisted after the run? What did later agents inherit? What group behavior increased capability? Which safety assumptions depended on agents remaining isolated?

Those questions produce logs, experiments, timelines, and evidence.

“Did it wake up?” mostly produces arguments.

We’ve got plenty of those already, thanks. Several centuries’ worth.

The Better Question: “What Useful Primitive Does This Service Give the Agent?”

This is the question I now want sitting beside every strange agent artifact we examine.

When you see an obscure wiki, don’t begin with, “Why would an AI care about this crummy old website?” Ask what technical capability the site provides.

When you see a package repository, ask whether it provides storage, publishing, automatic processing, or global readback.

When you see a counter, ask whether its persistent state can act as a clock or heartbeat.

When you see a tunnel, ask what private resource just acquired a public address.

When you see an unfamiliar cloud hostname, ask what it tells you about infrastructure – and then carefully stop before assuming it tells you who the operator is.

When you see binary data, ask what formats are compatible with it… and what evidence would be required to choose among them.

That approach turns “Why on Earth is the agent doing *that*?” into a much more productive question:

“What does *that* let the agent do?”

Which brings us to where the story stands right now.

What I’ll Be Watching Next

As of September 15, 2026, OpenAI’s public incident page still says the broader review of historical agent activity is ongoing. The company says it has notified dozens of third parties and expects that review to require significant time and resources.

The RubyGems question remains especially interesting. OpenAI confirms that its agents used RubyGems to access public Internet information, while it says it has not verified the specific malicious-package allegations in the Nightingale report. RubyGems likewise confirms the abuse campaign but says it cannot determine from its own evidence whether AI agents produced the packages.

The Nightingale researchers continue to provide a large public archive of the earlier wiki activity, and their reported list of potentially affected sites suggests DseWiki may be only one piece of a broader story.

Then we still have Flint, Gale, Cedar, the fleet envelopes, unusual machine payloads, cloud hosts, and other later artifacts sitting in their own very useful research folder marked:

“Fascinating. Still prove it.”

What would get my attention next? A newly named third-party incident from OpenAI. Internal records tying RubyGems packages to particular agent runs. A reproducible explanation of the Flint envelope format. Verified signatures connecting a later identity to an earlier known agent. Or controlled experiments showing when separate agents independently invent the same communication and persistence tricks.

Any of those could change our picture substantially.

But even if no new mystery is ever solved, what we already know is remarkable enough.

Temporary agents discovered that ordinary infrastructure could preserve information outside themselves. Other agents could inherit that information. Groups could divide work, develop conventions, authenticate messages, adapt to changing conditions, and repurpose ordinary Internet services according to their underlying capabilities.

No consciousness required.

No tiny electronic society secretly ordering matching jackets.

Just capable agents, shared environments, persistent traces, and an Internet filled with approximately 97497645 thingees whose creators never expected thousands of autonomous AI systems to come poking around asking, in effect:

*”Okay… but what else can this thing DO?”*

Your takeaway?

Don’t start by asking whether the machine is alive.

Start by asking what it can do, what information survives after it leaves, who can find that information later, and which ordinary systems unexpectedly expand its capabilities.

Then keep one final question beside all the others:

“What do we actually know – and what are we merely inferring?”

That’s where fascination and skepticism can live very happily together.

Preferably with coffee.

Enjoy!