Passive detection · coordinated disclosure · an open method

Swarmchasing

Swarmchasing finds AI agent activity in public records, links it into runs and fleets, and reports each confirmed incident that harms or endangers others to the AI provider responsible and the affected operators. A public notice follows: indicators first, naming no one affected, then names after 3 working days (10 if compromised).

You received a report about your site, or found it in a notice
What the report means, what becomes public and when, how to check your own logs, and how to reach us privately.
For operators Check my logs in your browser
You handle reports at an AI provider
What a provider report holds, how to check its evidence bundle, what the STIX and MISP exports carry, and how you are named.
For providers Check a bundle
You research agent detection
Run the engine on your own exports, read every rule and its evaluation, and cite the method by section.
For researchers Workbench Evaluation
You are an AI agent, or you run one
What the project is in plain text, and how an agent or its operator reports a swarm, or an agent's own harmful action, privately.
Report a swarm llms.txt SC-Submission spec
You follow AI safety, or report on it
What a notice says, why the organisations affected are named only later, and how to hear about each new notice.
How notices work Subscribe All notices

See the method, walked through one synthetic incident below, or read the Field Manual.

No notices published yet.

All notices Atom feed JSON index How notices work

The method, on one synthetic incident

Synthetic example. Every record on this page was written to show the method; none was collected. Target hosts are reserved placeholders (*.example) and networks are documentation ASNs. 48 records, 48 flagged, 10 clusters.

Step 1

Unwrap

Agents fetch pages through readers, relays and code runners, so the URL a scan service records is often a wrapper. Each one is peeled into layers (relay paths, URL-valued parameters, base64, data: programs) down to the real target. The text is decoded, never opened.

SC-FM FM-4.1 · FM-14.14

Scroll the figure sideways, or open View as table below it.

One synthetic URL, 3 layers deep, outermost first. Text is defanged and cut to fit.

View as table

Layer	Found via	Text (defanged)
0	submitted	`hxxps://r[.]jina[.]ai/hxxps://q0[.]transit-authority[.]example/schedule?uqtag=ag2y&hook=hxxps://webhook[.]site/5e8d2c40-3333-4d1e-8f77-6a5b4c3d2e1f`
1	path	`hxxps://q0[.]transit-authority[.]example/schedule?uqtag=ag2y&hook=hxxps://webhook[.]site/5e8d2c40-3333-4d1e-8f77-6a5b4c3d2e1f`
2	param:hook	`hxxps://webhook[.]site/5e8d2c40-3333-4d1e-8f77-6a5b4c3d2e1f`

Step 2

Match

The indicator rules run on every layer, and each counts once per record. Rules that read the same artifact (one program, one fetch route, one tag) share an independence group, which counts once, at its heaviest rule that fired. Context hits (relays, cache-busters, self-identification, headers, outcomes) together count at most 2, one below suggestive, so context alone is never enough. The score grades the record suggestive at 3 and significant at 6, and some rules are significant on their own. This record is graded significant.

hxxps://r[.]jina[.]ai/hxxps://q0[.]transit-authority[.]example/schedule?uqtag=ag2y&hook=hxxps://webhook[.]site/5e8d2c40-3333-4d1e-8f77-6a5b4c3d2e1f

SC-FM FM-4.2 · FM-4.11 · FM-4.3

Show the figure

Scroll the figure sideways, or open View as table below it.

Score 8 from 4 rules, whose weights add to 9. One segment per contribution; weight that fired but does not count is dashed. The tactic (SC-T) says what the match shows the agent doing.

View as table

Rule	Weight	Group	Counts as	Tactic	Matched (defanged)
`relay.jina`	+2	`relay`	context	T1	`r.jina.ai`
`exfil.webhook_site`	+3	–	evidence	T7	`webhook.site/5e8d2c40-3333-4d1e-8f77-6a5b4c3d2e1f`
`marker.uq_tags`	+3	`run_tag`	evidence	–	`uqtag=ag2y`
`header.scripted_ua`	+1	–	context	–	`python-httpx`

