
On May 11, 2026, a threat group called TeamPCP published 84 malicious versions of 42 widely-used developer packages in a six-minute window.
On May 11, 2026, a threat group called TeamPCP published 84 malicious versions of 42 widely-used developer packages in a six-minute window. The packages carried valid SLSA Build Level 3 provenance attestations. Sigstore verified the build process correctly. Every downstream organization that required attestation before installation got exactly what they required.
The attacker had not broken the attestation. They had hijacked the legitimate CI/CD pipeline itself, chaining three GitHub Actions vulnerabilities to extract a valid OIDC token and publish malicious code under the pipeline's own verified identity. The certificate was real. The provenance was accurate. What the provenance attested to was the problem.
The payload polled each compromised machine for GitHub tokens every sixty seconds. The moment a token was revoked -- the way every incident response playbook says to revoke it -- the worm ran a destructive cleanup routine. The attacker did not need the evidence to survive. They built the operation around the assumption that it wouldn't.
This is not a story about a verification framework failing. SLSA worked. The question it was designed to answer -- did this artifact come from this pipeline? -- was answered correctly. The question it was never designed to answer is the one that determined the outcome: who authorized the workflow configuration that made this possible, when was it last reviewed, and under whose authority was the pipeline operating?
No standard required that question to be answered. No record was required to exist. The attacker understood this. The defenders, collectively, did not.
TanStack is the sharpest example of a pattern that runs across every significant accountability failure in the past six months. In each case, a control was present and satisfied. In each case, the authorization record -- the durable, attributable proof of who decided what, under whose authority, against what policy, at what time -- was absent, incomplete, or designed out of existence before it was needed.
Incident | Control Present | Authorization Record Absent |
|---|---|---|
TanStack / SLSA | Build Level 3 attestation, valid OIDC certificates | Who authorized the workflow configuration, when last reviewed, under what authority the pipeline operated |
Vercel / Context.ai OAuth | Google Workspace OAuth flow, enterprise controls | Who authorized the "Allow All" grant, whether any policy review occurred, what scope was approved and by whom |
CISA / Nightwing | GitHub secret scanning guardrails (present and then disabled) | Who authorized disabling the guardrail, under what policy, and a six-month access log that may not survive the 90-day CloudTrail default retention window |
Agentic security agents | Execution logs | Who defined agent action criteria, when, under what authority, against what policy version |
Instructure / Canvas | Incident response, patching | What the attacker accessed before the demand, who authorized the affected data scope, whether that record was preserved |
The CISA row deserves a second look. A contractor at Nightwing disabled GitHub's built-in secret scanning, then committed 844 MB of AWS GovCloud credentials, plaintext passwords, and internal infrastructure data to a public repository named "Private-CISA." The repository sat open from November 2025 until mid-May 2026. Six months. The person who disabled the guardrail has not been identified. The authorization for that configuration change is not documented. And the default CloudTrail retention window is 90 days -- meaning the access log covering the first half of the exposure period may already be gone before any investigation formally begins.
The control was there. Someone turned it off. No standard required a record of who did that, or why, to survive long enough to matter.
The EU AI Act Article 14 requires providers of high-risk AI systems to create the conditions for effective human oversight. It does not require that oversight leave a provable record. A qualified person can review an AI output, approve it, satisfy the regulation entirely, and leave no documentation that the approval happened, when it happened, or under what authority. The oversight occurred. The authorization record did not.
DORA requires financial entities to maintain a register of every ICT third-party service arrangement, recording who provides it and whether it supports a critical function. It does not require a record of who internally authorized each consequential change to how that service is used. The register proves the contract exists. It does not prove the human decision chain that preceded the deployment.
NIST and ISO 42001 require that controls exist. Neither requires that each agent action, each configuration change, each scope grant, be linkable to a specific named human authorization decision at a specific time in a record designed to survive scrutiny.
The only mechanism in current practice that creates action-level authorization records for AI-assisted output is the Developer Certificate of Origin. Each commit is a named human certifying provenance at a specific time. The Linux community extended this to AI-assisted code because someone recognized the gap. Nothing equivalent exists for agentic AI decisions made at runtime. The DCO covers what a human put in. No standard covers what an agent decided to do, under whose authority, and whether that record holds.
Attestation answers a provenance question. Authorization answers an accountability question. The supply chain security community built a serious, rigorous answer to the provenance question. The TanStack attack did not break that answer. It demonstrated that the answer is necessary and insufficient simultaneously.
The attacker's sophistication was not primarily technical. It was documentary. They understood that the authorization record was the weakest point in the chain not because it was hard to protect but because no standard required it to exist in a form that could survive what came next.
Accountable by Design means building the authorization record as infrastructure, not as an afterthought. It means treating the question of who decided what, under whose authority, as a requirement with the same standing as the question of where an artifact came from. The frameworks we have right now can certify the first. None of them require the second.
Where in your organization right now is a tool running ahead of the rule designed to govern it? That gap is what we are here to map.
Vordan publishes the Accountability Report every Sunday and the Gap Alert when intelligence warrants it. Doctrine: Accountable by Design.
SOURCES + REFERENCES
UltraViolet Cyber -- Threat Advisory: TanStack Supply Chain Attack https://www.uvcyber.com/resources/reports/threat-advisory-tanstack-supply-chain-attack
Snyk -- TanStack npm Packages Hit by Mini Shai-Hulud https://snyk.io/blog/tanstack-npm-packages-compromised/
StepSecurity -- Mini Shai-Hulud Is Back https://www.stepsecurity.io/blog/mini-shai-hulud-is-back-a-self-spreading-supply-chain-attack-hits-the-npm-ecosystem
Rescana -- TanStack npm Supply Chain Attack: Detailed Analysis https://www.rescana.com/post/tanstack-npm-supply-chain-attack-detailed-analysis-of-the-may-2026-github-actions-breach-and-multi-ecosystem-impact
Strobes -- TanStack npm Supply Chain Attack: 170 Packages Compromised https://strobes.co/blog/tanstack-npm-supply-chain-attack/
Vercel -- April 2026 Security Incident Bulletin https://vercel.com/kb/bulletin/vercel-april-2026-security-incident
The Hacker News -- Vercel Breach Tied to Context AI Hack https://thehackernews.com/2026/04/vercel-breach-tied-to-context-ai-hack.html
VentureBeat -- Vercel Breach Exposes the OAuth Gap https://venturebeat.com/security/vercel-breach-exposes-the-oauth-gap-most-security-teams-cannot-detect-scope-or-contain
Trend Micro -- The Vercel Breach: OAuth Supply Chain Attack https://www.trendmicro.com/en_us/research/26/d/vercel-breach-oauth-supply-chain.html
Cyber Unit -- CISA Private-CISA GitHub Leak https://cyberunit.com/insights/cisa-private-cisa-github-leak-what-businesses-should-know/
Akeyless -- CISA's GitHub Leak Exposed a Static Secrets Problem https://www.akeyless.io/blog/lessons-from-the-cisa-github-leak/
WireX Systems -- When the Defender Leaks Itself https://wirexsystems.com/when-the-defender-leaks-itself-the-cisa-github-exposure-and-the-limits-of-after-the-fact-investigation
Dark Reading -- CISA Exposes Secrets, Credentials in Private Repo https://www.darkreading.com/cybersecurity-operations/cisa-exposes-secrets-credentials-private-repo
EU AI Act -- Article 14: Human Oversight https://artificialintelligenceact.eu/article/14/
DORA -- Article 28: ICT Third-Party Risk https://www.digital-operational-resilience-act.com/Article_28.html
DORA GRC -- Register of Information: Complete Guide https://doragrc.com/dora-register-of-information
