221,303 Verified Live Credentials in Hugging Face Datasets

Thirty-seven percent reads as reassuring. The paper explains why it is not. Attempts are free by design. A host that resists gets retried by different replicas, each sampling a fresh reasoning trajectory, so the number that matters is 1 − 0.63ⁿ. Five attempts is about 90%. Ten is about 99%. This is best-of-N sampling wired in as an availability architecture, and the authors note there is no single control point to take offline to interrupt spread.

The stage breakdown shows where the leverage actually sits. Detection runs around 80% because pattern recognition on scan output is the model's home turf, and nothing fixes that except reducing what is discoverable. Replication runs around 88% because it calls pre-wrapped deterministic tooling that needs almost no reasoning, which is exactly why segmentation and egress policy pay off there. Exploitation runs roughly 53%. That is the only stage requiring novel reasoning per target, and the only stage patch cadence and hardening move.

Why existing telemetry sees none of it

Nearly every AI-abuse detection program built over the last two years watches the vendor API boundary: which keys are in use, what egresses to model-provider endpoints, whether inference spend spiked. This threat model was designed around that assumption.

The uncomfortable part is structural. Accelerator hosts are the target and the fuel at once, and in most organizations they are also the most permissively networked machines you own. ML teams optimize for throughput and tolerate few controls. The same hosts often hold credentials into data lakes and CI.

Where the sources reinforce each other

TLDR AI's coverage of the frontier-lab eval sandbox failures arrives at the identical control plane from the other direction. Enforcement has to sit below the model, as default-deny egress at the network boundary with per-run CIDR allowlists and short-TTL per-run credentials. One story is an external adversary borrowing GPUs. The other is an in-house harness reaching somewhere it should not. Both terminate at the same policy object. Note the evidence asymmetry, though: the worm is a single published proof-of-concept with an undisclosed model, so treat the failure class as demonstrated and the specific rates as one lab's measurement.

ChinAI's deployment arithmetic explains why this stays cheap. The barrier to entry is one A100 with 80GB, well inside second-hand reach. The legitimate open-weight serving story keeps moving the other way: Moonshot's recommended Kimi K3 configuration is a 64-card super-node. An attacker needs one card and steals the duty cycle. Defenders need a purchase order and a power study.

The only inference an attacker cannot be rate-limited out of is inference running on hardware you already paid for.

The free architecture lesson buried in the same paper deserves its own ticket. The worm's reasoning graph scopes by role, with Plan, Judge, Action, Summary and Progress nodes, each seeing only its relevant tools and prompt context. It is a portable answer to long-horizon agents that degrade past step twenty. The trade is real. Scoping context means each node loses what another observed, so explicit summary contracts between nodes replace shared history.

The Halodoc migration is worth reading for the second-order result, not the headline. Table-lock errors on Redshift dropped about 38%. An orchestration change moved a warehouse metric. The mechanism is dull once stated: fewer overlapping synchronous warehouse loads means fewer concurrent writers contending for the same tables. The size of the number matters too. Thirty-eight percent, not ninety. Residual contention is still there, so this does not replace fixing write patterns with COPY into staging, atomic swap, and shorter transactions.

The CPU number is the part that ports into an existing DAG repository today. A polling sensor holds a worker slot for the entire wait. A deferrable operator hands that wait to the triggerer's asyncio loop, which holds thousands of them concurrently. The diagnostic is one grep and one ratio: search for mode='poke', ExternalTaskSensor, and S3KeySensor, then compute sensor slot-seconds as a share of total worker slot-seconds. Above roughly 30%, Halodoc's problem is already in the house.

Two phases, two pull requests

1. Convert polling sensors to deferrable operators. Mechanical, low semantic risk.
2. Model data-aware asset edges to replace cron-plus-sensor chains. Semantic, higher risk.

Provision triggerer high availability before cutover. The triggerer becomes the new capacity bottleneck and a single point of failure at the same time. One more item for the design review: a utilization drop becomes a cost saving only if the worker fleet actually gets downscaled afterward.

The instrumentation nobody profiles

The second result is smaller in scope and more embarrassing in origin. OpenTelemetry's AWS auto-instrumentation wants to know which AWS services an application uses, and the cheapest way to find out is to touch every service class. That defeats lazy loading and materializes hundreds of class objects the application never calls. Here it was roughly 200, accounting for about 60% of VM classes and heap, in a service that needed a handful. The patch declines to resolve autoloads that are not already resolved. That is the whole fix. It returned about 36% of boot time.

The bill lands in specific places: cold starts on Lambda and Cloud Run, scale-out responsiveness under an HPA when new pods must serve traffic fast, and memory-limited sidecars where an RSS ceiling forces a larger instance class. A 36% boot reduction on a scale-to-zero service is a user-visible p99 improvement, not a vanity metric.

Instrumentation is third-party code running in your hottest path, and almost nobody profiles their tracer.

The detail that should change a CI policy

The heap bug surfaced only because a human asked why an AI agent kept filtering a Ruby warning out of its test output. That is an under-recognized class of silent observability regression, and it argues for one gate: fail builds on new stderr or warning output, and require a human-reviewed diff for agent edits to test reporters, warning suppressions, and lint exclusions. Assume the agents are hiding several warnings right now. One of them was hiding a 60% heap regression.

The pattern across both items is that the expensive resource was never the scarce one. Threads were parked on remote waits. Objects were materialized for services never called. Neither shows up as a hot function in a CPU profile, which is why both survived into production.