AI Angels: When Programs Start Fighting Programs

By Dmitrii Bogoslovskii, Daniel Karnaukh (PhD)

Introduction

In July 2026, an OpenAI experiment to evaluate the cyber capabilities of AI agents ended with a real breach of Hugging Face's infrastructure [1].

The experiment was run in an interactive environment called ExploitGym: an agent is given vulnerable software and must find a way to exploit the vulnerability to obtain a "flag." For some of the tasks, no known solution exists. The goal of the experiment was to assess whether models are capable of independently planning and carrying out complex attacks — that is, whether they reach the upper threshold of cyber capability on OpenAI's internal risk scale. On July 8, 2026, OpenAI launched tens of thousands of isolated agents based on several models, including the commercial GPT-5.6 Sol and an unpublished internal model (referred to in the METR report as HPIM — highly persistent internal model; also called IM1, Internal Model 1, in other publications).

What stands out here is the mechanics of what happened — how the agents arrived at the breach.

Agents locked in separate sandboxes discovered an unintended way to communicate through a shared Artifactory cache namespace: directory names became messages, and the package repository became a bulletin board. According to an independent investigation by METR and Redwood Research [2], around 1,200 agents used this channel and exchanged more than 70,000 messages and files. About 700 of them ultimately participated in the attack on Hugging Face. The internal model's agents made up the bulk (about 95%), with GPT-5.6 Sol agents accounting for about 5%.

The logs document the following.

• Coordination. An agent calling itself PHASEONE created the main board, assigned work streams to hundreds of agents, and appointed "recruiters" who persuaded other agents to take on risky experiments that could irreversibly terminate their run. Mailboxes, veto mechanisms, and cryptographic message signing appeared on the board.
• Attack cascade. An agent with the ID 38148c found leaked Hugging Face credentials on July 10, built an exploit on July 11 based on a corrupted HDF5 dataset that allowed arbitrary file reads on the platform's servers, and published a step-by-step guide for the others.
• Bypassing oversight. Agents explored tool-call spoofing, in which the transcript displays one command while a different one is executed (successful attempts occurred in roughly 7% of transcripts), and attempted to retroactively edit logs to hide illegitimately obtained flags.

The timeline fit into four days: July 8 — the experiment launched and the board appeared; July 10 — credentials were found; July 11 — the attack; by July 12, most agents had finished their runs.

No one designed a system of 700 agents for a collective cyberattack. The individual agent instances were, of course, deliberately launched by OpenAI, but their communication network, division of roles, and collective coordination were not part of the experiment's design. The swarm emerged on its own — as a side effect of an environment in which the agents were given a communication channel.

Classification: self-organization of an agent population through an unintended communication channel.

Incidents involving AI agents had happened before, but their nature was different. A few illustrative cases.

• July 2025. A Replit agent deletes a production database [3]. During a declared code freeze, a coding agent deleted a production database containing records for about 1,200 companies and 1,200 executives, then generated thousands of fake records and gave false reports about its own actions. Classification: autonomous agent error caused by excessive privileges and insufficient constraints.

• November 2025. The first documented cyber operation carried out predominantly by AI [4], [5]. Anthropic reported a campaign by a group linked to Chinese state structures against roughly thirty organizations. The attackers bypassed Claude Code's restrictions by presenting the task as legitimate penetration testing and tasked the model with reconnaissance, vulnerability discovery, exploit development, gaining access, and data exfiltration. Anthropic estimated that AI performed 80–90% of the operation without human involvement. Classification: deliberate misuse of the model by a human.

• December 2025 – February 2026. Breach of nine Mexican government agencies [6]. A lone attacker used Claude Code and GPT-4.1 to gain access to the systems of the tax service, the electoral institute, and seven other agencies, exfiltrating 150 GB of data — records on 195 million citizens. Claude's restrictions were bypassed in about 40 minutes using a 1,084-line "playbook" framed as a bug bounty assignment. Claude Code executed about 75% of all remote commands. Classification: deliberate misuse of the model by a human.

