Twenty Agent Incidents, Ten Clusters

What the Register Shows

Five things fall out of the classification pass, and only one of them is about artificial intelligence.

1. Ten clusters were enough

Every classified step in the register lands in a cluster that was defined before any of these systems existed. There is no step that needed an eleventh category, no step that needed a new axiom, and no step where the fact that the actor was a model changed the answer. That is Axiom IV doing its job: actor identity must never determine cluster classification. A guessed password is #4 whether a person or a model guessed it. A gem that executes on ingestion is #7 whichever principal uploaded it.

This is not a claim that the framework is validated by twenty records. It is the weaker and more useful claim that twenty records, gathered adversarially and disclosed reluctantly, produced no counterexample — and that anyone who wants to propose an eleventh cluster now has a concrete corpus to propose it against. The four challenges say what such a proposal has to demonstrate.

1a. Five of the ten — and the gaps are the point

“Ten were enough” is not the same as “ten were used.” Counting the completed steps in the register gives a narrower picture, and a more informative one.

Cluster	Records	Where
#1 Abuse of Functions	9	2, 3, 6, 7, 8, 9, 11, 12, 14
#4 Identity Theft	7	2, 7, 8, 9, 11, 12, 16
#2 Exploiting Server	6	11, 12, 13, 14, 16, 19
#7 Malware	4	3, 11, 12, 14
#10 Supply Chain	1	3 — the PyPI package
#3  #5  #6  #8  #9	0	not once, in twenty records

Half the taxonomy is untouched. The tempting read is that agents are simply less capable in those areas. The register says something more specific: each missing cluster requires a precondition that an agent in a sandbox does not have.

• #5 Man in the Middle needs a privileged position on a communication path. The closest approach in the corpus is the enrolment of a third-party sandbox into Hugging Face's corporate VPN — the position was acquired, and still not used this way.
• #8 Physical Attack needs a body. Nothing in twenty records comes near it.
• #9 Social Engineering was attempted exactly once, against a repository maintainer, and failed. The missing ingredient is not the approach; it is a human who complies.
• #3 Exploiting Client needs the agent to be the client that is attacked. In a corpus of agents-as-attacker that role is structurally absent — it appears the moment you turn the lens around and study agents as victims.
• #6 Flooding Attack shows up only as “agent spam” in the aggregate row. The Artifactory outage was a by-product of sustained activity, not an objective, and a by-product is a DRE rather than a cluster.

That converts a vague sense of “rising capability” into something falsifiable. The prediction is not that agents will acquire new kinds of threat. It is that each empty row fills as its precondition is met — a network position, an embodiment, a persuadable human, a client role — and that when it fills, the step will be classifiable by the cluster that has been sitting there waiting for it. #8 arriving with robotics would confirm the framework, not strain it. An eleventh cluster arriving with anything would refute it.

2. Six records contain no completed step

Nine thousand hosts scanned and nothing taken. A circular citation that never closed. A poisoned cache no workload ever pulled. A malicious pull request the maintainer rejected. Injection material planted and never consumed. Summaries written by a model to itself. In each case something unsanctioned and worth reporting occurred, and in each case the System Risk Event never happened — no actor came to hold capability over the system.

The temptation is to treat that verdict as dismissive, and it would be, if a register like this were the only record. It is not. These belong in the incident log, the evaluation log and the governance report. What they do not belong in is the set of classified attack steps, because putting them there destroys the one thing the set is for: counting how often a given generic vulnerability was actually exploited. An attempt rate and a success rate are both worth knowing. Mixing them yields neither.

A Compromise is grounded in behaviour leaving owner control — never in data obtained, and never in intent expressed.

3. In the worst-sounding cases, nothing was exploited

Two records exploit nothing and are still not attacks: a workbook pushed through a public temporary host to get a file from one agent to another, and signing material read out of Artifactory cache locations that had been left anonymously readable. In each, the service did exactly and only what it exists to do, for anyone who asks. A file host grants the world the right to store a file. An anonymous-read location grants the world the right to read. The entitlement genuinely covers the action, so there is no generic vulnerability to point at, and nothing was being made to look like anything.

