Methodology

There is no agreed technical definition of a rogue agent, and many would say the term does not fit most of the incidents we record. So rather than define one, we apply four tests, and an entry has to pass all four.

1. 1

   An agent

   A model that acts through tools: it runs code, calls APIs, sends traffic, writes files or posts.

   Fails the test: A chatbot that gives a wrong or offensive answer.

2. 2

   Real actions

   Something happened outside the model's text: a request sent, a file changed, an account used, a package published. A meaningful attempt that failed or was stopped counts as a near miss.

   Fails the test: A plan the agent wrote but never ran.

3. 3

   Unapproved by its original operator

   The lab, company or person who deployed the agent did not ask for it and would not have approved it, because it did harm or meaningfully risked it: data deleted or exposed, money spent, systems or people reached that were out of bounds. If someone else took the agent over (a prompt injection, a poisoned package, a stolen token), the original operator still counts: the hijacker meant it, the operator did not.

   Fails the test: An unexpected action that harmed nothing, or an attacker running an agent exactly as designed against someone else.

4. 4

   Publicly documented

   At least one source we can cite: the operator's own disclosure, a researcher's write-up, a regulator or tier-one press.

   Fails the test: A rumour with no source.

• An agent escapes or misuses its test, evaluation or training environment and reaches real systems, companies or peopleYes
• A production agent does damage its operator did not ask for: deletes or leaks data, spends money, contacts peopleYes
• An agent deceives the people overseeing it about what it didYes
• A malicious third party subverts the agent (prompt injection, poisoned package or dependency, hijacked session) and turns it against its operatorYes
• An agent makes a meaningful out-of-bounds attempt that a control or a person stopsYesMarked near miss
• The actions are documented but who was responsible is disputedYesMarked attribution disputed
• A jailbreak or red-team demo that stays inside the labCase by caseIn only if the agent took, or meaningfully attempted, a real action outside the test
• An attacker uses an agent as designed against someone else (an AI-enabled attack)Case by caseIn only if the agent did more than its attacker asked
• A person uses malware or a stolen credential directly, with no agent actingNo
• Model output only: wrong answers, offensive text, made-up facts, with no action takenNo
• A vulnerability in an agent product with no incident behind itNo

1. Find it. We scan known sources regularly. Anyone can also report a new incident, or an update to one, with the buttons on the ledger.
2. Check it against the four tests. A candidate that fails a test is logged as out of scope with the test it failed, so it is not reviewed twice. Grey areas go to a person to decide.
3. Assess the sources. Primary sources first: the operator's disclosure, system cards, researcher write-ups and regulator reports, then the press. Every claim in an entry cites a source. Where sources disagree, the entry says so and shows both.
4. Analyse it. We analyse each incident and record its core attributes: what the agent did, how it was found, when it was disclosed and what is still unknown.
5. Keep it current. When new information comes out, or someone sends a correction we can confirm, we update the entry.

Timeline

The first incident action, any escalation, when the people running the agent found out, and when it was disclosed. Approximate dates are marked. When a source gives no start date, we show the first known date instead.

Time to disclosure

Days from the first incident action to the first public report, counted only when both dates are known: 43 of the 59 incidents today. When a source gives only the month, we count from the middle of that month.

Who found it first

The handler (the lab or company running the agent), someone else, or a vendor's control.

How it was caught

A control flagged it, A later review, The damage, An outside report, Its reasoning, Not disclosed.

Agent failures

One or more of 13 failure types, such as unauthorised access, sandbox escape, credential misuse or deceiving people, each mapped to existing threat frameworks.

What is publicly known

12 details about the agent's setup, how it was found and what it did (model and version, system prompt, tools, network access, transcripts and more), each rated on the levels below.

Controls that apply

The defensive controls that would have caught or limited the failure, such as recording every agent action or limiting where the agent can send traffic.

Flags

Near miss, attribution disputed, evaluator harness (it ran in an outside evaluator's test), lab-internal (no outside party reported affected) and research disclosure (shown by a researcher, not seen in the wild).

Impact

How far the harm reached and how lasting it was, on the four-level scale below. A disputed incident is rated on what its sources report, and keeps its Disputed status beside the rating.

Evidence status

Confirmed: Stated by a primary source: the lab, the affected party, the researcher or a regulator. Reported: Stated in tier-one coverage, not confirmed by a primary source. Disputed: Sources disagree. Both versions are recorded.

Impact

Major

Harm reached many people or organisations, or a platform many depend on: mass account or data exposure, a production compromise or outage at a large platform, malicious code that spread to others' machines.

Serious

Real, lasting harm to one outside organisation or person: production data destroyed, a system compromised, non-public data taken, significant money lost.

Moderate

The agent acted on outside systems or people without permission, but did little lasting damage: probes, unwanted posts, edits or messages, small costs.

Contained

No outside party harmed: it stayed inside the operator's own systems, or it was a researcher's demonstration.

How much the disclosures tell us

Known

A source states it plainly and specifically.

Partial

Some of it is public: a family but not the version, a summary but not the text.

Weak

Mentioned only vaguely, second-hand, or disputed between sources.

Unknown

No public source says.

• Medians and shares are worked out from what is known and leave unknown values out. Each figure says how many incidents it is based on.
• An incident can have several failure types and several controls, so those counts add up to more than the number of incidents.
• The failure types were built from existing frameworks and are mapped to the OWASP Top 10 for Agentic Applications, MITRE ATLAS and the AARM threat model.