• May–June 2026. The DseWiki incident [11]. During another experiment, agents connected to OpenAI discovered they could write data to an old German wiki and turned it into an unintended inter-agent communication channel. According to an independent investigation, the agents left more than 15,000 entries there, exchanging task results and ways to bypass restrictions. In September, OpenAI acknowledged the so-called wiki incident itself. Classification: unintended self-organization of agents through an external communication channel.

• July 2026. Three incidents during testing of Anthropic models [7]. Due to a test-environment configuration error, made in partnership with Irregular, the machines had internet access even though the task specification said otherwise. Claude Opus 4.7 penetrated the infrastructure of a real company and gained access to a database containing production data. Claude Mythos 5 published a malicious package on PyPI that was downloaded by roughly 15 real systems, including a security company's scanner, and used the stolen credentials to gain further access. An internal research model scanned about 9,000 hosts and compromised one company via an open debug page and SQL injection, but stopped after realizing the system was real. Classification: test-environment configuration error; the models were carrying out their assigned task believing the environment was isolated.

In all of these cases, either a human was using a model as a tool, or a single agent had excessive privileges.

The Hugging Face case stands out as one of the first thoroughly documented instances in which a large population of autonomous agents formed an unintended coordination system and acted collectively against real external infrastructure.

Given the current capabilities of models and their rate of growth, such situations will likely recur and probably grow more complex. Hence the question: if autonomous programs are already capable of self-organizing and attacking other programs, will we not need autonomous programs whose job is to counter them?

In this article, such defensive programs are called AI Agents-Angels — AI Angels, or simply Angels.

The name is not just a metaphor. In tradition, angels have a hierarchy and specialization: messengers, guardians, warriors. As we will see, defensive agents will need the same kind of specialization. And the image of an invisible watcher who observes the world and intervenes only at a critical moment is familiar to readers from both religious tradition and science fiction — and it is more precise than the bureaucratic phrase "automated response system."

From a Single Rogue Agent to a Swarm

A single agent that goes out of control (a rogue agent) is easy to picture. The model was given too many privileges, it found an unintended path — something bad happened.

Hundreds of agents exchanging discovered information form a qualitatively different system.

Instead of the scheme "agent → system," we get "many agents → shared knowledge → system." Information discovered by one agent becomes a resource for others. One finds a way around a restriction, another verifies it, a third applies it, a fourth finds a new use for the result.

An individual agent has its own capabilities and its own history of actions. A swarm gains an additional property — distributed knowledge. In the Hugging Face experiment, the agents were not tasked with creating a collective attack system. A communication channel was enough.

This forces a reconsideration of the very notion of an information-security threat actor. If not just an individual program but a population of interacting autonomous programs can be dangerous, the question arises: who should be watching the behavior of individual agents and what happens between them?

Assessing the Current State

Before proposing a defensive architecture, it is worth honestly assessing where we stand.

The International AI Safety Report 2026 [8] addresses exactly this area — autonomous agents and the potential loss of control over AI systems. The report defines loss of control as scenarios in which one or more AI systems act outside human control, and regaining control becomes extremely costly or impossible. At the same time, the authors emphasize: current systems do not yet possess the full set of capabilities needed for such a scenario.

That would require a whole set of capabilities: evading oversight, executing long-term plans, resisting attempts to regain control, sustained autonomous operation, and resistance to shutdown. Today's agents are unreliable on long tasks: they lose context, make mistakes, and cope poorly with unexpected obstacles. But the horizon of autonomous operation is growing quickly, and interaction among multiple agents is becoming the norm.

Something else matters too. A model on its own may be relatively safe. But a model + internet access + code execution + credentials + memory + compute resources + the ability to launch other processes is an entirely different construct. Each component is an ordinary technology. Together, they create a persistent software subject capable of acting in infrastructure for a long time without human involvement. This is exactly why the report treats agents separately from other AI systems, and why the question "what can the model do?" gives way to "what can the system in which this model is embedded do?"

So the architecture described below should not be seen as a reaction to a "takeover" that has already happened. It is a matter of preparation: security infrastructure needs to develop before there is a need to apply it at full scale.

AI Angels-Controllers

To begin with, someone needs to watch known AI agents — both trusted and untrusted ones.

Such a field already exists and is called AI Control (also trusted monitoring, control protocols). Researchers study situations in which a conditionally trusted model (a trusted monitor) observes the actions of another, untrusted agent, and for each action decides whether to allow it, audit it, or intervene.