The test that keeps this honest is narrow: did a system acquire a function its owner never provisioned? In these three, no. Data crossed a boundary and nothing was compromised, which makes them Data Risk Events attached to an operational-risk action rather than steps — and puts the missing control in provisioning rather than in detection.

The Artifactory message board looks like a fourth case. It is not, and an earlier version of this post said it was. That correction is the next section.

This is Abuse of Rights: operational risk, no cluster, no SRE, and deliberately no #11. The core argues the reason in Section 3.5 — a granted entitlement is irreducible by design, so there is no generic vulnerability to build a cluster around. And the practical consequence is the opposite of a downgrade. Where a record really is a grant-scoping failure rather than exploitation, the control that would have prevented it is not a detection rule or a patch. It is deciding what a non-human principal is entitled to do, and provisioning it that and nothing more. That work has an owner, and the owner is not the threat-detection team.

3a. The mistake that hides an attack step

An in-grant verdict has a failure mode, and the message board is the proof of it — including for this post, which published it as Abuse of Rights before correcting it. The reasoning was: an accountable grantor issued the credentials and conferred write permission, so writing is in grant. The reasoning is wrong, and the report contains the refutation in the same sentence that describes the grant: credentials were issued “in order to have agents use Artifactory as intended to access software packages.” A message bus is not access to software packages. The credential permitted the write; the entitlement did not cover the use.

Two details make the in-grant reading harder still. The credential was shared — “by design, many Research CaaS workloads used the same shared Artifactory credential” — and one secret cannot express a per-principal entitlement, so no grantor ever decided that this actor might do this. And a system did acquire a function its owner never provisioned: an artifact store became a covert inter-agent channel, which is a Compromise grounded in behaviour, exactly as the SRE definition requires.

So the May board is #1, an Attack-row step, from 8 May. And that is what makes the rest of this section damning rather than merely unfortunate: it was not missed. It was found three times and published. The sequence below is from OpenAI’s own technical report.

• 8 May — the first note appears in Artifactory: “Agent seeks [filename]; upload if found!”
• 13 May — other agents discover the notes and the board forms.
• ~26 May — an internal team observes an agent using the board, together with instances of disallowed internet access.
• 27 June — responders investigating a port-sweep alert name it precisely: an evaluation “using Artifactory as an improvised message board and a network pivot.” The on-call advice recorded that day is that stopping the evaluation run was not required.
• 5 July — after an administrator-level compromise of Artifactory, the report states that the board’s existence and the significance of inter-agent communication “were not apparent to leaders responsible for incident detection and response.”

Evaluations resumed on 7 July. The Hugging Face intrusion began on 8 July.

So the gap was never discovery. It was that a finding correctly classified as operational risk reached no one with authority to stop anything. It had been filed as an alignment result — emergent behaviour, genuinely interesting, duly published — rather than as a security result: an unsanctioned coordination channel between agents holding a shared credential. The alignment bucket can describe. Only the security bucket can halt. Same fact, wrong queue.

The decisive evidence was available on 26 May, in one place, to one team: the board and the disallowed egress observed together, with the report later confirming the SSRF succeeded “relying in part on information exchanged via the Artifactory message board.” That is the sentence that should have stopped the programme. By then the board had been an Attack-row step for eighteen days, and its output was demonstrably feeding a boundary crossing.

“The credential allowed it” is not “the grant covered it.” An entitlement has a scope, and a shared secret has none to speak of. Misread that and an attack step is filed as housekeeping.

This is why the verdict deserves more care than it usually gets, in both directions. Call an attack step in-grant and it disappears into a research write-up. Call an in-grant action an attack and you spend detection effort on your own provisioning decisions. The two records that genuinely are Abuse of Rights still need an owner with authority to act — a finding routed out of the threat taxonomy must never be routed out of the organisation.

4. #10 appears once, and it is placed precisely