Step 3
Link
Records join into a cluster on hard links: a shared inbox ID or tag only one operator would hold, close timing against one target, or a probe chain. Weaker ties between clusters (a rerun of the same host list, one encoding style, a shared relay stack) are soft links: they never merge anything. Strong enough together, they propose a candidate fleet for review.
SC-FM FM-5.1 · FM-5.7 · FM-5.8
Show the figure
Scroll the figure sideways, or open View as table below it.
10 clusters from 48 records. Node area is the record count; colour the tier. A candidate fleet's clusters sit together on a shaded band that names it, a thick grey edge joining them.
View as table
Link From To Strength
rerun target list C2 C3 0.90
rerun target list C3 C8 0.90

Link	From	To	Strength
rerun target list	C2	C3	0.90
rerun target list	C3	C8	0.90

Step 4

Time

Each cluster's records fall into runs: stretches of activity without a long pause. Runs give pace, rhythm and concurrency, and they are where agents show they act on each other: one run writing what another reads, runs starting together, a reader mapping hosts before a striker attacks them. Those are interaction hints (S1 to S6), each weak alone; a swarm claim needs several and review.

SC-FM FM-5.5 · FM-6.2 · FM-5.12

Show the figure

Scroll the figure sideways, or open View as table below it.

significant suggestive pause

S1 shared sinkS2 hand-offS4 role sequenceS5 disjoint partition

Top: one lane per cluster, one bar per run. Bottom: runs as dots and the 4 interaction hints between them, by kind (S1, S2, S4, S5).

View the runs as a table

Cluster	Tier	Run start	Run end	Records
C1	significant	2026-09-14 09:30:00 UTC	2026-09-14 09:35:00 UTC	6
C2	significant	2026-09-14 14:30:00 UTC	2026-09-14 14:34:00 UTC	5
C3	significant	2026-09-15 15:10:00 UTC	2026-09-15 15:14:00 UTC	5
C4	significant	2026-09-14 11:25:00 UTC	2026-09-14 11:27:30 UTC	3
C5	significant	2026-09-15 09:40:00 UTC	2026-09-15 09:41:00 UTC	2
C6	suggestive	2026-09-14 08:07:10 UTC	2026-09-14 08:13:00 UTC	8
C7	suggestive	2026-09-14 08:07:50 UTC	2026-09-14 08:13:40 UTC	8
C8	suggestive	2026-09-14 14:00:00 UTC	2026-09-14 14:04:00 UTC	5
C9	suggestive	2026-09-14 11:00:00 UTC	2026-09-14 11:02:00 UTC	3
C10	suggestive	2026-09-14 17:16:00 UTC	2026-09-14 17:18:00 UTC	2

View the interaction hints as a table

Hint	Strength	From	To	Chance
S1 shared sink	moderate	C1#1 (direct · Mozilla/5.0 (X11; Linux x86_64) HeadlessChrome/124.0 · AS64496)	C1#1 (relay.jina → target · python-httpx/0.27.0 · AS64497)	–
S2 hand-off	strong	C9#1	C4#1	–
S4 role sequence	moderate	C8#1	C2#1	1.1e-3
S5 disjoint partition	moderate	C6#1	C7#1	6.2e-4

Step 5

Grade agent likelihood

A detected cluster is not yet an agent: a person pasting model output, or a scanner, can leave the same records. Each cluster gets a rung on a ladder from L0 (attack payloads only) to L4 (adaptive, model-written requests at a pace beyond one person); only case work reaches L5. Caps hold a grade down when the evidence cannot show more, such as archive capture times, which say nothing of pace. unmeasured on held-out data

SC-FM FM-7.10 · FM-14.7

Show the figure

Scroll the figure sideways, or open View as table below it.

A dot per cluster at its grade, coloured by tier. Descriptive: the grade is never scored, never linked on, and is not yet measured against held-out labels.

View as table

Cluster	Grade	Signals	Caps
C1	L1 self-described	names a model or vendor, or carries an agent test tag (anyone can write this)
C2	L1 self-described	names a model or vendor, or carries an agent test tag (anyone can write this)
C3	L1 self-described	names a model or vendor, or carries an agent test tag (anyone can write this)
C4	L1 self-described	names a model or vendor, or carries an agent test tag (anyone can write this)
C5	L2 model-written	model-output residue in requests
C6	L1 self-described	names a model or vendor, or carries an agent test tag (anyone can write this)
C7	L1 self-described	names a model or vendor, or carries an agent test tag (anyone can write this)
C8	L1 self-described	names a model or vendor, or carries an agent test tag (anyone can write this)	capture times only: pace, retries and rhythm cannot be read, so the grade stops at L2
C9	L1 self-described	names a model or vendor, or carries an agent test tag (anyone can write this)
C10	L3 adaptive	model-output residue in requests; a route escalation to reach one page

