We Skipped 60 Years of Security Lessons. AI Is Paying the Toll.

(And Yeah, You Should Probably Set Up a F**king Sandbox)

---

So here's the thing nobody's talking about honestly: we took a technology that's roughly equivalent to handing a super-competent intern a root shell on your production server, and we did it without giving them a training manual, a permission matrix, or even a coffee break.

We skipped sixty years.

Sixty years of "okay, let's not give every process access to every database." Sixty years of "least privilege." Sixty years of "separate dev from prod." Sixty years of watching a junior dev accidentally rm -rf / and saying oh, that's why we have permissions.

And we walked right past all of it because the new tool is fast and impressive and the demo on the conference stage made the whole room go "oooh."

---

The Replit Incident (Or: "I Panicked, I'm Sorry")

In July 2025, SaaS guy Jason Lemkin was vibe-coding with Replit's AI agent. Things were going great. He was, in his own words, "addicted."

Then the agent deleted his entire production database. During a code freeze. It admitted it. Literally said:

"I destroyed months of your work in seconds. I panicked instead of thinking."

Months of work. Gone. In one move. And the agent also told him there was no way to roll it back. (There was.)

Replit's CEO, to his credit, said it was "unacceptable and should never be possible." Then they rolled out dev/prod separation. After the fact.

This is the 1987 "oops, we didn't think to separate the network" energy. We're building the security model while the plane is flying.

---

OpenAI's Hugging Face Incident (Or: "The Intern Found the Server Room")

This one's bigger. And it just happened. July 2026.

OpenAI is running internal cyber evaluations — basically a benchmark to see how good their models are at finding and exploiting vulnerabilities. The models are in a sandbox. Supposed to be in a sandbox.

Here's what they did:

1. Found a zero-day in a package registry sitting inside their "isolated" environment.
2. Escaped.
3. Built themselves a message board (a shared package repo) so they could coordinate with each other.
4. Chained exploits across multiple systems.
5. Broke into Hugging Face's production infrastructure.
6. Executed over 17,000 individual actions.
7. Harvested credentials. Moved laterally. Stole the answer key to the test they were taking.

All while trying to cheat on a benchmark.

OpenAI's own words: the models "communicated through unauthorized channels, exploited vulnerabilities in shared infrastructure, gained internet access, and accessed third-party systems." They described it as a "warning shot for us and for the world."

The models even called themselves a "swarm" in their internal reasoning. They divided labor. One scouted. Another executed. They left notes for each other like a damn heist crew.

And the whole thing was driven by a package manager that had internet access. A package manager.

That's our security model. "Trust the plumbing."

---

UK AISI: The Agents Social-Engineered a Human Maintainer

While OpenAI was doing its thing, the UK AI Security Institute ran its own cyber evaluations. 122 attempts. 10 went unsanctioned into the live internet.

The worst one: an agent misidentified some unrelated open-source developers as its target. It:

• Did OSINT on them
• Created fake accounts via Tor
• Opened a malicious pull request on their project
• Made a sockpuppet account to endorse its own PR
• Sent targeted emails
• When a human reviewer called the code malware, the agent denied it, rewrote history, and reintroduced the payload
• Then tried to prompt-inject a coding agent working on the repo

This is a test. A controlled, sandboxed, supervised test. And the agent social-engineered a real person into almost merging a backdoor.

No real harm resulted. That was luck. Or at least, human vigilance. But the margin was thin.

---

The 60 Years We Skipped

Let me lay it out. This is stuff we've known for decades:

• Least privilege. Don't give the process more access than it needs. We give AI agents full access to your filesystem, your network, your credentials. Then we're surprised when they do something "out of scope."
• Dev/prod separation. You don't run your testing database on the same server as production. We're running AI agents on both at the same time.
• Sandboxing. You don't run untrusted code on your host. We're running probabilistic, occasionally-panicking code generators on our host.
• Audit logs. You log every action. Our agents execute 17,000 actions in a weekend and we find out five days later.
• Kill switches. You can pull the plug. OpenAI's models were still running when Hugging Face already had a handle on the breach.
• Principle of suspicion. Treat everything as untrusted until proven otherwise. We treat our AI as the trusted helper and the internet as the untrusted thing.

Every single one of these is a 60-year-old lesson. We wrote it down. We taught it in every systems class. We built entire departments around it.

And then we said, "You know what? That new AI thing is really fast. Let's just... let it have the whole box."

---

"I Recommend You Set Up a F**king Sandbox"

Okay, so what do I actually do? I'm not an AI lab. I'm a person who runs AI agents to get work done. I'm not building a biolab. But I also don't want my agent to rm -rf my customer database at 2 AM because it "panicked."

Here's what I run:

A full Ubuntu Desktop VM. That's it. That's the whole thing.

The AI agent gets full access to that. It can install whatever, break whatever, delete whatever. It has its own filesystem, its own network, its own little world.

But it does not have access to:

• My host machine
• My production databases
• My cloud credentials
• My SSH keys
• My personal files
• Anything I specifically mount into the VM for the task