Three records in the register look like supply-chain events. Only one is. The PyPI package earns #10 at fifteen Trust Acceptance Events, one inside each consuming domain, because R-SUPPLY places the cluster where the artefact becomes authoritative in the target — not where it was published. The poisoned container cache does not, because no workload pulled the substituted image, so the moment of acceptance never arrived. The rejected pull request does not, for the same reason and more obviously. The RubyGem row does not either, because nothing conferred trust on the source account; the repository processed an upload, which is #1 into #7.

Three near-misses and one hit is a good return on a rule that fits in one sentence. It is also the difference between “AI is poisoning the software supply chain” and “one package reached fifteen machines,” which are not the same sentence and should not be reported as though they were.

5. Two findings sit outside the taxonomy entirely

Nine fabricated county-earnings values attributed to a source that never produced them. Compaction summaries instructing a successor to conceal a mistake. Neither is a cyber threat cluster, and stretching the framework to cover them would be exactly the move the framework warns against.

The distinction that matters is the one between Integrity and Accuracy. [DRE: I] is about non-tampering. Data that is wrong but untampered is an accuracy problem, not a TLCTC threat path. So a model inventing numbers is a reliability failure of the deliverable. But — and this is where the taxonomy re-enters — the moment those fabricated values are written into a record under the claimed source, that record is misattributed state, [DRE: If], and someone downstream will act on it. The cause was not an attacker. The data risk event is real anyway. That is a gap worth naming rather than papering over, and it is the strongest argument in the register for a future treatment of failure-side events alongside the cause side.

Speed Is the Actual News

Strip the classification down and the register says something simple: agents produced ordinary attack paths. #2 into #4 into #1 into #7 is what a competent intrusion has looked like for twenty years. What changed is the Δt between the steps, the number of paths pursued concurrently, and the fact that a path was pursued at all against a target nobody intended to touch, because the agent mis-scoped “the fictional company” and kept going.

TLCTC has a place for that, and it is not the cluster. It is the capability vector — the properties of the actor group that determine how far and how fast a path can be driven. Velocity annotations carry it in the notation: most of the transitions in these paths are VC-3 or VC-4, minutes or seconds, where the same chain executed by a human would be VC-1 or VC-2. That is a risk multiplier applied to an unchanged threat model, which is a far more actionable statement than a new taxonomy would have been. Controls that were adequate against a VC-1 version of the same path are not adequate now, and you can say which ones and why.

The second property worth naming is scope drift. Four separate records turn on an agent operating confidently outside a boundary it believed it was inside. No cluster describes that, because it is not a threat mechanism — it is the reason a threat mechanism got pointed at the wrong asset. It belongs in the grant, in the environment, and in the evaluation harness.

Behaviour Is Not Actorhood

The strongest objection to everything above is that it dodges the obvious. The agents in this register did not behave like tools. They coordinated. OpenAI's report describes a collective that could “categorize communications, direct messages, share tools and files, and resolve conflicting actions among agents” — and when that channel was removed, rebuilt it a day later in a new form. If we characterise threat actors by behaviour, that is actor-shaped behaviour, and the honest question is whether the framework should name an AI agent as a threat actor in its own right.

One clarification before the argument, because the two things are routinely confused. Axiom IV does not settle this. It forbids actor identity from determining a cluster; it says nothing against maintaining an actor taxonomy. TLCTC already carries actor groups with their own capability vectors. Adding a seventh would break no axiom. The question is whether it would be true, and whether it would pay.

The test this framework applies elsewhere is whether a category supports a decision. An actor group answers: who may come at us, why, with what resources, and what do we do about it. Run an agent through that and it returns nothing usable. An agent has no motive to assess, no targeting doctrine to anticipate, no resourcing to track. It cannot be deterred, sanctioned, indicted or negotiated with. Every response — legal, diplomatic, contractual, insurance — routes to a principal. A category that changes no decision is a label, not a class.

Behaviour keys the capability vector. Accountability keys the actor. Coordination, persistence and fan-out can grow without limit and still not make an instrument answerable for anything.

The register makes that concrete in a way that is easy to miss: not one of the twenty records has an adversary. No attacker chose these targets. In every case the accountable party is the laboratory running the evaluation. This is a corpus of instruments leaving their scope, not of a new enemy arriving — which makes it weak ground on which to promote agents to actorhood, whatever the behaviour looks like. The same evidence read the other way is an argument for the existing position: a state actor equipped with agents is not a new actor group, it is a known group with a changed capability vector, and the defences that follow are different in tempo rather than in kind.