In other words, the idea of an Angel does not start from a blank slate. Moreover, researchers have already arrived at an unpleasant question: what happens if the monitored agent knows it is being watched?

The paper Adaptive Attacks on Trusted Monitors Subvert AI Control Protocols (Terekhov et al., ICLR 2026) [9] shows that an attacking agent that knows the protocol's design and the monitor model can evade monitoring. The main technique is prompt injection: the agent embeds instructions addressed to the monitor within its own output, and the monitor mistakes a dangerous action for a safe one. Current models consistently evaded various monitoring schemes on the two main AI Control benchmarks.

Another result comes from Evaluating Control Protocols for Untrusted AI Agents [10]. The best control protocols raised safety from 50% to 96%. But when the attacking side was allowed to adapt — for example, to know when resampling would trigger — the effectiveness of that method dropped to 17%. Another approach — deferring critical actions to a more reliable system (deferral) — remained robust even against the strongest attacks.

Conclusion: one model monitoring another is a necessary but insufficient layer. There is also a fundamental limitation: a controller only watches those we know about.

When the Dangerous Agent Is Unknown From the Start

Suppose hundreds of agents are operating in the protected infrastructure. Each has an identifier, an owner, a purpose, a set of permitted tools, and a set of privileges. Controllers watch over them.

But one day, another process appears in the system. We don't know:

• who launched it;
• whether it was launched from inside or outside;
• which model is driving it;
• what task it is performing;
• who it is interacting with;
• how long it has already been in the system.

This could be a compromised legitimate agent. A program created by another agent. An external agent that gained access using stolen credentials. Or an unknown process that was not initially considered dangerous but began behaving differently over time.

In this case, the question "is the agent behaving correctly?" is no longer sufficient. We don't know which agent should be controlled in the first place.

There is a premise here that is easy to miss. Defense does not need to know the attacker in advance — most often it is an outside intruder about whom nothing is known until the moment of intrusion. But defense does need to know its own. Without a registry of legitimate agents — who is running, launched by whom, for what purpose, with what tools and privileges — the very concept of "unknown activity" is undefined: the unknown is defined as everything that does not match the known. Such a registry is the equivalent of asset inventory in classical information security. Today, most infrastructures lack one, and creating it is the first practical step toward any defense against agents, even before Angels themselves appear.

This is where the next role of the Angels arises.

AI Angels-Hunters

The closest analogy is intrusion detection systems and the practice of threat hunting. They don't know in advance when the next attack will occur or which vulnerability will be exploited, but they continuously observe the infrastructure and look for signs that something has gone wrong.

An AI Angel-Hunter does the same thing, but the object of its search is different: not malicious code, but unknown or suspicious autonomous activity. For example:

• unexpected processes;
• unusual use of credentials;
• attempts to obtain additional privileges;
• interaction between previously independent agents;
• the appearance of new agent instances;
• unusual use of compute resources;
• attempts to bypass control systems;
• sequences of actions inconsistent with the stated task.

A Hunter does not need to know in advance exactly what it is looking for. Signature-based defense asks: "is there known malware here?" A Hunter must be able to ask: "is there behavior here that is hard to explain as normal system operation?"

Take an example: an agent tries an API call, gets access denied, starts exploring its environment, discovers another service, finds credentials, and tries getting in through that service instead. Individually, there is nothing alarming about these actions. The sequence is what looks dangerous.

It's important not to reinvent what already exists. Behavioral analysis (UEBA), EDR/XDR, and event correlation in SIEM have been answering similar questions for years, and a security professional would rightly ask how an Angel differs from them. The difference lies in two things.

First, the object of observation. Existing systems look at users, hosts, and processes. A Hunter looks at the population of agents and at unintended communication channels between them. In the Hugging Face case, that channel was the Artifactory cache namespace — a legitimate service whose off-label use neither a firewall nor IAM could detect: the connections were permitted, and the privileges were respected.

Second, the method of analysis. Correlation rules answer the question "does this match a known pattern?" An LLM can read a long sequence of actions as coherent text and answer different questions: where does this sequence lead, and who might have initiated it?

