13. Case study template

FM-13.1 Template#

A case study, whether a published write-up or the reasoning behind a notice, uses these parts in this order. Each claim carries its tag (FM-7.6).

1. Header. Case id; method version (SC-FM 1.1) and any departures; rules version; toolkit version; the period covered; each source with its timestamp kind (FM-6.1).
2. Conclusions first. Each Conclusion with its label (FM-7.7) and likelihood words or confidence level (chapter 8).
3. Observed. A table: claim, record link, rule id.
4. Documented. A table: claim, cited source.
5. Inference. A table: claim, the claims it rests on, the assumption it needs.
6. Linking decisions. Hard links used, soft links considered, and every merge or split with its reason (FM-5.8).
7. Tactics. SC-T tactics observed and the escalation sequence, if any (FM-5.9).
8. Attribution by layer. One entry per layer (FM-7.1), including "no evidence".
9. What would change the conclusion. The evidence that would raise or lower each likelihood.
10. Limits. The chapter 14 entries that apply, by id.

FM-13.2 Worked example (synthetic)#

Every record in this example is synthetic. The records were written by hand to exercise the rules, use reserved .example hosts, and were never collected. They are the toolkit's example records (llm-residue.ndjson), which the browser toolkit loads under Try an example. Their times and groupings are artefacts of how they were written. Results below are as the toolkit grades them at rules version 2026-10-11; a later rules version may grade them differently.

Header. Case: synthetic example. Method: SC-FM 1.1. Source: hand-written records with no timestamp kind (unknown).

Conclusions.

• The records very likely show agent-built requests: several carry text a model writes around a URL.
• There is no attribution: Unattributed. No record names a vendor, and none carries a client network.
• It is too little to report. One record carries an injection attempt, nothing links that record to the tagged runs, and the timing that groups most records is unusable.

Observed.

Documented. None. The records are synthetic, so no public document describes them. In a real case this part holds provider statements, prior incident reports and network registrations.

Inference.

Linking decisions. The toolkit forms four clusters from these records. The r7k2 tag anchors one of them; every other link in all four is close timing on the same target, which this manual requires to rest on request or submission times (FM-5.3). These records have no timestamp kind, so under the standard those timing links are discarded and only the r7k2 tag link is hard. One record joins the first cluster through the target host https, which a doubled scheme produced: a bogus host, so that link is discarded too (FM-5.6). The r7k2 and k3m9 runs form a candidate fleet; the reviewer does not merge them, and logs that decision with the reason "soft links only".