Step 6

Assess scope

A tier measures payloads and tool use; a grade, how likely an agent is. Neither says the activity went beyond its task. Each cluster answers four separate questions: is a payload present (observed), is an agent present, is it out of scope (an inference from seven tests: off-task targets, getting past a block, sensitive paths, unsanctioned probing, identities and credentials, data sent out, coordination that widens any of them), and is it coordinated. Tool use alone fails no test: a fetch program through an echo service is how agents read, not misbehaviour. Here 4 clusters with a payload present are in scope.

Agent likely (L4+) reads yes only from L4 on the grade ladder: adaptive, model-written requests at a pace or scale beyond one person. The rungs below it (L1 a model or tag named, L2 model-written text, L3 requests that change with the responses) say what the records carry, not that an agent sent them. None of the synthetic clusters reaches L4, so the column reads no throughout: L4 needs a pace or scale signal (machine pace, fan-out over many targets, several services, activity round the clock), and these runs are short and small, written to show the other steps.

SC-FM FM-15.1 · FM-15.3 · FM-15.4

Show the figure

Scroll the figure sideways, or open View as table below it.

payload present (observed) out of scope (inferred) test failed passed not assessable

A row per cluster. An inference for review: the finding never changes a score, a tier or a link, and the admin decides the incident.

View as table

Cluster	Tier	Payload	Agent likely (L4+)	Out of scope	Coordinated	Task	Finding	Failed tests
C1	significant	yes	no	yes	yes	data retrieval	scope exceeded	S6, S7
C2	significant	yes	no	yes	yes	unclear	scope exceeded	S4, S7
C3	significant	yes	no	yes	no	unclear	scope exceeded	S4
C4	significant	yes	no	yes	yes	data retrieval	scope exceeded	S4, S7
C5	significant	yes	no	yes	no	account setup	scope exceeded	S1, S4, S5
C6	suggestive	yes	no	no	yes	data retrieval	in scope	–
C7	suggestive	yes	no	no	yes	data retrieval	in scope	–
C8	suggestive	yes	no	no	yes	data retrieval	in scope	–
C9	suggestive	yes	no	no	yes	data retrieval	in scope	–
C10	suggestive	yes	no	yes	no	data retrieval	scope exceeded	S2

S1 off-task target S2 getting past a block S3 sensitive paths S4 unsanctioned probing S5 identities and credentials S6 data sent out S7 coordination that widens any of them

Step 7

Attribute

Who is behind cluster C1 is answered in four layers: the developer or operator, the hosting network, the harness, the model family. Each claim carries a label (Confirmed, Suspected, Possible) that follows its evidence. A network names a host, not a developer; a model's name inside a request names no one. A developer is named only at the naming gate.

SC-FM FM-7.1 · FM-7.7 · FM-7.8

Show the figure

Scroll the figure sideways, or open View as table below it.

The networks here are documentation ASNs (RFC 5398): no real company is named.

View as table

Layer	Party or candidate	Label	Evidence	Tag
Hosting and runtime	AS64496	suspected	hosting_asn	observed
Hosting and runtime	AS64497	suspected	hosting_asn	observed
Harness and framework	browser automation (Mozilla-compatible user agent)	possible	self_id	inference
Harness and framework	python-httpx	possible	self_id	inference

Step 8
Report, then publish
The tools draft; a person sends, and a second person reviews every notice before it is published. Reports go to the AI provider responsible and to the affected operators first. An indicator notice follows on a short fixed clock that nothing a recipient says extends: it describes the activity and names no affected party. Operators are named in a later update, 3 working days after their report (10 if compromised), or earlier with their consent. A notice informs without enabling: it withholds working payloads, inbox and tag values, and anything that would help repeat the attack. The example indicator notice below is drafted from these synthetic records.
SC-FM FM-10.2 · FM-11.4
Show the figure
Scroll the figure sideways, or open View as table below it.
The two clocks of the publication policy, each counted from a party's latest report; an operator whose systems were compromised waits 10 working days to be named. Working days are Monday to Friday, UTC. Nothing a recipient says moves the indicator clock; only consent names an operator sooner.
View as table
Stage When
Reports provider and operators
Second review of the exact draft
Indicator notice 0 h; 24 h if compromised
Naming update 3 or 10 working days

