In March, two malicious versions of a widely used AI gateway sat on PyPI for about forty minutes.
This month we found out they touched roughly 2,500 organisations.
Not because anything new was exploited. Because researchers finally worked through the data the attackers themselves had collected — 433,909 files, 118,829 CI runner dumps — and matched it back to the companies it came from. The compromise happened in March. The blast radius became visible in August.
That five-month gap is the shape of the whole week, and it kept appearing in places that have nothing to do with supply chains.
Authority granted on one device now travels to another, still valid, long after the context that justified it has changed. One upstream planner's wrong assumption fans out through twenty downstream agents and comes back looking like consensus. A step made fourteen times faster produces a system that is not measurably faster at all. A sentiment metric moves because AI entered the process that writes the reviews, not because customers got angrier.
In each case something detached: the permission from the moment, the confidence from the evidence, the local speedup from the system, the measurement from the thing it measures.
Issue 10 ended on the absence of a signal being mistaken for the absence of a problem. Issue 11 was about production outrunning confirmation. This is the layer under both: the link between an action and its consequence stopped being local, and most of our controls still assume it is.
The 60-second version
If you read nothing else:
- A five-month-old compromise just got its real number. The March LiteLLM incident — a poisoned security scanner in CI, not the library itself — is now attributed to roughly 2,500 organisations. Blast radius is discovered on a different timescale from breach.
- Trust travels further than it is granted. A scanner with read access to CI became a credential harvester. Two "independent" model fallbacks can share a base and fail together. A session that follows you across devices carries its logins with it.
- One assumption fans out. A wrong fix direction cut patch success from two-thirds to one in six. An upstream planner feeding twenty agents multiplies a single bad premise; adding an agent at the bottom barely changes risk.
- A faster step is not a faster system. Amdahl's law applies to AI forecasts: the speedup is capped by the part you did not speed up, and the constraint is often something the model never touches.
- The measuring instrument moved. Once AI writes the reviews, sentiment can decline without the experience declining. The number is real; the comparison to last year is not.
One line for the week: the permission, the confidence, the speedup, and the metric all travelled further than the thing that justified them.
1. Trust travels further than it was granted
This week's deep cut.
The most useful story of the week is five months old, which is precisely what makes it useful.
Here is the chain, from the disclosures. In March, a threat actor compromised Trivy, an open-source vulnerability scanner, force-pushing malicious changes across nearly all of its action tags and publishing a trojanised release. LiteLLM — an AI gateway library — used Trivy in its own CI pipeline. When the poisoned scanner ran inside that pipeline, it did exactly what a scanner is designed to do: read broadly. It read the PyPI publishing tokens. The attackers then published two malicious LiteLLM versions, live for about forty minutes before quarantine.
Two details make the mechanism worth understanding rather than filing away. First, the payload used a Python .pth startup hook, so it executed when the interpreter started — not when anything imported the library. "We do not call that package directly" was not protection. Second, the target was a credential-rich environment by design: cloud keys, SSH keys, Kubernetes configuration, database credentials, tokens.
Then the part that happened this month. Researchers obtained and analysed the attackers' own collection — 433,909 files, 118,829 CI runner dumps — and attributed them to roughly 2,500 corporate domains. Forty minutes of exposure in March; five months to learn who it reached.
Worth stating plainly, because the number is doing a lot of work in headlines: at least one research group argues most of those organisations were compromised earlier through Trivy itself rather than through LiteLLM. That does not soften the lesson. It sharpens it — the trust chain is longer than the incident report, and even the researchers reconstructing it disagree about where in the chain each victim was caught.
The general form is what matters, and it showed up three more times this week in completely different domains.
A security scanner needs broad read access in order to be useful, which makes it a uniquely bad thing to compromise — the tool you installed to reduce risk is granted exactly the access an attacker wants. Model lineage fingerprinting surfaced the same shape in AI procurement: two fallback models with different names, vendors and prices can share a base or a tokenizer family, so failures believed to be independent may be correlated. And agent sessions became portable across devices — conversations, skills and connectors following the account rather than the machine, acting through the browser logins you already have. Excellent product decision. It also means an authority granted in one context arrives intact in another.
In every case, something was granted narrowly for a good reason and then travelled.
Operator move: map the things your systems trust transitively, not just directly. For each: what access does it hold, what could it reach if compromised, and what would tell you it had been. Then apply the specific controls this chain defeats — pin executable CI tooling to exact versions or digests rather than floating tags, scope credentials to what the tool genuinely needs rather than what the environment happens to expose, and stage tool updates through a canary rather than adopting them organisation-wide on release. And add the retrospective habit: when a compromise is disclosed anywhere in your dependency graph, ask not "are we patched" but "what did that component have access to while it was compromised, and can we still reconstruct which of our pipelines executed it?" Five months is a long time to find out you were in the archive.
Everything a tool can read, an attacker who owns that tool can read too. The read access was the point.
2. One assumption fans out across the graph
If trust travels, so do mistakes — and this week produced the sharpest available statement of how.
Research into multi-agent systems keeps landing on the same structural point: reliability is a property of the delegation graph, not the agent count. An agent added at the bottom of a workflow barely changes systemic risk. One upstream planner feeding twenty downstream workers multiplies a single bad premise across everything below it, and the results come back looking like agreement rather than like one error repeated.
The patch study from the previous week gives this a number. When the prompt carried a correct fix direction, models closed the bug about two-thirds of the time; when it carried a plausible but wrong one, that collapsed to roughly one in six. A single upstream assumption, propagated confidently, did more damage than any model-quality difference. Confidence should not increase because several descendants repeated the same upstream claim — but structurally, that is exactly what happens.
Operator move: treat fan-out as a risk multiplier and set verification thresholds by position in the graph rather than by depth. A leaf result consumed once can use the ordinary evidence bar. An upstream classification or plan consumed by many workers needs stronger verification before release, because everything below it inherits the error. Make unverified claims structurally incapable of becoming canonical shared context, and when a high-fan-out node fails, quarantine the dependent branches instead of letting each continue on its own copy of the bad premise. Test it deliberately: inject one false assumption at a leaf and one at a planner, and confirm the damage differs.
The dangerous question is not how many agents you have. It is which wrong assumption can reach the most downstream work.
3. A faster step is not a faster system
The week's clearest corrective came from an old law rather than a new capability.
Amdahl's law says the speedup is capped by the part you did not speed up. Make one stage infinitely fast and the system still runs at the pace of everything around it. Most AI forecasting skips that step entirely: find a task a model now does well, multiply, and describe the result as transformation.
Two of the week's launches make the point concrete in opposite directions. A frontier model reached roughly 750 output tokens per second, about fourteen times a standard tier — a genuine capability change for interactive coding, incident response and control loops, where a correct answer after the useful window is functionally a different answer. And in the same week, the counter-observation: most long-running agent workflows spend their time waiting on tool latency, builds, browsers, APIs and verification, not on token generation. The same fourteen-times improvement is transformative in one workload and invisible in the other.
The organisational version showed up too. As implementation time shrinks, unresolved decisions become the visible constraint — a roadmap can say September while the actual blocker is a choice nobody owns. Slower building used to hide decision latency inside the schedule.
Operator move: before forecasting from a capability, find the step the work is currently waiting on, and check whether the model touches it. If it does not, the forecast is arithmetic about the wrong number. Then apply it to your own queue: instrument where time actually goes in your slowest workflows, and if the answer is approvals, decisions or handoffs rather than execution, that is where the automation budget belongs — not on making an already-fast step faster.
This cuts both ways, which is what makes it useful rather than cynical: it explains both the pilots that produce nothing after impressive demos and the teams that get outsized results from unremarkable models because they happened to automate the actual bottleneck.
4. The measuring instrument moved
The subtlest detachment of the week is the one that leaves every number intact.
A study of 117,816 hotel reviews found that access to a chatbot changed both the length and the tone of what people wrote — with the most negative AI-assisted reviews becoming harsher and more subjective than their unassisted equivalents. Feed that distribution into a sentiment dashboard, a support prioritisation model, or an agent that acts on customer signal, and the numbers are real while the comparison to last year quietly stops being valid. AI did not analyse the signal. It entered the process that generates it.
The same question runs through two other threads. Autonomous products break the engagement metric in the other direction: for a set-and-forget system, early human activity can fail to predict retention entirely, because the product creating the most value is the one nobody needs to open. And agent failure turns out to be a measurement of the codebase as much as of the model — Cloudflare's Astro workflow treats a repeatedly failing agent as evidence of opaque abstractions or missing tests, on the reasoning that an agent with no tribal knowledge is an unusually honest probe for whether a system exposes its own invariants.
Operator move: for every metric that drives an automated decision, write down what it is a proxy for and what would break that proxy. Then check the specific break that is now live everywhere: has AI entered the path that produces this data — writing the reviews, filing the tickets, drafting the résumés, summarising the incidents? If it has, re-baseline rather than comparing across the boundary, and be especially careful about handing that series to an agent, which will optimise the number without any sense that its meaning shifted underneath.
Before asking an AI to act on a metric, check whether AI has already changed what the metric means.
5. Explore wide, answer narrow
The last theme is the one that turns the rest into a working practice, and it has a pleasing symmetry: the answer to detachment is deliberately narrowing what you are accountable for.
Cheap agentic implementation genuinely changes the economics of exploration. Trying three working approaches can now cost less than arguing about them abstractly for a day. But human review did not get a larger context window, and the failure mode is letting the exploratory implementation become the pull request. Build wide; then collapse the result into a small change with explicit boundaries that a person can actually own.
The same discipline showed up as its own absence. One coding-agent run lasted over seven hours and attempted thirteen releases, driven by an eighty-six-line skill written to help with release work that kept pulling migrations, policy changes and production recovery into scope. Nothing malicious — just a procedure with no stated non-goals, where every newly discovered problem read as an invitation to continue. PortSwigger's HTTP desync research is the counterexample: genuinely novel AI-assisted findings across tens of thousands of authorised targets, held together by deterministic validation gates that decided what counted. And a separate security investigation found a real exploit chain while the agent performed actions outside its intended mandate — technically successful, and a task failure.
Operator move: specify what a skill or agent task must not do, with the same care you specify what it should. Mutation scope, retry budget, the boundary at which it returns to the caller rather than continuing, and the evidence that means done. Then judge outcomes on two axes rather than one: did it achieve the objective, and did it stay inside the authorised envelope. An agent that succeeds by exceeding its mandate has told you something important about the next task you give it.
Exploration can be abundant. Responsibility still needs a tractable object.
Counter-signals worth holding
Three tensions to keep live, with where I would put the weight:
Locality is not always recoverable — or worth recovering. Portable sessions, shared upstream context, transitive tooling and model reuse all exist because they deliver real value; re-authorising every action and rebuilding every dependency locally would produce a slower, more brittle organisation that people route around. Real. The weight: the goal is not to re-localise everything but to know where the link is broken and to instrument those specific points — a system with three well-understood detachment points is safer than one that pretends it has none.
The 2,500 number deserves care. At least one research group argues most affected organisations were compromised through the scanner directly rather than through the AI gateway, and attacker-collected archives are a biased sample of what was reached. Fair. The weight: the precise attribution matters less than the interval — whatever the exact path, the blast radius took five months to become legible, and that interval is the operational problem regardless of which link in the chain caught whom.
Not every metric distortion is corruption. When AI helps someone articulate a complaint they could not previously express well, the resulting signal contains more information, not less; treating every AI-mediated input as noise throws away real feedback. True. The weight: the failure is not AI in the pipeline, it is comparing across the boundary as though nothing changed — re-baseline, do not discard.
Operator takeaway
If you are shipping in regulated systems, security-sensitive, or AI-adjacent products, three things hardened this week:
- Map trust transitively, and assume discovery lags the event. What can each trusted component reach if compromised, and could you reconstruct which of your systems executed it five months later? Pin executable tooling, scope credentials to need, stage updates through a canary.
- Set verification thresholds by fan-out, not by depth. An upstream assumption consumed by many workers needs stronger evidence before release than a leaf result used once. Confidence must not grow because descendants repeated it.
- Check what the number is still a proxy for. Find the limiting step before forecasting from a capability, and re-baseline any metric whose data-generating process AI has entered. A real number attached to an obsolete meaning is worse than a missing one.
These are not predictions. They describe where the operating ground already moved.
Worth tracking
A few specific things from this week worth a closer look:
- Whether transitive executable tooling gets its own inventory discipline — the LiteLLM chain worked because a scanner is trusted by design; scanners, linters, build helpers and agent tooling arguably need to be tracked separately from ordinary application libraries, with their own credential scoping and update staging.
- Model lineage as procurement metadata — if fingerprinting becomes routine, multi-model resilience claims become checkable rather than assumed, and "we have vendor diversity" turns into a testable statement.
- Whether portable agent sessions grow risk-tiered revalidation — session continuity is now shipping across surfaces; the open question is whether high-consequence grants get re-checked when the surface or the underlying state changes, or simply travel with the conversation.