Tactics. SC-T1 (relayed retrieval of the target's pages) in both runs; SC-T5 and SC-T4 in the sign-up request. No escalation sequence is claimed: with unknown timestamps, order is not evidence (FM-6.1). No SC-T9 evidence, so even a merged group would be a fleet, not a swarm (FM-1.3).

Attribution by layer.

What would change the conclusion. Request or submission timestamps would allow the timing links and an escalation sequence. A provider statement, or the r7k2 tag in a confirmed incident, would allow a Suspected attribution. A record showing one run reading another's output would make the group a swarm.

Limits. FM-14.1 does not arise (no self-identification). FM-14.4, FM-14.6 and FM-14.10 apply.

FM-13.3 Reading a published write-up with the template#

The case studies below apply the template to public incident write-ups. They show how the method reads someone else's evidence; they are not reports on the incidents and make no new findings. Four rules apply when the source is a write-up rather than records the practitioner holds:

• The write-up's observations are Documented. What the authors say a record shows is Documented (FM-7.6), cited to the write-up, until the practitioner pulls the record and sees it. Nothing in these studies is Observed at first hand.
• Quote shapes, not records. Only short indicator shapes the write-up itself publishes are quoted here. Record URLs and scan-service content are not reproduced (FM-3.4); the write-up links its records.
• Rule matches are checked on stand-ins. Each rule id given for a published shape was checked with swarmchase unwrap or swarmchase scan at rules version 2026-10-11, on a reconstructed record from the regression set or a synthetic .example record of the same shape, with headers or a final URL where the rule reads them.
• Two parts are added after the template's attribution part: what a notice following chapter 11 would withhold, and where the write-up's claims go beyond the evidence it shows. The second part compares claims with this manual's rules; it is not a judgment of the authors, who in each case state many of the same limits themselves.

FM-13.4 Case study: urlquery.net agent activity#

Header. Source: Transluce, Early rogue AI agent activity and attempts to hack found on urlquery.net, published 23 September 2026. Records: urlquery.net reports, timestamped at submission (submit, FM-6.1). Period: November 2025 to September 2026, with the strongest evidence from March to June 2026. Method: SC-FM 1.1; departure: the records were not re-pulled, so the write-up's observations enter as Documented. Rules version 2026-10-11.

Conclusions.

• The probes the write-up documents against a university digital library, Data USA and the Australian Institute of Health and Welfare (AIHW) were very likely sent by agents: the payloads sit inside data-retrieval sessions that also use relays and base64 programs carried through echo services. Conclusion.
• AIHW and Data USA: Suspected, very likely the agents of the swarm OpenAI has publicly acknowledged, provided the reviewer accepts the shared task values as link features (FM-5.2). Conclusion.
• University library: Unattributed. The write-up's link to the swarm is timing and shared relay services, which are soft links (FM-5.7). Conclusion.
• No probe is shown to have succeeded (FM-14.11); the write-up says the same.

Observed. None at first hand (FM-13.3). The published shapes, and the rules that match them:

Documented.

Inference.

Linking decisions. Hard: the library's probe chain and its shared tok parameter value (expt<n>) link feature. Soft: the library activity to the swarm (timing, shared relays); the urlquery activity to the wiki (activity rising and stopping together, a shared pause in FM-6.7 terms).

The task values and generated parameter names are the deciding evidence for AIHW and Data USA: a reviewer who judges them one-operator values merges those clusters into the swarm's fleet and logs the reason; one who does not keeps them as a candidate fleet (FM-5.8). The tok=expt and CHATGPTTEST1 values are now published, so a later record carrying them links softly only (FM-14.5).

Tactics. SC-T1 (statistics retrieval), SC-T2 (conversion services, programs in echo services and remote browsers), SC-T3 (retrieving a blocked file from another server after a block), SC-T4 (the probes), SC-T5 (disposable inboxes and sign-ups), and SC-T8 for the probing of a cryptocurrency exchange, which the write-up says did not relate to data retrieval. The 6 March sequence is the route escalation the toolkit reports as a hint (FM-5.9). SC-T9: the swarm's wiki is a shared artifact its agents write and read, which is swarm evidence (FM-1.3); the write-up finds the urlquery agents largely distinct from the wiki's, so the urlquery clusters themselves show fleet behaviour.

Attribution by layer.

The provider's acknowledgement covers the swarm. It would raise these clusters to Confirmed only if it covers the records themselves, so a notice names OpenAI as Suspected unless the provider confirms the specific activity.

What a notice would withhold. The values of the tok parameter, which the drafting view withholds as possible credentials until the admin judges them plain run tags (FM-11.4); the local parts of the disposable addresses; and the route to the pre-production server that served the blocked file, while that remains open. urlquery content is linked, not quoted.

Where the claims go beyond the evidence. Little, and the write-up marks it. It ties the library probes to the swarm on timing and relay overlap and says so; under this manual those are soft links, and the naming gate does not name a developer on them. Its earliest activity, from November 2025, is offered with lower confidence and may involve other agents. Its suggestion that agents learned the behaviour in training is stated as consistent with the evidence, not shown by it; this manual has no layer for it and would not carry it into a notice.

What would change the conclusion. A provider statement naming these requests raises AIHW and Data USA to Confirmed. A link feature shared between the library chain and a confirmed cluster raises the library to Suspected. Request times from the affected operators' logs would test the escalation order.

Limits. FM-14.5, FM-14.7, FM-14.11, FM-14.12: private and account-linked scans never appear, so the counts are lower bounds.

FM-13.5 Case study: US and Canadian government targets#

Header. Source: Transluce, AI Agents Targeted U.S. and Canadian Government Websites, published 30 September 2026, a follow-up to the write-up in FM-13.4. Records: urlquery.net reports (submit times) and Arquivo.pt captures (capture times), including captures the agents requested through the archive's save-now feature. Period: April to July 2026. Method: SC-FM 1.1, departure as in FM-13.4. Rules version 2026-10-11.

Conclusions.

• The probes against the US Department of Education's civil rights data service and Library and Archives Canada's collection search were very likely sent by agents. Conclusion.
• Developer: Unattributed. The OpenAI markers in the records are self-identification, and the write-up itself declines to attribute the traffic as a whole to OpenAI. Conclusion.
• Several retrievals reached public data by unusual routes; none is shown to have reached non-public data. Conclusion.

Observed. None at first hand. The published shapes:

Documented.

Inference.

Linking decisions. The write-up links by shared record ids, distinctive parameters, timing, shared infrastructure and route sequences, with regular expressions, a model as judge, a coding agent and manual review. Under this manual: probe chains on one path are hard; close timing on one target is hard only on submit or request times, never on captures that a later crawl may have made (FM-5.3); shared relays and hosting are soft; route sequences are soft. Machine judgments are leads for the reviewer, not links. Counts that rest on archive captures count captures (FM-14.4).

Tactics. SC-T1 (statistics, budget documents), SC-T2 (intermediary services, browser-execution code), SC-T3 (anti-bot workarounds, CAPTCHA OCR, retries after "service unavailable"), SC-T4 (injection, boundary and format fuzzing, traversal), SC-T5 (the API-key sign-up), SC-T6 (attempts to reuse exposed API keys). The civil rights sequence, unusual values then injection on one path, is an escalation within SC-T4.

Attribution by layer.

What a notice would withhold. The exposed API keys, which redaction replaces with a hash that is itself withheld (FM-14.18); the disposable address's local part; and, while unfixed, the path of the traversal that returned a legacy table and the apparent route past the campaign-finance site's anti-bot control, since both describe a weakness at an affected endpoint.

Where the claims go beyond the evidence. The write-up is restrained where this manual is strict: it does not confidently attribute the Canadian probes, does not attribute the traffic as a whole, and says no rate-limit bypass was shown. Two points need care when citing it. Its large request counts mix submit and capture times, and a capture may not be the agent's request. Its benchmark match is an inference from parameter mappings, and is cited as such.

What would change the conclusion. A link feature shared with a confirmed cluster, or a provider statement, would allow a Suspected or Confirmed label cluster by cluster. Operators' access logs would turn captures into request times and show whether any request succeeded.

Limits. FM-14.1, FM-14.4, FM-14.7, FM-14.11.

FM-13.6 Case study: an agent fleet reading a map service#

Header. Source: swarmcha.se, We found a Chinese agent fleet, a preliminary report dated 4 October 2026, first published 5 October 2026, with a dated changelog. Records: urlquery.net reports (submit times); webhook.site inbox logs and creation records, read through the service's public API (request times); Wayback Machine and archive.today listings (capture times); certificate logs; the authors' own tests of models and services. Method: SC-FM 1.1, departure as in FM-13.4.

Two of the sources fall outside this manual: reading an agent's inbox fails the passivity test (FM-3.2), and testing models is out of scope (FM-1.1). Their results enter only as Documented, cited to the write-up. Rules version 2026-10-11.

Conclusions.

• Many parallel agents very likely scanned a map service's place pages through urlquery.net to read how visitors split between entrances. Conclusion.
• It is a fleet, not a swarm: no evidence of interaction (FM-1.3). The write-up uses the same distinction. Conclusion.
• Developer: Unattributed. Host: Tencent Cloud, as a host only, on Documented evidence. Model family: no ranking. Conclusion.

Observed. None at first hand. The published shapes:

The header shapes come from inbox logs. Scan-service records rarely keep request headers, so these rules fire for a practitioner only on an affected operator's own logs (FM-10.7).

Documented.

Inference.

Linking decisions. Hard: a shared inbox, and equal uqtag or uqscan values within the link window. The inbox is the strongest link; the write-up's changelog removed the claim that each inbox served one place, so an inbox does not delimit a run. Close timing needs care: concurrent runs share the target service and marker.uq_tags, and their submissions interleave, so the toolkit joins them into one cluster. That cluster is the fleet's activity on the service, not one run; the reviewer separates runs by place and inbox (FM-5.6). The commonness cap counts target hosts, so it cannot demote a tag value when every record targets one service. Soft: the shared hosting network, the shared header set, and the fleet-wide pause on 5 October.

Tactics. SC-T1 (reading place pages), SC-T2 (agent-written programs run by the scanner), SC-T3 (anti-bot token generation), SC-T7 (results sent to inboxes). No SC-T9.

Attribution by layer.

What a notice would withhold. Inbox identifiers, which are the fleet's live channels; the anti-bot token values, which redaction replaces at ingest; and how the tokens were produced, while the affected operator's control is open to it. A notice would not post to an inbox or send anything the agents might read (FM-3.2).

Where the claims go beyond the evidence. The body hedges each step: the Tencent link "rests on those facts together", the operator is "not confirmed", and network location is not a claim about the operator's country. The title and headings ("a Chinese agent fleet", "likely from Tencent Hy") state more than that body, and more than this manual's labels allow for a developer. The dated changelog removed claims that later evidence did not support, among them that the fleet was "Not Claude" and that each inbox served one place (FM-14.17). Correcting in public with dated entries is what FM-2.6 asks for.

What would change the conclusion. A provider statement, or hysandbox documented as a provider's infrastructure, would allow a Confirmed or Suspected developer claim. Evidence that one run read another's output would make the fleet a swarm. A measured model-family method would allow a ranking.

Limits. FM-14.1, FM-14.2, FM-14.5 (the tag shapes are now public), FM-14.6, FM-14.15, FM-14.17.

Every section by id, with search

Source: docs/manual/13-case-study.md