The OpenAI-TanStack incident shows why EU AI Act deployers need supplier-incident evidence

In May, an attacker used open-source software library TanStack's trusted release pipeline to publish 84 malicious versions across 42 official software packages. OpenAI later disclosed that two employee devices were affected and that limited credential material was exfiltrated from a subset of internal source code repositories, while it found no evidence that customer data, its intellectual property or published software were compromised.

That statement matters. It also has a boundary. 

For deployers under the EU Artificial Intelligence Act, a supplier's public incident statement should not become the whole evidence file. It may be the starting point, but the deployer still needs to show what the incident meant for its own AI system and operating environment.

This is not a claim that every software supply-chain event is automatically a serious incident under the AI Act. That would overstate the law. The narrower point is more practical: when an upstream supplier, software dependency or update channel is affected, deployers need a disciplined way to decide whether the incident changes their AI Act evidence position.

Why is a supplier statement not enough

Article 3 defines a deployer as a person or organization using an AI system under its authority, except for personal non-professional use. That phrase, "under its authority," is where the evidence problem starts.

A supplier can describe what happened in its environment. A deployer still must document what happened on its own.

OpenAI's response also described a third-party investigation, credential and session revocation, temporary restrictions on code-deployment workflows, certificate rotation and a 26 June deadline for certain macOS app updates. Those actions help downstream users understand the supplier response, but they do not replace an assessment of the deployer's own environment.