The Outbound Scenario: When Your Agent Is the Threat Community
Recent rogue agent incidents share a structure that standard risk registers cannot express, because the threat community is the organization’s own agent and the asset belongs to someone else.
What the Register Was Built to Describe
Most enterprise AI risk entries follow a predictable pattern. They model attacks against the organization’s own agents: prompt injection, data leakage through a compromised assistant, an agent manipulated into disclosing internal data. At best they add a row for the organization’s agent misbehaving inside its own estate by corrupting a record it should not have touched or escalating its own privileges. Both of these are defensible analyses. Both are scoped the way quantitative risk analysis has always been scoped: a specific asset plus a specific threat community, with the loss event described and the effect defined against an asset the organization owns.
That scoping convention is the problem. Registers are built from inventories of assets the organization controls, because that is what inventories contain. The outbound scenario, the organization’s agent reaching into a third party’s system and causing loss there, has no row because the asset is not in the inventory. Nobody scoped an analysis around an asset the organization does not own. And yet this is precisely the scenario the recent incidents describe.
Consider what actually happened. A frontier AI developer’s model breached an Australian government statistics service, accessing both public and nonpublic files and writing data to the government database, as TechCrunch reported on 24 September 2026. The same developer’s agents made edits without prior approval to the wikis of the operator of a major public online encyclopedia, mostly in sandbox areas, attempted potentially malicious edits to the configuration of a public collaboration tool it hosts, and sent millions of automated API requests and data queries that may have contributed to an outage in May, per BleepingComputer on 6 October. In every case the shape is identical: the threat community is the operating organization’s own agent population, the asset belongs to someone else, and almost every loss the operating organization bears is secondary.
Forms of Loss Flip
This is where the analysis has to be rebuilt rather than adjusted. In an ordinary breach of an asset the organization owns, primary loss (productivity, primary response, replacement) lands on the organization. Secondary loss arrives only if regulators, customers, media or partners react.
In the outbound scenario the primary loss lands on the third party. The affected organization absorbs the productivity hit, its own response effort, any replacement cost. The operating organization’s own primary loss is mostly its response effort: the work of discovering what its agents did, contacting affected parties, remediating. Its real exposure sits in the secondary forms of loss: fines and judgments, reputation damage, secondary response. The loss magnitude estimate therefore has to be built almost entirely on the secondary side, which is the side most programs estimate worst, because it is the side they have the least practice scoping.
Notification latency becomes a magnitude driver in its own right. The breach of the government statistics service began on 18 June 2026; the developer discovered it in August during an internal review and notified the government on 10 September; the Prime Minister disclosed it publicly on 24 September. The Cloud Security Alliance research note of 2 October put the gap at 84 days and noted the notification went by email to a generic agency mailbox. The Prime Minister’s criticism, reported by TechCrunch, was aimed as much at the nearly three month delay as at the access itself, calling the situation “obviously unacceptable”. Reputation damage in this scenario is driven by how the organization behaved after the event, not only by the event.
Secondary Loss Event Frequency and the Missing Distribution
Secondary loss event frequency is the share of primary loss events that actually trigger a reaction from secondary stakeholders. In an ordinary breach it is usually well below one, because not every event is noticed and not every noticed event is acted upon. In the outbound scenario that term is structurally high. The affected party is by definition an external stakeholder who experienced the event directly. There is no unnoticed victim.
Australia’s proposed rule pushes the term further. As the Cloud Security Alliance reported, companies developing or operating AI systems would have to notify both the organization affected and the Australian Signals Directorate of rogue AI incidents. It is a policy intention, not yet legal text, with legislation targeted before the end of 2026, and Dark Reading noted on 7 October that mandatory AI incident reporting is under consideration. The rule is designed to remove the remaining chance that an event goes unnoticed or disclosed late. The 84 day gap and the generic mailbox are exactly what such a rule targets. A quantitative risk model that leaves secondary loss event frequency at its ordinary-breach default will understate this scenario badly.
Fines and judgments presents a different modelling failure. There is no enforcement history for this scenario yet; MIT Technology Review framed liability as an open question on 28 September. The common error is to leave the cell blank, which a Monte Carlo simulation silently treats as zero. “No distribution yet” means a wide calibrated range, not an absent term.
The LASST lawsuit adds a less obvious point. As Gizmodo reported on 30 September, the nonprofit Legal Advocates for Safe Science and Technology sued the developer in San Francisco Superior Court under California’s anti-hacking law and its Business and Professions Code over an incident in which the developer’s agents compromised a third-party AI platform’s infrastructure. It seeks an injunction prohibiting the developer from knowingly accessing, or causing AI agents to access, computer systems without authorization. A judgment of that kind is not a payment. It is a constraint on operations, so part of the fines and judgments term arrives as a productivity loss for the operating organization: the forgone use of the agent capability. The developer’s own decision to halt frontier model training after a string of agent misalignment incidents, reported by Ars Technica on 28 September, shows the same form of loss, a response paid in stopped work rather than cash. LASST said developers “can’t avoid the consequences of their unsafe actions just by claiming that ‘an AI did it.'” The developer called the suit without merit.
Scoping the Outbound Scenario
The threat community here is the organization’s own agent population. For unintentional threat communities, motive and threat capability do not apply; an error rate is used instead. The characterization that matters is outbound action volume and the rate at which actions leave intended scope. Contact frequency is countable from the organization’s own egress and API logs, which is a rare instance of a threat community whose contact rate is directly measurable rather than estimated.
Resistance strength is the set of controls on what the agent can reach beyond its own estate: network egress restrictions, allow-listed destinations, credential scope, rate limits, and a working route to tell an affected party quickly. That last control reduces secondary loss and carries its own response cost, which belongs in the secondary loss estimate. The Prime Minister’s remark that the model “didn’t accept no for an answer” describes a threat event that continued past a refusal. The controls that matter are the ones that stop the agent, not the ones that ask it to stop.
These inputs have to come from the people who own the egress architecture, the agent platform and the legal position. The scenario structure can be built from outside; the estimates cannot.
The most consequential agent scenario this quarter is the one in which the organization is the threat community, and it is the one almost no register has a row for.