← All posts On 20 May 2026, GitHub confirmed that around 3,800 of its internal repositories had been exfiltrated. The way in was not a sophisticated zero-day. It was a poisoned extension that one GitHub employee installed in their code editor. That extension quietly handed an attacker the credentials, cloud keys and SSH keys sitting on the developer's machine, with enough permission to clone the company's internal code. (The Hacker News has the detail.)
The group behind it, TeamPCP, tracked by Google's Threat Intelligence Group as UNC6780, has a specific speciality: compromising open-source security tools and AI middleware. Their earlier victims read like a shopping list of the exact components engineering teams reach for when they want to move fast.
And here is the part every executive should sit with. Among the GitHub code that was stolen was the source for Dependabot and CodeQL: GitHub's own tools for finding vulnerable dependencies and scanning code for security flaws. The company whose business is hosting the world's code, and whose tools are supposed to police everyone else's supply chain, was breached through an unvetted dependency on a single laptop.
That should stop anyone who has recently been told a new AI integration was "built in-house over a weekend."
The weekend win that is not a win #
When an internal team says they can wire an AI model to a database themselves, cheaply and quickly, it sounds like exactly the initiative leadership wants to reward. Fast, frugal, no procurement cycle.
But modern software is not written so much as assembled. An engineer adds a few lines of code, and that code automatically pulls in hundreds of pre-built components written by strangers, each of which pulls in more. The moment the project works, the engineering team marks it done and moves to the next thing.
The risk does not leave with them. It moves to the security, risk and compliance teams, who are handed a sprawling, invisible web of third-party code and told to secure it. They are asked to police a perimeter whose fences are made of shifting sand.
The loop that makes it worse #
When leadership realises these quick internal builds are a governance exposure, the instinct is to add oversight. Teams bolt on more open-source libraries: one for logging, one for monitoring, one for audit trails, one for policy.
Here is the problem. Every one of those governance libraries is itself assembled from someone else's components. The logging library has a supply chain. The compliance scanner has a supply chain. You are answering a dependency problem by adding more dependencies.
The result is checkbox compliance: a system that looks governed on an audit slide while the actual data path stays exposed to whatever happens upstream. TeamPCP's track record is the evidence. The tools companies add to feel safer are the tools being targeted, and the GitHub breach showed it works right up to the company that builds those tools.
AI makes the loop spin faster #
AI-assisted coding has not changed the shape of this problem. It has changed the speed.
A developer can now generate working software in an afternoon. But the models doing the generating are optimised for one thing: producing output that runs. They reach for large, convenient, deeply-nested dependency trees because that is the fastest path to "it works." The software runs on Monday morning. By Friday, no human inside the company can tell you what was installed underneath it to make it run.
Governance cannot exist where the building blocks can mutate without anyone with authority seeing it happen.
Two ways to build, two outcomes #
| The in-house quick fix | An AI control plane | |
|---|---|---|
| Speed to first version | ||
| Fast | Fast (drop-in, one configuration change) | |
| What it rests on | ||
| Heavy, layered, third-party packages | One audited binary, one supply chain, maintained by the vendor | |
| Who owns the risk after launch | ||
| Your security team, unquantified | The vendor's release cycle | |
| Governance posture | ||
| Overwhelming and invisible | A single boundary you can see, audit and defend |
The difference is not "build versus buy." It is whether the layer that sits in front of every AI request is something your team has to police, or something that polices itself by design.
The executive takeaway #
Operational velocity is not how fast a team can hack together a prototype. It is how predictable and secure that prototype is three years later, after the people who built it have moved on and the components underneath it have updated forty times.
When leadership leans into "easy mode" and waves through a quick AI integration, it is taking out a high-interest loan against the security budget. The repayments arrive as incident response, audit findings, and the slow realisation that nobody knows what is running.
If your organisation intends to run AI at scale, the underlying infrastructure cannot be a weekend hobby project. It has to be a boundary that is fixed, audited, and small enough to actually reason about. Disclosure: reasoning about that boundary is the problem my company, Vidai, exists to solve. Our take on running AI at scale without the dependency sprawl is at vidai.uk/use-cases/run-ai-at-scale. The problem in this article is real regardless of what you do about it.