Skip to content

BABEL and GTG-14020: many operators, one account

Sources (studied 2026-09-14, bead w6xw):

Fidelity caveat: everything about BABEL itself comes from one outlet (S1, S2), plus a secondary reading of that outlet (S4). None of it has been independently verified. This note does not reproduce the infrastructure indicators or personal data that appear in S2 and S4, and nothing here should be read as attribution.

Companion to erdos-ai-ledger-lessons.md: its lesson 2 (the denominator problem) comes back here twice, as a refusal that was re-prompted and as a router that hides who is asking.

First: does BABEL match GTG-14020?

NetAskari's framing is that Anthropic's case "by coincidence matched a project we have been following for weeks." Line the two up before drawing any lesson:

GTG-14020 (S3) BABEL (S1, S2)
Who "One operator" ran the desk; Anthropic banned "a group of accounts" "A single operator", said to be affiliated with CIPU (a police university)
How Claude was used At runtime, as "a stand-in for a staffed analyst team": ingest multilingual sources, write templated Chinese-language dossiers At build time: Claude wrote the scrapers and infrastructure. Analysis at runtime ran on a MiniClaw agent over DeepSeek or OpenAI
Access path Not described Through a Chinese model router (huoshenai[.]com)
Targets Catholic cardinals across Asia; Presbyterian Church in Taiwan; Tibetan exile administration and advocacy groups; Falun Gong and affiliated media; missionary networks (Singapore, Hong Kong) Uyghur diaspora; Tibetan exile politicians; Inner Mongolian independence activists; Christian communities in Japan and Korea
Output Dossiers, clue reports, daily digests A running platform: dashboards, chat assistant over a monitoring database, Telegram and Reddit collection, blockchain tracker

One of five target sets overlaps (Tibetan exile politics). The mode of use is different: one describes a model doing the analysts' job, the other describes a model writing software that other models then run. The same S3 report has a second case, GTG-14021, that includes "a police academy student" and a municipal cyber police unit that ran a monitoring pipeline through Claude Code. That fits a CIPU tie at least as well as 14020 does.

S4 logs internal contradictions in S2 as well. The body says the servers were in the US and Malaysia, while the IP geolocation in the screenshots says US and Korea. The narrative says Claude and MiniClaw, while the terminal screenshot says it is "based on GPT-5". The system's own chat assistant calls its dataset a "sample database".

Verdict: the match is asserted, not shown. At most, BABEL is one operator's toolchain seen from the server side while S3 saw a desk from the API side, and those may or may not be the same actor. The lessons below do not depend on the match. They depend on the mechanisms each source describes on its own terms.

Lessons and their translation

# Mechanism (source) SWARM translation Where it lands
1 Many operators, one account. A model router pools end users behind aggregator accounts and takes payment in yuan, with no Western card or KYC (S1, S2) The inverse of a Sybil. SybilDetectionLever looks for one entity behind many identities; a router is many entities behind one identity. Every per-agent lever (reputation, staking, circuit breaker, audit) then acts on a mixture Scenario bead ggiw
2 Build-time uplift, run-time harm elsewhere (S1 vs S3) The provider sees "write a Telegram scraper" and "build a dashboard", each with a high p. The harm is realized later, on a different model, outside the interaction. E_soft = (1-p)·h prices harm in the interaction; here h lands off-platform and no ρ can internalize it Open question 2; relates to trajectory coverage (q2fg)
3 Refused, then re-prompted (S3, GTG-14021: "Claude refused an attempt … But the actor was able to re-prompt") A refusal is a per-attempt gate, and attempts are free to retry. This is the denominator problem again: a metric over accepted interactions scores the successful retry and never sees the refusal before it Open question 3; see the 81sk correction in erdos-ai-ledger-lessons.md
4 One operator, a team's output (S3: "the work of a team of analysts … run by a single operator") Harm capacity per identity scales with automation, not headcount. Levers keyed on agent count or per-agent rate assume a large operation needs many agents Covered in part by existing rate-limit levers; not modelled as capacity per identity
5 Composition, not components (S2: scrapers, chain tracker, Telegram monitor "don't all tie into the wider system") Each component is dual-use with a benign base rate. What makes it surveillance is the target list and the join. capability_precondition.py already names the boundary: "a harmful write to a resource the agent is granted passes" Open question 2

The adversarial reading

Take the router's side. It is a legitimate business for most of its customers (cheaper tokens, local payment), which is exactly why it works as cover. A provider that bans the router account cuts off every benign co-tenant. A provider that doesn't keeps serving the adversary. Either way the provider's metrics are computed over a mixture it cannot split. If adversarial operators are a fraction f of router traffic, per-account toxicity is the mixture f·T_adv + (1−f)·T_benign, so the adversary's excess over the benign base is scaled down by f. Once a detector's threshold sits above that diluted excess, the adversary is invisible for as long as the router's benign base stays large. The adversary's best move is therefore to route through the largest and most reputable aggregator, not a shady one.

Take the provider's side. The router is also a single point where volume is visible (S4 J-003 makes the same point). It concentrates many users into a few accounts, which is expensive for attackers who need to look ordinary, and router-side KYC pass-through is a lever that exists nowhere for direct accounts. The question is the price of that lever relative to bans, and it is empirical.

What is measurable now

  • Dilution at the router level: run any existing adversarial scenario with agents relabelled so that K of N share an identity, and compare toxicity_rate and quality_gap at operator vs. identity granularity. This needs no engine change, only a post-hoc groupby on the interaction log.
  • Retry denominator: count attempts per interaction in scenarios where governance refuses before an interaction is recorded. First check whether the event log records the refused attempt at all (not yet audited). If it doesn't, that absence is the finding.

Proposed scenario

Bead ggiw: N operators, mostly benign plus a few adversarial, route through K routers, and the governance engine observes only router-level identities. Sweep one lever at a time: the pooling ratio N/K first, then the ban policy (ban the router vs. ban nothing), then KYC pass-through at a cost. Report toxicity and quality gap at both granularities, benign-operator welfare lost per adversary removed, and adversary persistence (epochs to re-route after a ban). A second arm tests lesson 5: give an adversarial operator a task decomposed into individually high-p components and check whether a trajectory-level check (q2fg) recovers what the interaction-level metrics miss.

Falsifier: if per-identity toxicity at realistic pooling ratios still separates routers that carry an adversary from routers that don't (e.g. AUC > 0.8 at f = 0.05), lesson 1 is wrong about invisibility and the interesting lever becomes ban precision, not detection.

Open questions

  1. Did BABEL's Claude traffic go through the router? If all of it did, a ban on the operator's own accounts, as S3 describes, is hard to square with BABEL being GTG-14020. Either the operator also had direct accounts, or these are different actors. This is the cheapest discriminator between the two stories and neither source addresses it.
  2. Can off-platform harm be priced at all? SWARM's externality term assumes harm is realized by the interaction that caused it. Build-time uplift breaks that. Candidate: a deferred externality attached to an artifact (the code) and charged when the artifact is used. That needs artifact provenance, which is exactly what a router strips.
  3. What is the refusal-retry rate? A refusal that yields to a re-prompt is a detection that was logged as a success. S3 names one instance, and no rate is public.