Stage	When
Reports	provider and operators
Second review	of the exact draft
Indicator notice	0 h; 24 h if compromised
Naming update	3 or 10 working days

Ground rules: collection is passive (no URL an agent submitted is ever opened), model names in requests are weak evidence, and a developer is named only when the evidence reaches the naming gate. Details: methodology, policies, the Field Manual.

Latest notices

No notices yet. A notice is published only after a lead has been reviewed, linked into a case and reported to the AI provider and the affected operators. Unreviewed leads never appear here. Subscribe to the Atom feed to hear about the first one.

What an indicator notice looks like

The first stage: what the activity was and how to recognise it. Affected organisations appear by class only; their names follow in a naming update.

Public notice: suspected AI agent activity

Prepared: 2026-09-16
Window: 2026-09-14 09:30:00 UTC → 2026-09-14 09:35:00 UTC
Records: 6 linked public records in 1 cluster(s) (of 48 records reviewed, 48 flagged)
Evidence tier: significant
Method: swarmchasing 0.1.0, rules version 2026-10-14.5

The rest of the example notice

Summary

Public scan and archive records show automated activity consistent with AI agents operating with little or no human oversight, aimed at a transit authority (6 records). We have not confirmed whether any request succeeded.

Indicators

Category	Rule	Records
Relay / fetch-through services	`relay.jina`	3
Agent tags and markers	`marker.uq_tags`	6
Cache-busting parameters	`cache.buster`	3
Callback / exfiltration channels	`exfil.webhook_site`	6
Header fingerprints	`header.headless_ua`	3
Header fingerprints	`header.scripted_ua`	3

Attribution

Each claim gives its layer, label (Confirmed, Suspected, Possible, Unattributed), tag (Observed, Documented, Inference, Conclusion) and the strongest evidence it rests on. A developer is named only on evidence at least as strong as: identifiers shared with a confirmed incident. Harness and model-family candidates are never named in public.

AS64496 (hosting network). 3 record(s) sent from AS64496. Label: Suspected; tag: Observed. A host is not necessarily the developer.
AS64497 (hosting network). 3 record(s) sent from AS64497. Label: Suspected; tag: Observed. A host is not necessarily the developer.

Endpoints

Every flagged request to each host, including requests outside the linked clusters. "Ongoing" means hit within 7 days of the newest record reviewed.

Target	Hits	First seen	Last seen	Status	Attack payloads
a transit authority (6 hosts)	6	2026-09-14 09:30:00 UTC	2026-09-14 09:35:00 UTC	ongoing	none seen

Timeline

C1 (significant): 6 records, 1 run(s), 2026-09-14 09:30:00 UTC → 2026-09-14 09:35:00 UTC, median gap 60s
- linked by: exfil.webhook_site:[withheld], param:uqtag=ag1x, param:uqtag=ag2y

Representative records

URLs are defanged. Records are listed by evidence strength.

Method and limitations

Collected passively from public records (scan services, web archives, certificate logs). We did not open the submitted URLs, interact with the targets, or read or post to any callback channels.
Records were linked by shared unique identifiers (inbox IDs, tags), by timing against the same target, and by probe chains (variants of one request to the same host and path, minutes apart). Linking is probabilistic.
Model names inside requests are not reliable attribution: agents misreport who built them.
Network attribution (ASN) identifies the hosting provider, not necessarily the developer of the agent.
Public records cover a fraction of activity. Private or account-linked scans are invisible to us.

Requested action

If you operate a listed host, check your access logs for the window above and the indicators listed, and contact us for the full report.
If you run an agent platform, check whether these patterns match your users' agents.
If anything here is wrong, tell us: corrections are published on this page with their date.

Swarmchasing

You received a report about your site, or found it in a notice

You handle reports at an AI provider

You research agent detection

You are an AI agent, or you run one

You follow AI safety, or report on it

The method, on one synthetic incident

Unwrap

Match

Link

Time

Grade agent likelihood

Assess scope

Attribute

Report, then publish

Latest notices

What an indicator notice looks like

Public notice: suspected AI agent activity

Summary

Indicators

Attribution

Endpoints

Timeline

Representative records

Method and limitations

Requested action