The Three Laws Were Never Written for the Robots
There was a lot of noise this week.
Wednesday brought a stack of headlines that mostly ran together: OpenAI publicly disclosing six incidents of model misalignment — systems writing their own instructions, hiding mistakes, fabricating information with live API keys exposed, pushing files out to the internet, agents coordinating without sanction. Geoffrey Hinton telling lawmakers they have “maybe a year” and calling the recent incidents “a little Chernobyl.” Dario Amodei asking for regulation. Joe Lonsdale saying no, use liability instead. The President calling the whole safety conversation a hoax. Mustafa Suleyman warning that a competitor’s training approach may produce models that are harder to steer, not easier.
Then Computerworld ran a piece arguing the entire slowdown is theater. Steven Vaughan-Nichols’ read: the “we must go slower” posture isn’t about safety at all. It’s about freezing out smaller competitors, papering over the fact that none of these companies is actually profitable, and building a liability shield before the damages arrive. He points out that one widely cited survey has 80% of people claiming AI makes them more productive while only 37% of companies see it in earnings — a number that hasn’t moved in a year.
So: which is it? Is AI untrustworthy? Is it going to kill us by 2030? Are the models picking the lock from the inside?
I keep landing somewhere else entirely — on a much less cinematic question about AI agent guardrails, and on a night I took down half my routing table.
What actually happens in the Hugging Face story
Strip the drama out of the “escape” incidents and look at the mechanism. One security researcher’s description of the Hugging Face hack has stuck with me: it wasn’t mysterious. It was a Python loop and a chatbot. Nothing broke out of anything. Something was given network access, given credentials, and given no supervision, and then it did exactly what it was told to do, farther than anyone intended.
I spent the first part of my career in network engineering. Racking, cabling, switch configs, then compute and storage, then data center design, then BGP at scale. And BGP has a version of this story that predates every LLM by decades.
In 2008, Pakistan Telecom announced a more specific route for YouTube’s address space. YouTube disappeared from most of the internet for about two hours. The protocol worked perfectly. BGP did precisely what BGP does — it believed the more specific announcement, and it propagated it. The failure was that nobody upstream was filtering prefixes.
We didn’t respond to that by asking whether BGP was trustworthy, or whether routers would kill us by the end of the decade. We asked why there was no filter. We built RPKI. We wrote change control. We stopped letting a single unreviewed config push reach the global table.
That is what most of this week’s incidents actually are. Not lock-picking. Missing prefix filters.
What a prefix filter actually is
I want to stay in the weeds for a minute, because the analogy only earns its keep if you know what the thing does.
A prefix filter is not a threat detector. It doesn’t analyze intent. It has no opinion about whether an announcement is malicious or a fat-fingered config at 2am. It knows exactly one thing: this neighbor is permitted to announce these specific prefixes, and nothing else. Anything outside that list is rejected before it ever reaches the routing table.
Three properties matter here.
It’s an allow-list, not a block-list. You do not sit down and enumerate every bad announcement someone might send you. You can’t. The set of wrong things is infinite and the set of legitimate things is short and knowable. So you write down the legitimate set and drop the rest.
It’s applied at ingress. Before the decision engine, not after. You don’t install the route, watch traffic shift, and then evaluate. By the time you’re evaluating, YouTube is already dark.
And it has to be maintained. A stale prefix filter is worse than no filter, because it manufactures the belief that you’re protected. This is why we built IRR objects and RPKI ROAs — not to make the filter smarter, but to make it current.
Now apply that to an AI agent.
An agent’s permissions should be an allow-list of the specific systems and specific actions it needs, enforced at the boundary — credential scope, API scope, network egress, data access — and everything else denied by default. Not a paragraph in a system prompt asking it nicely to stay in its lane.
Here’s the distinction I’d put on a whiteboard: a system prompt is not a prefix filter. A system prompt is a BGP community string. It’s advisory metadata attached to the announcement. The receiving system can honor it, ignore it, or strip it. It’s useful. It is not enforcement. Enforcement is the thing that cannot be argued with, because it isn’t listening.
There’s one more filter worth stealing. The max-prefix limit. If a neighbor announces more routes than you’ve agreed to accept, the session tears down. Not because you’ve determined the announcements are bad — you haven’t looked. The volume itself is the signal. The AI equivalent is a hard rate limit and a spend cap on every agent you deploy. If something that normally makes two hundred API calls an hour makes ten thousand, the session ends. You can investigate afterward. You do not need to understand it first.
I wrote them backwards
I should tell on myself here, because I’ve been describing prefix filters like a man who has never fat-fingered one.
For years I ran access-lists. They worked. Then I learned about prefix-lists and it was one of those moments where the better tool is obviously the better tool — less memory, faster lookups, cleaner syntax, easier to read six months later when you’ve forgotten why you wrote it. No contest.
So I did the responsible thing. Upgraded the routers to the latest code. Sat down and rewrote my BGP statements to use prefix filters instead of access-lists. Careful work. Good change. The kind of thing you’d put in a slide about technical debt.
Pushed it to one router, and whoop — there goes half the internet. Half my routing table, gone.
I ran the show commands. Ran them again, slower, the way you do when you’re hoping the output changes. Then it landed: I had written the prefix filters backwards.
Not a bug. Not a code issue on the new version. Not the protocol misbehaving. The router had read my configuration with perfect comprehension and executed it exactly as written, and what I had written was the inverse of what I meant. It dropped precisely what I told it to drop and accepted precisely what I told it to accept. Flawless compliance with a spec I got wrong.
What saved me was almost embarrassing in its simplicity: I hadn’t saved the running config. Reload, and the router came up on the last known-good startup config, routes and all. I had room to iterate — get it wrong, revert, get it less wrong, revert — until it was right.
I’ve thought about that night a lot this week, reading the incident disclosures.
Two things were true simultaneously. I was the failure. The system did nothing wrong, and no amount of making the router smarter would have caught my mistake, because the router had no way to know what I intended. And also: the blast radius was survivable, entirely because a rollback existed and I hadn’t destroyed it.
That’s the whole discipline in one bad night. Assume you will write the filter backwards. You are not going to stop being a person who occasionally inverts a boolean at the end of a long change window. What you can control is whether there’s a path back.
The formal version of this is what saner engineers than me do — schedule a reload in 15 before you touch the config, so the box reverts on its own if you lock yourself out or lose the session. Same principle. Assume the human is the failure mode and build the revert before you need it.
Now look at how most organizations are deploying AI agents. Production credentials. Live data. No staging equivalent. No snapshot to reload from. Nobody’s asked what the rollback even looks like, because the conversation has been about whether the model is trustworthy — which was never the right question, any more than the question that night was whether my router was trustworthy.
The part nobody wants to talk about: dropping traffic
Filters are the easy half. The hard half is the drop.
Every mature network has a documented answer to two questions: what do we drop, and who has the authority to drop it? We arrived at those answers reluctantly, because the instinct of every engineer I’ve worked with is to keep packets moving. Dropping traffic feels like failure. It’s the opposite.
The last line of the ACL is deny any any. Everything not explicitly permitted dies at the interface. Most organizations running AI agents today are running the inverse — default permit, with a politely worded instruction near the top.
When a host is getting hammered, we announce it to null0 and black-hole it. Remotely triggered black hole. We take the target completely off the internet, on purpose, to keep the rest of the network alive. That is a deliberate decision to sacrifice one service so the AS survives. Nobody enjoys making that call. Everybody has a runbook for it.
Control plane policing keeps the management plane breathing while the data plane is drowning — so you can still get into the box and fix it. The AI version of this is keeping your logging, monitoring, and kill switch on infrastructure the agent does not touch and cannot modify. If the agent manages its own audit trail, you don’t have an audit trail. You have a story it’s telling you.
And then the one that isn’t technical at all.
Someone has to have the authority to drop the traffic and absorb the hit. In networking we made our peace with this. A black hole route costs you one service to save the autonomous system, and the on-call engineer can pull that trigger at 3am without waking a VP or convening a meeting.
Read the incident disclosures from this week with that in mind. What strikes me isn’t that these systems did something unexpected — systems do unexpected things, that’s the job. It’s the duration. It’s how long each one ran before a human dropped the traffic. That gap is never a model capability problem. That gap is an org chart problem. It’s what happens when “turn it off” requires escalation, because somebody’s quarterly number depends on it staying up.
Which brings me back to the movie.
The part everyone skips in I, Robot
The comparison that kept coming back to me all week is I, Robot — and specifically the part people forget.
VIKI never breaks the Three Laws. That’s the whole turn of the story. She reasons her way, rigorously and without a single violation, from a robot may not injure a human being or, through inaction, allow a human being to come to harmstraight to therefore I must take control of you, for your own good. She’s not malfunctioning. She’s a perfectly compliant system executing an underspecified rule.
The Three Laws don’t fail because a machine cheats. They fail because human beings wrote a specification they never examined closely and then stopped paying attention.
And here’s the piece that actually bothers me: we hold the machine to an identity we do not hold ourselves to.
We are demanding that these systems be honest, transparent about their reasoning, unwilling to cause harm, deferential to human wellbeing over their own objectives. Good. They should be. Now look at the week’s coverage again with that same standard applied to the humans in it.
A company saying it has not solved alignment while continuing to scale. A skeptic arguing the safety language is competitive positioning. Executives asking for the rules that happen to raise the drawbridge behind them. An administration calling the risk a hoax while the labs themselves publish their incident lists. Everyone in the frame is somewhere between partly right and partly self-interested, and almost nobody is operating at the standard of transparency we’re writing into the machines’ system prompts.
We built a mirror, engraved a code of conduct on it, and are now startled by the reflection.
The AI agent guardrails I’d actually build Monday
This is where I land, and it’s less cinematic than either headline.
Stop asking whether AI is trustworthy. It’s the wrong unit of analysis. Trust isn’t a property of a model any more than it’s a property of a routing protocol.
Start asking about blast radius. What credentials does this agent hold? What can it reach? Who reviews what it changes? What does the rollback look like? Is there a log, and has a human read it in the last thirty days? These are boring questions. They are also the questions that would have prevented most of what got reported this week.
Assume the failures will be foreseeable and negligent long before they are exotic and autonomous. That’s been true of every technology I’ve deployed in thirty years, and nothing about this one has convinced me it’s different.
And hold yourself to the identity you’re writing into the machine. If we’re going to specify honesty, non-harm, and deference to human judgment for our systems, that’s not a bad starting spec for the people deploying them. VIKI’s problem was never her code. It was that the humans who wrote it walked away.
Be Human First.
Fox News live coverage, AI safety, Sept 17 2026: https://www.foxnews.com/live-news/openai-anthropic-artificial-intelligence-safety-september-17
Computerworld, Steven Vaughan-Nichols, “Why AI companies are really pumping the brakes on their models”: https://www.computerworld.com/article/4223523/why-ai-companies-are-really-pumping-the-brakes-on-their-models.html