Detect accounts reselling US frontier models through a relay or proxy, using account-level user-agent and egress-network dominance in default.generations, and file the survivors as Sentinel ban candidates. Use when asked to sweep for proxy/relay traffic, newapi-style gateways, Go-client traffic on Chinese cloud egress, or to build a frontier-restriction cohort from traffic shape.
Standardmäßig ist der Prompt ausgewählt, der zuerst die Quelle prüft. Sie können zu einem direkten Befehl wechseln oder eine lokale Kopie herunterladen.
Quelldateien prüfen
Lesen Sie SKILL.md und alle von SkillsMP angezeigten Begleitdateien, bevor Sie sich für eine Installation entscheiden.
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Ein direkter Befehl überspringt den Prüf-Prompt. Prüfen Sie die Quelle, bevor Sie ihn ausführen.
Detect accounts reselling US frontier models through a relay or proxy, using account-level user-agent and egress-network dominance in default.generations, and file the survivors as Sentinel ban candidates. Use when asked to sweep for proxy/relay traffic, newapi-style gateways, Go-client traffic on Chinese cloud egress, or to build a frontier-restriction cohort from traffic shape.
allowed-tools
Bash
user-invocable
true
Detect proxy-shaped relay accounts
Goal: find accounts whose frontier spend runs through a relay or proxy, and hand
the survivors to sentinel-ban-candidates as frontier_us_models proposals.
Two signals are available on default.generations, and neither is proof on its
own. The tagged CTE in proxy-shaped-shortlived.sql holds the authoritative
user-agent and ASN patterns for both; extend the signals there.
Self-declared relay user agent — the gateway stacks that ship a
recognisable default user agent. Self-reported, so trivially spoofed, and
absent on any operator who bothered to change the default.
Go HTTP client user agent on Chinese cloud or telecom egress — a Go
client default paired with a Chinese cloud or telecom ASN. The common relay
stacks are Go and ship this default, but so does any Go SDK user.
Rules
Select on account-level dominance, never on matching requests. Require
the signal to carry a supermajority (at least 80%) of the account's usage in
the window. A per-request filter puts large legitimate customers in the
cohort on the strength of one matching request.
Separate short-lived from long-lived accounts and file them as separate
cases. They differ in confidence and in what a reviewer must check, and a
mixed case forces one decision on both.
Short-lived (higher confidence): a span of at most about a day, one API
key, a handful of models, and spend that stops close to a round cap.
Uniform lifetime, key count, model count, egress network, and terminal
spend across independent accounts is a configured ring, not a set of
independent customers.
Long-lived (needs per-account judgement): full-window accounts with broad
model use. A legitimate product with a Go backend on Chinese cloud egress
is indistinguishable from a relay on these signals alone. Do not sweep
these; file them for review with the ambiguity stated.
Propose frontier_us_models, not a ban. Traffic shape plus spend
concentration is one account-level signal short of a ban, and the restriction
is reversible.
State the alternative explanation and the disproof in the case
description. For each cohort, name what would show the selection is wrong.
Run the compromised-key gate on every account before filing, and never
approve or enact on this shape. Relay user agent and egress ASN describe
the relay, not the account behind it, so a harvested key replayed through the
relay lands in this cohort looking exactly like an operator. Check whether the
key predates the traffic, whether the account has its own funding and prior
traffic from a real origin or SDK, and whether the burst model and ASN are new
to an otherwise ordinary account. When any of that holds, file for visibility
only, leave the target pending_review, and escalate for key revocation,
holder notification, and crediting the negative balance. Full gate in
SCANNER_SPEC.md.
Devin Secrets Needed
CLICKHOUSE_URL
CLICKHOUSE_READONLY_USER
CLICKHOUSE_READONLY_PASSWORD
(Usually already in the session environment.)
Run the query
proxy-shaped-shortlived.sql enforces rule 1 plus the span, key-count, and
model-count filters. Cap proximity is evidence only: usd_to_nearest_cap is
never filtered on, so the reviewer applies that test.
A 48-hour window keeps the sweep proactive. Widening it mostly returns accounts
already restricted by earlier sweeps.
For the long-lived half, run the same file against the same lookback_hours
with the shape filters opened up:
param_max_span_hours=48 (the window itself, the highest span it can report),
param_max_api_keys=1000, param_max_models=1000. That run is a superset of
the short-lived one, so subtract the short-lived accounts from it before filing,
or rule 2's two cases overlap. Both runs must share lookback_hours, or the
subtraction compares different windows.
The query carries no FORMAT clause, so swap default_format=PrettyCompact in
to eyeball a run and back to TSVWithNames to parse it.
Then file
Follow sentinel-ban-candidates for the ingest. One target per account,
proposedKind: "frontier_us_models", no proposedTarget, {} params, no
expiry. The query's output columns are the per-target evidence: signal,
signal-matched frontier usage, total usage (the denominator behind every
*_pct), signal share, request counts, egress ASN and country, top user agents,
key and IP-hash and model counts, active span, first and last seen, signup date
and account age, and distance to the nearest round spend cap. Cohort and window
are not columns: they come from which run produced the row, so record the
parameters alongside the rows.
active_span_hours is clamped to the lookback window, so it measures time
active within the window rather than account age, and usd_to_nearest_cap
measures window spend rather than lifetime spend. A months-old account with a
nightly batch job can pass the short-lived filters, so read both against
signup_at and account_age_days before treating a row as a fresh burner.
signal is both_signals when an account carries relay user agents and
Go-on-CN-cloud egress, and no_signal when it carries neither — only reachable
at min_frontier_usd=0 and min_signal_pct=0, since a no-signal account also
has signal_pct = 0; relay_ua_pct and go_cn_egress_pct (plus their request
counts) say how much usage each signal actually accounts for, so cite those
rather than the label alone. round_caps is the cap set usd_to_nearest_cap
measures against — widen it when a ring's spend concentrates elsewhere.
Gotchas
analytics.stg_restrictions lags. It is a CDC replica, so an enactment
from the last few minutes or hours is not there yet and the query's
exclude_restricted filter will re-surface those accounts. Treat the SQL
exclusion as a floor and confirm against sentinel:ban-candidates list and
targets before filing.
A restriction is only equivalent to this proposal if it covers all three US
frontier authors. The exclusion counts frontier_us_models,
inference_block, account_ban, and the three-author author_ban
combination, and nothing weaker.
EU-region traffic is outside the sweep. The query carries
data_region != 'europe' per packages/kyc/sentinel/SCANNER_SPEC.md, so a
relay running on EU-region keys will not appear. Never narrow it to
data_region = 'global': that also drops the us rows.
Frontier spend under-reports BYOK relay traffic. A relayed account on its
own provider key bills the holder upstream while OpenRouter records only the
BYOK fee, so rank and report BYOK exposure alongside the query's usd columns
rather than ranking on them alone.
User agent is empty on a material share of rows and ASN is missing on a
small one, so every share this query reports is a slight underestimate.
Reference the account-level CTE exactly once. ClickHouse inlines a CTE
per reference rather than materializing it, so a second reference re-runs the
whole default.generations scan — measured at double the rows read on a
48-hour run. Enrich from a table that is cheap to aggregate in full instead of
filtering it by the cohort.
Keep unbounded arrays out of the aggregation.topK is bounded and
uniqExact keeps every distinct value per group, which held up empirically at
a 7-day window. groupUniqArray over keys, IP hashes, user agents, or models
across all accounts exhausts the query memory limit. If you need full lists,
aggregate the cohort first, then enrich the reduced account list.