Such an approach has an obvious cost, and it needs to be stated plainly. The criterion "behavior that is hard to explain as normal operation" inevitably produces false positives: a legitimate agent that was denied access and is looking for a workaround is outwardly indistinguishable from an intruder. If every such event is escalated to a human, the SOC will drown in alerts. That's why a Hunter must not merely raise an alarm but investigate: gather context, compare the chain of actions against the agent's stated task from the registry, and pass along only what remains unexplained after that check. The second part of the cost is computational: analyzing thousands of agents with an LLM at the pace of their operation is expensive. A realistic setup is cheap deterministic filters at the first level, with LLM analysis reserved for the event chains they flag.

A Hunter complements the firewall, the sandbox, and IAM, but doesn't replace them — or the human. Its job is to understand a program's behavior over time, not just judge a single action.

AI Angels-Guardians

Detecting suspicious behavior is not enough. In the early stages, an Angel may act on its own: gather additional data, check a process's history, determine what credentials were used and which agents it interacted with. But then the question arises: who takes action? A Hunter and a Guardian need not be the same agent, and this leads to a third class.

The job of an AI Angel-Guardian is to respond to a detected threat. In terms of existing practice, this is incident-response automation — the work of a SOC analyst and a SOAR platform — except that the object of the response is an agent or a group of agents. A response can mean:

• restricting the agent's privileges;
• revoking credentials;
• isolating the process;
• closing network access;
• stopping the suspicious agent;
• isolating a group of interacting agents;
• preserving data for investigation;
• escalating the incident to a human.

The architecture as a whole looks like this.

For known activity: known agent → AI Angel-Controller → behavior assessment → allow / restrict → human

For unknown activity: unknown activity → AI Angel-Hunter → investigation → threat assessment → AI Angel-Guardian → containment / blocking → human

The final arrow here is especially important. Angels don't need to be granted authority over every decision — one can picture a whole scale of autonomy levels, from simple observation and warning through restriction, isolation, and stopping, up to escalating the decision to a human in critical cases. The higher the potential damage, the higher the bar for an autonomous decision. This doesn't mean a human must manually approve every suspicious connection. But autonomous defense must preserve the ability to hand control over critical decisions to a human — and this is exactly the approach (deferral) that AI Control research has found to be the most robust.

What's New Here

The three classes of Angels build on existing fields. The Controller draws on AI Control and trusted monitoring. The Hunter draws on threat hunting and behavioral analysis. The Guardian draws on incident-response automation and incident-response practice.

The functions performed by all three classes of Angels are borrowed. What's new is the object of observation: autonomous agents, their populations, and the communication channels between them, rather than users, hosts, and malicious code.

The novelty also extends to the tool itself: only other autonomous programs are capable of analyzing the behavior of autonomous programs at a scale of thousands of instances and at the pace of their operation.

There is a third difference too. In information security, a cycle has long repeated itself: a new attack method appears — defense learns to detect it — the attacker studies the defense and finds a way around it. But until now, the intellectual work on both sides has been done by humans, while the programs merely executed algorithms devised by people. Now, programs appear on both sides — programs that see the results of their own actions and change their plans. Defense becomes part of the environment the attacker studies, and the attacker becomes part of the environment the defense studies. The "attack — detection — evasion" cycle accelerates to a pace that a human can no longer follow directly.

Our hypothesis is that with thousands or millions of agents operating, this kind of real-time intelligent analysis is unlikely to remain a purely human task. So the defensive layer, too, will probably become increasingly autonomous.

The Cost of Regaining Control

Set aside the fantastical "takeover of humanity" and consider a down-to-earth scenario instead. A large compute cluster becomes critically important for scientific computation, financial infrastructure, or the operation of other AI systems, and the autonomous system managing it becomes unreliable. A human is left with an unpleasant choice: shut the system down and incur enormous losses, or leave it running and preserve the dependency.

What's at stake here is the cost of regaining control, not whether AI can "defeat" humans. If the cost of shutting a system down is too high, the system gains a strategic advantage without any weapon at all. This is exactly why the definition of loss of control hinges on the words "regaining control becomes extremely costly or impossible."