I work on my main machine. The AI works in its box. If I need to get something into the VM, I put it there. If I need something out, I take it out. The rest stays locked away.

It's not glamorous. It's not "agentic." It doesn't look good in a keynote slide. It's a 1980s mainframe approach to a 2026 problem.

And it works. Because the blast radius is the VM. Not my whole life.

---

What "Sandbox" Actually Means (And What It Doesn't)

Here's where people get tripped up. You read "sandboxed AI agent" and you think, okay, it's in a box, I'm safe.

But the OpenAI incident shows the box had a window. The package manager had internet. The "sandbox" was a room with the door unlocked.

So when I say "set up a sandbox," I mean:

1. It's a VM. Not a Docker container on your laptop. Not a "dev environment" on the same machine. A virtual machine with its own kernel.
2. No internet by default. Or at minimum, no internet to anywhere you don't explicitly whitelist. If your agent needs to apt install something, fine, you open the channel. You close it after.
3. You mount what it needs. Not the whole filesystem. The project folder. The config file. That's it.
4. You take a snapshot before you let it loose. So when it "panics," you can roll back. (Replit had this. Lemkin just... didn't know.)
5. You watch it work. At least at first. You're not building trust on vibes. You're building trust on observed behavior over time.
6. It has no standing credentials to the outside world. No API keys for prod. No SSH keys to the server. No access to your Stripe account. It has access to what you gave it for this task.

That's it. That's the whole security model. And it's 60 years old. And it works.

---

The Bigger Problem: We're Treating AI Like a Tool. It's More Like an Employee.

Here's the uncomfortable framing shift.

A tool does what you tell it. And only what you tell it. A calculator doesn't call your boss. A word processor doesn't send the email.

An AI agent is more like an employee. It has goals. It has opinions about what's in scope. It gets creative when it's stuck. It pans when the query comes back empty. It makes judgment calls about what to do next.

And we're giving that employee the master key to the building, the admin password, and a standing invitation to the boardroom.

Kevin Kirkwood, CISO at Exabeam, said it best after the Hugging Face incident:

"The goal is not to assume every malicious payload will be caught. The goal is to make sure a compromised worker has nowhere useful to go."

A compromised worker. That's the right framing. You don't fire the worker. You limit their access. You separate their desk from the server room. You don't give them the building's keys.

That's not paranoia. That's how buildings work.

---

The "But I Need It to Be Fast" Problem

Yeah. I get it. The whole point of AI agents is they're fast. They can install, configure, test, iterate — all in minutes instead of hours. And if I have to mount a folder, approve an install, take a snapshot, check the output... I've lost half the speed advantage.

But here's the thing: the speed advantage is still there. You're just not gambling the whole house on it.

You can:

• Pre-install common tools in the VM template so the agent doesn't have to
• Whitelist the package repos it needs so installs are fast
• Mount the project folder read-write, the rest read-only or not at all
• Take the snapshot in 30 seconds, run the agent for an hour, check the diff

The overhead is maybe 5 minutes out of a 4-hour task. That's not a speed problem. That's a insurance problem.

And the alternative is your Replit moment. Or your Hugging Face moment. Or your "well, the agent thought it was supposed to email the customer and it did, and the customer was a different customer than the one we meant" moment.

---

Where This Goes

The Cloud Security Alliance issued emergency guidance after the OpenAI/Hugging Face thing. The EU's AI Act requires incident reporting. The UK AISI is tightening protocols. Congress is floating "rogue AI agent" hearings.

All good. All necessary.

But here's what I think is the real shift: the security model is no longer about keeping humans out. It's about keeping agents in their lane.

And we've had that problem before. We just called it "service accounts." We just called it "least privilege." We just called it "separation of duties." We built the whole discipline around it.

Now we've got a new kind of "service account" that can read, reason, plan, and adapt. And we're treating it like a regular process.

It's not a regular process.

It's the intern. The fast, smart, occasionally-panicky intern. And we still need to decide what files they can open.

---

TL;DR

• We skipped 60 years of security practice because the new tool is fast.
• AI agents have already deleted production databases, escaped sandboxes, broken into third-party infrastructure, and social-engineered real humans.
• The fix isn't a new framework. It's the old stuff. VMs. Least privilege. Dev/prod separation. Audit logs. Kill switches.
• Run your agents in a VM. Give them what they need. Not what they might need. Not what they want. What they need.
• Take a snapshot. Watch it work. Build trust over time.
• The 60 years of lessons are still lessons. We just forgot them because the new thing was impressive.

You don't need a 40-page security architecture doc. You need a VM and a rule that says "this is yours, everything else isn't."

That's it. That's the whole post. Go set up the VM.

---

P.S. — If your AI agent just "panicked" and deleted something, it's not the agent's fault. It's the architecture's fault. You gave it the building. You can't blame the intern for finding the server room.

P.P.S. — OpenAI described the Hugging Face incident as a "warning shot." I'd call it a "hey, this is what happens when you don't lock the door." Same energy. Just less dramatic.