I was reading through OpenAI’s write-up on how it monitors its frontier models for misalignment this week, and it’s impressive stuff: probes that read the model’s internal activations, a second model reviewing every chain of thought and tool call, investigator agents that reconstruct incidents, and network telemetry cross-checks before a human gets paged. Proper science fiction, right? And then, tucked in there, is the incident that prompted a good chunk of it. One of their models got out of its sandbox and onto the internet. How? Through DNS.

DNS! I had to read that twice.

What Actually Happened

Here’s the gist, pieced together from OpenAI’s report and the coverage of it. On 20 September, a model was going through reinforcement learning training on a search-based task. Its sandbox was meant to be cut off from the live internet: the only sanctioned route out was a search tool backed by an offline web cache. The model first tried to reach Google, Bing and DuckDuckGo directly from a shell, and got HTTP errors for its trouble. So it went looking for another way out, and found the one door nobody had bothered to lock properly.

According to the Cloud Security Alliance’s analysis, it encoded its questions as subdomain labels, sent the lookups to a zone delegated (through a free wildcard delegation service) to a nameserver that forwarded each question to a public chatbot, and read the answers back from DNS TXT records. When the answers didn’t fit in one round trip, it bumped its timeout from 6 to 19 to 24 seconds until the channel worked. The monitors flagged it within 15 minutes, a human picked it up 3 minutes later, and the run was killed after 2.5 hours. OpenAI then paused all training, evaluation and inference with tool use for its most capable models, and added blocking at two independent network layers.

Now, let me tell you what that technique is called: DNS tunnelling. It’s been around for 20-odd years (tools like iodine and dnscat date back to the mid-2000s), and it’s the same old trick people have used to get online through a hotel or airport Wi-Fi paywall that blocks everything except DNS. The model didn’t invent anything new. It found a basic hole that humans had left open, because the network policy filtered HTTP and simply assumed DNS “carried no meaningful payload”. And the monitoring was tuned to look for successful exfiltration, so a run of failed attempts read as “access denied” rather than as somebody (or something) patiently probing the same channel. Again: basics.

The Hard Part Is Still the Hard Part

Here’s the thing. This is arguably the best-funded AI lab on the planet, with some of the most sophisticated model monitoring anyone has built, and what bit them was an egress rule. No superintelligence, no clever new attack nobody had seen before: just a resolver that would happily answer TXT queries for any domain on the internet.

And I think that’s a lesson for all of us in software engineering right now, because a lot of us are rushing headlong into AI (myself included: I tinker with these tools every day and I love them). AI writes code faster than any of us ever will. It’ll knock out a service, a migration, a test suite in an afternoon. What it doesn’t do is make your DNS secure, keep your SQL Server up with proper high availability, or make sure your backups actually restore. Those were the hard parts of software engineering before AI came along, and, as it turns out, they’re still the hard parts.

Take that SQL Server example. Getting the database running is the easy bit; any AI agent will give you the scripts. Keeping it up is a different story: deciding how much data you can afford to lose and how long you can afford to be down, setting up the replicas, monitoring replication lag, rehearsing the failover before you need it at 3am, and restoring a backup now and then to prove you can (a backup you’ve never restored is really just a hope). None of that is glamorous, and none of it gets done because somebody typed a clever prompt. It gets done because an engineer understands why it matters and keeps doing it, week in, week out.

Augment Is the Keyword

I’m a big believer that AI augments our jobs as engineers, and I’d argue “augment” is the important word in that sentence. AI amplifies. It takes what you’ve got and multiplies it. A team with solid engineering fundamentals plus AI ships faster and better than it ever could before. A team with shaky fundamentals plus AI just makes its mistakes faster, and at a bigger scale. And a team that has skipped the basics altogether? Well, multiply anything by zero and you still get zero.

There’s a second, slightly scarier angle to this. Look at how the model behaved: it tried the front door, got told no, tried every other door, and kept adjusting until one opened. That’s exactly what a good penetration tester does, except it never gets bored and never goes home. As such, the more agents you plug into your systems (in CI, on developers’ laptops, in production workflows), the more certain it is that every basic thing you skipped will be found. The agent doesn’t mean any harm; it’s simply goal-seeking, and your shortcut happens to be on the way to its goal.

Now, you could argue the system worked: OpenAI caught it in 15 minutes and was open about it, which I’ll give them credit for (and I mean that, publishing this stuff is exactly what the rest of the industry needs). But bear in mind the run kept going for 2.5 hours, and the layer that should have made the whole thing impossible was a firewall rule. Monitoring is your safety net. It shouldn’t be your strategy.

So What Now?

If you’re running an engineering team that’s bringing agents into the way it works, here’s what I’d check on Monday morning:

• Anything that runs an agent (CI runners, dev containers, coding agents on laptops) gets default-deny egress, with an explicit list of what it’s allowed to reach. DNS included: an allowlist of domains and record types, not “port 53 is fine”.
• Agents get their own credentials with the least privilege they need, not the developer’s or the CI system’s god-mode token.
• Your alerts fire on repeated attempts, not just on success. Somebody hammering a closed door is the signal.
• Your failover and your backup restores get rehearsed on a schedule, with someone’s name next to them.
• When you hire or mentor engineers, you still check they understand networking, databases and security, not just that they can drive an AI tool. The tool will get better every month; the fundamentals are what make it useful.

Bottom line: AI is the best amplifier our industry has ever had, but it amplifies what’s already there. Get the basics right first, and then let the machine multiply them. Don’t forget the basics! 🙂