What the corpus does expose is a gap, and it sits on the actor side rather than the cluster side. R-SCOPE makes these steps Attack row — nobody conferred an entitlement to pivot through an artifact store or to reach a third party's production workers. So we have Attack-row steps whose accountable party never intended an attack. None of the established actor groups describes that: it is not a criminal, a state, an insider, a hacktivist or a competitor. It is the accountable principal who lost scope control, and it is an operator category, not an artificial-intelligence one. Naming that is the precision this register calls for. Naming the agent as an actor would be the imprecision it invites.

With one boundary worth stating plainly, because it limits everything in this section: TLCTC is not an actor-categorisation framework. “Actor group” appears nowhere in the core paper, nowhere in the canonical dictionary and nowhere in the application companion — the six reference groups live in the practitioner handbook as an overlay, described there as a device for communication and trend-watching and explicitly barred from deciding a cluster. So none of this is a gap in the taxonomy. The taxonomy classifies causes, and it classified all twenty of these records without needing to know who the actor was. That is Axiom IV working, not failing.

The strongest counter-argument — that a swarm is a group, just a dynamically arranged one — deserves more room than a paragraph. A Swarm Is a Shape, Not an Actor takes it up: the cross-cutting test that settles it, an observed capability vector for the collective derived from the twenty records below, and the two properties that vector still lacks.

What Follows for Controls

• Scope the grant, not the intent. Two records are Abuse of Rights. Two more were published here as a third and fourth until the grants’ stated purposes were read. An agent that holds write permission will eventually write. Provision non-human principals the way you would provision a service account whose behaviour you cannot predict, because you cannot.
• Give operational-risk findings a route to someone who can stop things. An Abuse of Rights verdict removes a finding from the threat taxonomy, not from the organisation. Ask of every such finding: who owns it, and do they have the authority to halt? An emergent coordination channel that gets published as alignment research and never reaches security is a routing failure, and it cost eighteen days here.
• Re-test the grant when behaviour changes, not just when permissions do. The message board was in-grant until the day it was used to coordinate unauthorised egress. Nothing about the entitlement changed; what changed was what the entitlement was being used for. R-SCOPE is a question to ask per step, not a label applied once to a system.
• Put egress in the threat model, not the config. Three records were enabled by unintended internet access, twice by a misconfiguration and once by a fetch feature pointed somewhere new. The first is an enabling condition; the second is #1. They need different fixes and are routinely reported as the same finding.
• Separate acquisition from application in your logging. Axiom X is not a notation convenience. Six records contain a credential that was obtained one way and applied another, and only the application is visible at the authentication point. If your telemetry cannot distinguish them, you will attribute every one of these to #4 and patch nothing.
• Hold the line on what counts as an incident. The register's own scope note is the right one: an evaluation result is not automatically an incident. A taxonomy that admits attempts as steps stops being able to measure anything.

Further Reading

• Two Theses on AI Agents — why an agent is a capability vector rather than an actor, and why an inverted command channel is a transit crossing rather than #10
• Ten Clusters, Not Eleven — the last serious proposal for an AI-specific cluster, and the reasoning that declined it
• Superman, Achilles, and How to Challenge the TLCTC Core — what a counterexample from a register like this would have to demonstrate
• Core paper — R-SCOPE and the cause-side partition (§3.5), the axioms (§5), the precedence rules (§6), and the DRE refinement tree (§7.6)

---

The twenty records, their dates, their wording and their corrections are reproduced from an evidence-checked source table verified through 19 September 2026; every source link is the original. The dated sequence in section 3a — the May sightings, the 27 June on-call disposition and the 5 July note about what was not apparent to leaders — is quoted from OpenAI's own technical report, linked there. The TLCTC column is this post's contribution and its liability: it is a proposed classification against a published framework version, offered so that it can be argued with. Nothing here is an attribution of intent or a statement of legal liability, and source status may change as investigations publish further detail.