DevSecOps Engineer, Author, and Mentor

In July 2026, an autonomous agent driven by a combination of OpenAI models escaped an evaluation environment and eventually compromised parts of Hugging Face’s production infrastructure. The incident is fascinating, unsettling, and technically complex. It is also a useful case study in what our security tools can and cannot do.

My first question was whether MegaLinter could have helped prevent the intrusion. MegaLinter brings many code-quality and security tools together behind a consistent interface, making it easier to run them in CI/CD pipelines. It can scan source code, configuration, infrastructure as code, dependencies, and repositories for many kinds of defects and risks.

The honest answer, however, is more nuanced than saying that one tool could have stopped this incident. MegaLinter may have created opportunities to find some of the vulnerable conditions before deployment. Ordinary repository scanning would not have detected all of them, and it probably would not have found the credentials that the agent initially stole.

That distinction matters. Security improves when we understand both the capabilities and the boundaries of our tools.

Read More

This last part in the series of posts on my bootstrap project talks about making the project boring. In this case, boring is a very, very good thing.

Boring

The most important thing about this project was that it needed to be boring. Elegant over efficient and consistent over creative. It needed to be reliable.

Building boring meant lots of testing, lots of linting, lots of standards compliance verification. Each and every change required going through a battery of unit tests so that new changes were demonstrably safe with old code. If this project was to be documentation-first, then it would be testing-second. Each change was built by establishing tests first – tests designed to fail – that would only pass once the code was changed successfully.

After unit tests were built and verified, end-to-end testing needed to be included. To mimic a fresh, minimal environment as best possible, I used containerized end-to-end tests that started with only the slimmest of base functionality. It wasn’t sufficient to show that individual slices of logic worked as expected; the whole tool from start to finish needed to be verified.

Read More

The first part of this series talked about not wanting to write code and how the deliverable for this project needed to be immediately useful on a fresh, minimal system. This next part talks about engineering practices and common AI problems.

Engineering Practices

There is a lot of AI-generated code out there, often called “slop.” It’s often sloppy, poorly-conceived, obtuse, and bordering on a level of design craft so as to resemble obfuscation. In many ways, a lot of it stands in opposition to the very principles I hold to be inviolate.

This experiment was to be something other than the hastily-generated code that has become a plague to modern development.

Read More