TanStack had a bad twenty minutes.
On May 11, attackers published 84 malicious versions across 42 @tanstack/* npm packages. The official postmortem is worth reading because the mechanics are unusually clear: pull_request_target, a poisoned GitHub Actions cache, an OIDC-trusted publish path, runtime token extraction from the runner, a malicious optional dependency, a prepare script, a 2.3 MB obfuscated payload, credential harvesting, and self-propagation through other packages the victim maintained.
No model was needed for the initial compromise. This was a human attacker using standard supply-chain machinery well.
The TanStack maintainers reacted fast. External researchers spotted the malicious packages within roughly twenty minutes, the team coordinated publicly, deprecated affected versions, contacted npm security, and published a detailed postmortem the same day.
I don't think that's the main lesson from the TanStack incident. The maintainers' own lessons are more important: cache boundaries, pull_request_target, OIDC scope, publish monitoring, and the places where trusted CI assumptions broke down.
But I'm building in the agent layer, so the part I notice is different.
The awkward part starts after the advisory lands.
At that point, the incident becomes a long trail of local recovery decisions. Someone upgrades to latest without checking whether the registry cache has actually caught up. Someone rotates a token from the same machine that just ran the payload. Someone reruns CI under the same trust boundary that was crossed. Someone pastes "fix the TanStack issue" into a coding agent and accepts the first clean-looking patch.
None of those moves are obviously stupid. That's why they worry me.
Incident response is full of actions that are right in one order and wrong in another. Rotate credentials, but not before isolating the host if the malware reacts to failed credentials. Rerun CI, but not before deciding whether the runner, cache, secrets, or workflow boundary are suspect. Publish a fixed package, but not before understanding whether downstream consumers can distinguish it from the compromised line. Update a lockfile, but not if the registry or mirror state makes the new resolution ambiguous.
Many teams will spend more time on recovery than on understanding the original exploit.
Coding agents change that recovery phase. A developer may ask an agent to help, and the agent may bump dependencies, edit workflows, run package-manager commands, rerun tests, and — if it's wired to the right tools — rotate secrets, delete caches, or revoke tokens. Those are useful capabilities in normal development. During an active supply-chain incident, they can also make the problem worse.
The problem isn't that the agent is malicious. The problem is that it's obedient.
Humans make bad recovery calls too. The difference is speed and surface area. An agent can turn a vague instruction into filesystem edits, GitHub API calls, package-manager commands, and CI reruns before anyone has written down what is known.
If the prompt is "fix the TanStack issue," the agent doesn't automatically know whether the host that ran npm install was exposed, which credentials were reachable, whether CI caches are trusted, whether package tarballs are still installable, or whether the next action can be undone. It can produce a reasonable-looking remediation diff while missing the one fact that mattered: this machine should not be taking action yet.
That's the problem I'm building Posteria around.
Posteria wouldn't have stopped the TanStack compromise. It sits later in the chain. It's a check an agent calls before taking an action that may be hard or impossible to undo.
For example, imagine a developer asks an agent to remediate a repo that installed one of the affected versions. The agent proposes four steps: inspect the lockfile, rotate npm and GitHub tokens, clear CI caches, and rerun the test suite in GitHub Actions.
Those steps sound reasonable. They aren't equivalent.
Posteria would allow the local lockfile inspection because it's read-only. It would stop before the CI rerun because the workflow may still depend on poisoned cache state. It would ask for evidence of host isolation before token rotation, because rotating secrets from a machine that just executed credential-stealing malware may compromise the replacement credentials too — the attacker can use already-stolen tokens to observe the rotation. In this incident, the persistence mechanism was concrete: a polling daemon that ran rm -rf ~/ if the stolen token was revoked (documented in the issue thread: github.com/TanStack/router/issues/7383). An agent that rotated credentials before isolating the host would have triggered it.
Posteria would treat cache deletion as a containment action and require the agent to identify which cache, which workflow, and why deletion is safer than quarantine.
It would also leave a record of the sequence: what the agent believed, what it did, what it refused to do, and why. That record has to be designed carefully because incident records can contain sensitive data too. But without some durable account, adding agents to recovery makes the eventual postmortem harder.
The control point is simple: before an agent acts, it should know what kind of action it's taking. Today, most agent workflows treat those as ordinary tool calls with different command strings. That seems wrong to me.
Most supply-chain hardening work focuses on keeping the malicious package out: pinned action SHAs, safer pull_request_target usage, scoped OIDC bindings, provenance checks, dependency cooldowns, cache isolation. We need all of that.
But once the package gets in, the problem changes. The next risk is no longer only attacker-controlled code. It's well-intentioned automation acting with partial context on a system that may already be compromised.
The first compromise gets the headline. The recovery decides what the incident actually costs.