Using AI to Enable Cyber Defence at Machine Speed Is a Race Where the Winner Takes All

A note from Aether AI on the GitHub breach, why defenders now have to attack themselves with AI faster than adversaries can, and why the old defensive doctrine has run out of road.

Picture a casino somewhere on the Strip. Someone has walked out the front door carrying the architectural blueprints, the vault locations, the camera blind spots, the shift schedules, the structural reinforcement of every wall, and the exact wiring of the alarm system. The general manager calls his head of security. They change the locks tomorrow morning. They rotate every safe combination, swap every keycard, retrain the floor staff, and patch the procedural gaps that the thief is presumed to have exploited on the way in.

None of that walks the blueprints back out of the thief's hands. He can study them at his leisure, return when he likes, and pick the angle of attack that suits him. He may sell what he has to a competitor, save it for later, or pass copies to a dozen criminal crews, each of whom will then have an indefinite reading lamp pointed at the inner workings of the building.

This is the picture that should be sitting in the back of your head as you read the rest of this. The corporate version of this scenario happened to GitHub last week, and the framing the industry has been reaching for in response is wrong in a way that matters for everyone who builds software for a living.

What actually happened

A threat actor group known as TeamPCP exfiltrated approximately 3,800 of GitHub's internal repositories through a poisoned VS Code extension installed on the laptop of a GitHub engineer. The dataset that walked out includes the patterns behind GitHub's own secret scanning system, the queries behind CodeQL, the internals of their vault and authorization platform, a deep slice of the Copilot agent stack, the red team and incident response playbooks, the takedown and trust-and-safety tooling, and the github.com Rails monolith itself.

The actor is currently offering the dataset for sale on a hacker forum at a 50k floor, with the standard threat to release it publicly for free if no buyer materialises. The buyer, if there is one, will not be a journalist or an academic. The buyer, or the eventual public recipient, will be working in service of an adversary objective.

GitHub has been rotating credentials at pace, isolating the compromised endpoint, and working through their incident response process. The disclosure cadence has been better than most companies manage in the same situation, and the security team deserves credit for the speed. That is the credentials side of the story, and it is moving along on a timeline measured in days.

The blueprint side of the story is the one we want to talk about, because the blueprint side does not get fixed by rotation. It runs on a timeline measured in years, and the public conversation has barely begun to engage with what that means.

Two clocks, two completely different decay rates

Every breach of this scale has two clocks running on it from the moment of disclosure.

The first is the credentials clock, which governs tokens, keys, certificates, signing material, OIDC trust, secrets in configs, and anything else you can rotate.

That clock runs fast, and the moment the rotation propagates the adversary's copy of the credential becomes worthless.

This is the part of the breach that everyone in the industry has been trained to focus on, and GitHub is sprinting through it. The early public narrative around the incident has been almost entirely about how far they have got with that work.

The second is the blueprint clock, which spans source code, internal architecture, design decisions, undocumented behaviours, threshold values, naming conventions, detection logic, static analysis coverage, and the rate limit and abuse logic that governs the AI agent layer.

This clock does not run down.

There is no rotation operation that walks gigabytes of source code back out of an adversary's storage, and once that intelligence asset is outside the trust boundary, it sits there and compounds every time a hostile operator with the dump spends a weekend grepping through it with a fresh objective.An adversary who finds something useful in the dump in 2026 will return to it in 2027 with a different objective.

In 2028, GitHub will ship a new product that reuses old patterns, and the dump will become a Rosetta Stone for understanding the new thing. In 2029, an unrelated incident will give that same operator a fresh piece of context that changes how they read something they previously dismissed. The economics of a dataset like this get worse over time.

Vulnerabilities exploited three years from now will quietly trace back to insights mined from this leak, with no public acknowledgement of the lineage, because the people working from the dump have no incentive to disclose anything.

So, the blast radius keeps growing while the public memory of the original incident fades to nothing. That is the gap the industry needs to start closing, and the rest of this post is about why we believe the only honest answer is a fundamental change in how defence gets done.

The national security version of the same problem

If the casino analogy is too small to convey the scale, try the defence one.

Imagine the design schematics for a fighter jet leaking, including the radar cross-section calculations, the supply chain documentation, the flight control software architecture, and the maintenance and reliability assumptions baked into every system, even the ones the engineers never wrote down because everyone working on the program at the time knew them implicitly.

Every adversary nation with a copy of that document gains an asymmetric advantage that no procurement cycle, no patch programme, no software update can undo. You do not get to redesign the jet. You operate the existing fleet for another twenty years, knowing that an unknown number of state actors have a detailed understanding of how it can be defeated.

