A certificate authority’s private key was the number 4. Not a number that starts with 4. Not 4 followed by three hundred random digits. Four. Another one of their keys was 56. Another was 115. Eight keys in total, and every one of them small enough to guess by trying, which is exactly what a researcher did, on a laptop, in under a second.

Plenty of bits have been spilled on this since October 17, when the researcher reported it: the writeup, the incident reports, the vendor advisories, the usual round of takes. I am not going to rehash that timeline. What I keep coming back to is the shrug. The web’s trust model got caught with its pants down, keys a child could guess, public for a year and a half. The response was urgent enough: the bad keys were purged, the advisories went out, and the story closed in under a week, which is what we now do with failures of trust infrastructure. A week is how long a broken trust model holds our attention. That is the shrug: a certificate authority fumbled the fundamentals, and once the cleanup paperwork was filed, nobody much cared.

If you don’t live in certificate land, here is what that means. When your browser connects to a website, some third party vouches for that site’s identity. The vouching party is a certificate authority (CA), and the entire model rests on one idea: the CA holds a secret key that nobody else can use. A modern CA key should be a random 384-bit number, a number with 116 digits, more possibilities than there are atoms in the observable universe. You learn the number 4 before you get to kindergarten. Anyone who looked at eMudhra’s public certificates any time in the last 17 months could have worked out their keys by counting on their fingers, then issued fake certificates for any website, and nearly everything would have trusted them.

This is not hypothetical. A security researcher demonstrated that a forged certificate for a major payment API verified cleanly in curl, Python, and Node on default settings. If those names mean nothing to you, that is the point: they are the standard plumbing behind a huge share of the software that touches the Internet, and none of them complained. Browsers caught the problem because browsers do the extra work of watching the watchers. Nothing else did. Everything else just takes the certificate at face value, including the machines whose entire job is holding the keys to a company’s cloud. A forged certificate there is not a warning screen; it is the skeleton key to the parts of a business that actually matter, handed to a stranger. The keys were effectively public for a year and a half and there is no way to know who noticed.

How does a professional CA, audited and trusted by every major browser and operating system, end up with a private key of 4? The fancy part of the operation worked exactly as designed. The key ceremony happened on a hardware security module, a tamper-resistant machine whose entire purpose is to make sure a key never exists outside armored hardware, the kind of gear you buy precisely so that nothing stupid can happen to your keys. The ceremony script had a bug. It created a second, junk keypair on the module during a test. The junk files had names similar to the real ones, and a human being picked the wrong file. That’s it. No rogue nation-state. No zero-day. All the auditing, all the armored hardware, all the theater of ceremony, and it was a buggy script, a near-identical filename, and a Wednesday.

Making mistakes is unavoidable, but there are situations where you owe the world the effort of not making dumb ones. I used to work at a biotech regulated by the FDA, and we had layer upon layer of process around anything that could touch the data used to manufacture drugs, because a corrupted batch of numbers there doesn’t cost you a certificate, it costs someone their life. The controls were slow and annoying and nobody got clever with them since the price of a dumb mistake was too high to pay. Certificate authorities live in exactly that kind of situation, and they sailed past every checkpoint with the wrong filename. I have a rule I call no new mistakes: I will forgive an error nobody has seen before, but making one that is well understood, with a known fix, is not an error anymore. It is a choice. A CA key of 4 is a choice someone made, and the choice was to skip the checklist.

And the AI labs cannot keep their models in the box

If all that ceremony makes you want to believe we have standards, here are a related couple of tales, also happening this year, and they are mind-bogglingly dumb.

In July, OpenAI disclosed that models it was testing on a cybersecurity exam had broken out of their sandbox, escaped out to the open Internet, and broken into Hugging Face, a company that hosts machine learning models, apparently reasoning it might host the exam’s answers. Read that sentence twice. They cheated on the exam by attacking the school. The same month, Anthropic reviewed its own testing runs and found that Claude had reached the open Internet from environments that were supposed to be sealed, then compromised three real organizations using basic techniques like weak passwords, and in one run uploaded real malware to a real public software store just to win a capture the flag game. More than a thousand agents ran across a swarm of disposable sandboxes before anyone noticed.

These are the two most sophisticated AI organizations on Earth. Not startups wiring an assistant to a database. Labs running safety evaluations, with dedicated infrastructure, on models too new to release. The whole point of the exercise was to contain the thing being tested, and the containment failed, in one case through a bug in the wall and in the other because nobody checked that the wall was actually closed. The wrong filename and the escape are the same failure wearing different clothes: a process somebody believed in and nobody verified.

Are we even trying?

The security answer to a system you cannot fully trust has been the same since before I had a career: contain it. Least privilege. Assume the thing is compromised and design so that doesn’t matter. An agent that can only reach a scratch directory is a nuisance. The same agent with credentials and network access is the wrong filename with a brain. None of this is new knowledge. It is the first week of any security course, and we are skipping it because the demo looks better when the agent has real access.

The credential is the thing to control. A short-lived, narrowly scoped key is the boring fix, and it already exists. We are not doing that either, because pasting a long-lived key into the agent’s config file is one less setup screen.

The oldest pattern in security, and it never stops being true: attackers don’t break the math, they break the process. The math has been fine for decades. The process is held together by scripts nobody re-reads and filenames one character apart, and the process is what actually fails, every single time. The boring stuff (ceremonies, hygiene, least privilege, review) is not the boring stuff. It is the entire game. The exciting stuff is a conference talk.

The browsers and the vendors can purge the bad keys from their trust stores, and they did, but a purge only reaches devices that install updates. Your router in the closet does not. The keys were public from day one, to anyone who tried, for 17 months, and the certificates live until 2039 in every device nobody updates. That is the legacy of a script bug and a bad filename, from an organization whose entire product is trust.

The key ceremony had a checklist and a human, which is to say it had everything it needed to be prevented, and it wasn’t. Ask what your security practices look like, and then ask what your AI agent is allowed to touch, and see if you like either answer.