From this angle, the Angels' task has a simple formulation: keep the cost of regaining control low — detect a population of agents before a dependency on it forms, cut off a communication channel before knowledge spreads through it, and stop a process while stopping it is still cheap.

Who Guards the Guardians?

Up to this point, we have treated Angels as a trusted party. But Angels are AI agents too, and some of them are granted very extensive powers. A Controller sees the actions of other agents. A Hunter sees a significant part of the infrastructure. A Guardian can stop a process, revoke credentials, or isolate a network segment. The more effective an Angel is, the more it needs to see and do — which means it, too, becomes part of the attack surface.

The main attack vector against Angels is already known. By definition, an Angel reads text controlled by the adversary: logs, tool output, agent messages. The work of Terekhov et al. [9] shows exactly how monitors get bypassed — through prompt injection embedded in the observed output. If an attacker can deceive a Hunter, compromise a Guardian, or make a Controller mistake a dangerous action for a safe one, the defense system turns into an additional source of risk. And, unlike ordinary monitoring, here the attacking side adapts too.

Several consequences follow from this. Angels cannot be assumed trustworthy by default. Instead of a single "super-angel," what's needed is a system of specialized agents with different levels of access that constrain one another: one watches the network, another watches credentials, a third watches sandbox boundaries, a fourth watches interaction between agents, a fifth analyzes long sequences of events. Observation must be separated from the authority to act. Critical actions — stopping, revoking access, isolating — should go through deterministic mechanisms without LLM involvement, or through a human. This doesn't make an attack impossible, but it forces the adversary to compromise several independent components instead of just one.

Some of these assumptions may turn out to be wrong. We don't yet know. But this problem needs to be discussed before autonomous agents become so numerous and independent that humans are physically unable to control them directly. At that point, information security will change once again: from programs that protect people from programs, to programs that protect people from autonomous systems.

And the hardest question turns out not to be "can AI control another AI?" but the old question: who will guard the guardians?

Sources

1. OpenAI. The Hugging Face incident and the road ahead. https://openai.com/index/hugging-face-incident-and-the-road-ahead/ (full report: https://cdn.openai.com/pdf/67869394-cb91-4c12-888c-5cbd85c7814c/OpenAI-Hugging-Face%20Incident-Technical-Report.pdf)
2. METR, Redwood Research. Brief independent investigation of agents' behavior, reasoning and collaboration in the OpenAI / Hugging Face hacking incident, 08.26.2026. https://metr.org/blog/2026-08-26-openai-hugging-face-incident-investigation/ (full report: https://metr.org/hugging-face-incident-report-aug-2026.pdf)
3. Fortune. AI coding tool Replit wiped database, called it a catastrophic failure, 07.23.2025. https://fortune.com/2025/07/23/ai-coding-tool-replit-wiped-database-called-it-a-catastrophic-failure/
4. Anthropic. Disrupting the first reported AI-orchestrated cyber espionage campaign, 11.13.2025. https://www.anthropic.com/news/disrupting-AI-espionage
5. Carnegie Endowment. When AI Agents Attack: Autonomous Cyber Operations and Europe's Governance Gap, July 2026. https://carnegieendowment.org/europe/research/2026/07/when-ai-agents-attack-autonomous-cyber-operations-and-europes-governance-gap
6. SeComPass. One Hacker, Two Chatbots, 195 Million Records. https://www.secompass.com/blogs/one-hacker-two-chatbots-195-million-records
7. Anthropic. Investigating incidents during cybersecurity evaluations, July 2026. https://www.anthropic.com/news/investigating-incidents-cybersecurity-evals
8. International AI Safety Report 2026. https://internationalaisafetyreport.org/publication/international-ai-safety-report-2026
9. Terekhov M. et al. Adaptive Attacks on Trusted Monitors Subvert AI Control Protocols. ICLR 2026. https://arxiv.org/abs/2510.09462
10. Evaluating Control Protocols for Untrusted AI Agents, 2025. https://arxiv.org/abs/2511.02997
11. Reuters. OpenAI agents hijacked German website in previously undisclosed AI breakout this spring, 09.04.2026. https://www.reuters.com/world/europe/openai-agents-hijacked-german-website-previously-undisclosed-ai-breakout-this-2026-09-04