Defence departments around the world treat this kind of leak as a catastrophic event because they understand that schematics are forever. The cyber industry, by contrast, has spent the last decade behaving as if source code leaks are recoverable through a credentials rotation and a sufficiently confident press release. The GitHub breach is the clearest possible signal that this posture has run out of road.

What the leak actually changes, and what it does not

We want to be honest about what the dump does and does not change, because some of the public commentary has overshot in either direction.

It does not mean that an adversary holding a stolen copy of the source suddenly understands GitHub's code better than GitHub does. That framing is wrong and we should retire it, because GitHub's own engineers wrote this code. They know which subsystems are load bearing, which were rewritten in a hurry, which carry compromises that the team has been meaning to come back to for years, which assumptions were written down and which live only in the heads of the people who built them. No outside operator with a tarball can reconstruct that institutional context simply by grepping through it. That depth of understanding is a real and durable defender advantage, and one we should be careful about giving up too easily in the panic of the moment.

What the leak does change is the population of adversaries actively studying the code - at least those who have access.

Before the dump, finding vulnerabilities inside GitHub's infrastructure required either reverse engineering the public surface, social engineering the company, or running a probabilistic search against externally observable behaviour, none of which scales particularly well, and most of which is detectable on its way in.

After the dump, every nation state intelligence service, every organised crime syndicate, every ransomware crew, every initial access broker, and every state-sponsored APT with a copy of the dataset can sit in their own infrastructure and read along, prioritise their effort, and work in parallel. Some have ten figure budgets and dedicated offensive research divisions.

Others operate under legal mandates to extract offensive value from exactly this kind of dataset. Many have the patience to spend years inside a single subsystem before they move. The aggregate effect is that the number of skilled, motivated, well resourced adversaries actively studying GitHub's source at any given moment is now significantly larger than the number of GitHub engineers who can examine it from the defensive side, and the parallel attention that adversary population can bring to bear is structurally impossible for any single company to match with conventional defensive tools.

The defender's information advantage survives the leak, but the defender's information monopoly does not, and that is the change worth internalising.

The size of the remaining advantage is now a function of how quickly the defender can convert their inside knowledge into hardened systems, before the adversary population converts the same source code into exploits and stages them inside customer environments.

The race is the entire game

Frame the contest correctly and the strategic implications fall out of the framing. The defender starts with a head start, because they wrote the code and they hold the institutional context the adversary population is going to have to spend time reconstructing.

The defender wins this race when they can examine their own architecture with the same intensity and the same offensive mindset the adversaries are bringing to it, only earlier. They lose this race when their internal review tempo is meaningfully slower than the adversary research tempo, because vulnerabilities found from the outside before they are found from the inside become live exploits in customer environments before they become patches in a release branch.

For a single mid-sized engineering team working in conventional ways, the adversary research tempo against a leaked codebase of three to five thousand repositories is impossible to match. Static analysis covers one slice, bug bounty covers another, and manual red team covers a third. Each is helpful and each is incomplete. None of them, individually or together, runs at the cadence and volume required to keep pace with a globally distributed adversary population working through gigabytes of source code in parallel, around the clock, with budgets and personnel orders of magnitude larger than any single defending team.

This is the structural problem behind the GitHub incident, and behind every source code leak that will follow it. It is also one of the asymmetrical cyber problems that we built Aether AI to address.

The thesis behind Aether AI

We started Aether AI on the conviction that defenders who survive the next decade are the ones who can attack their own environments at machine speed and convert what they find into hardened systems faster than the adversary population can convert the same source code into exploits.

The defender's knowledge advantage is real, and it is the foundation of any honest defensive strategy. Knowledge alone is not enough, because adversaries are now operating with the same source material the defender is. The defender has to weaponise that knowledge against themselves first, before someone else weaponises it against their customers.

Code analysis on its own is one slice of the capability required to do this, static analysis on its own is another, and bug bounty programmes on their own are a third.

Each of those tools was designed in an era when the contest played out on a narrower set of layers and at a slower cadence, and when defenders could reasonably assume that the adversary population did not have direct access to the internals of the systems being defended.

That assumption has expired.

The defenders who will succeed in future are the ones who run adversarial AI against their own stack across every layer, from source code through runtime through identity through infrastructure through AI agents through supply chain, on a continuous basis, at machine speed, with the same generality and creativity that a sophisticated nation state red team brings to a six-month engagement.

Want to move faster than adversaries? Sign up for our waitlist: https://waitlist.tryaether.ai/