When I was a kid I thought I was going to grow up to be an automotive engineer. I read Car and Driver cover to cover every month. One ad that stuck with me for 30 years was for a brand of tires. The Pirelli "Power is Nothing Without Control" campaign. A barefoot sprinter making a tight corner, angled so steeply he's nearly horizontal to the ground. Raw capability at its limit — and the only thing keeping him from becoming a skid mark is the interface between his foot and the ground. That interface is what this talk is about.
I lean toward the Cassandra end of the spectrum when it comes to AI. Not doom-saying — just hard-won skepticism from watching agents fail in specific, instructive ways:
- Ignoring instructions silently
- Generating tests that pass but don't actually validate the code
- Skipping git pre-commit validations
- Confidently doing the wrong thing at machine speed
The goal of this talk isn't to slow you down. It's to give you the grip that lets you go faster safely. Just as we can't rely on the engine to control a car's behavior, we can't rely on the coding agent to police itself. This talk a mix of a sermon, a how-to, and demo of what I've built and learned so far.
Walk through concrete failure modes with real examples or brief demos. The audience needs to feel why "just trust the model" isn't an engineering strategy.
The agent isn't malicious. It's a very fast, very confident intern with no judgment about what it shouldn't touch. The question isn't "how do I build Fort Knox?" It's "how do I make sure the intern can't accidentally email the client list, delete the production database, or commit my AWS credentials?"
These are solved problems. The tools are old. The threat is new. The gap is that we forgot the tools existed.
Controls that live outside the agent's reach aren't a constraint on AI power — they're what makes that power usable. Just like the tire.
This is a swiss cheese model of quality and security. No single layer is perfect. Stack enough layers and the holes don't line up.
Tell your agents to do the right thing — and then enforce it from outside the agent's reach.
The instructions without enforcement is a gentleman's agreement. The enforcement without instructions sends your agent into a doom-loop. You need both.
This is not all or nothing.
High Supervision <————————————> High Autonomy
- High supervision: You're essentially pair programming. You are the guardrail. Fewer external controls needed, but the cost is your attention.
- High autonomy: You've spun up an agent and gone to bed. This is when the controls let you sleep at night.
Most developers slide back and forth depending on the task. The guardrails mean you can make that choice fluidly.
Agents don't accumulate judgment the way humans do — every session they're essentially new again. The guardrails compensate for that lack of accumulated trust.
Make unauthorized actions structurally impossible, not just forbidden.
The best security control is the one you'll actually use.
"The best time to exercise is the time you're most likely to do it."
Web developers have never treated security as a first-class concern, which means most exploits are elementary-school-level. It doesn't take much to protect ourselves.
macOS VM (Apple Virtualization)
- ✅ Full isolation, can snapshot and clone
- ✅ Clone a VM, try installing a package, throw it away if it breaks — you missed step 11 of 20? Clone again and start over
- ❌ Heavy — each VM is ~30GB
- ❌ Can't run Docker inside the VM (Apple only allows one layer of virtualization)
Linux ARM VM
- ✅ Can run Docker inside the VM — fully isolated from Docker on the host machine
- ✅ Same snapshot/clone experimentation benefits
- ❌ Pain to find ARM builds
- ❌ Shared file system is slow, really shows up on git operations
Sandboxed User for Cursor (most likely to be adopted)
- ✅ Low friction — Fast User Switching makes it nearly seamless
- ✅ Separate desktop, both sessions stay alive simultaneously
- ✅ Setup is an afternoon of work, then zero daily friction
- ❌ Side-channel leakage — file paths on the main account are still visible even if contents aren't (names of clients, infrastructure structure, which secrets manager you use)
- How to set up: create a user, strip permissions on your main account's sensitive directories (
chmod o-rwx -R /Users/$YOUR_MAIN_USER_NAME), install Cursor under the new user
Demo opportunity: show Fast User Switching live — switch to Cursor user, show it can't access SSH keys, switch back in under 10 seconds.
- Docker/Podman — cleanest story on paper. Better suited to headless/CLI agents (Claude Code, cursor-cli) than GUI tools like Cursor. More realistic for CI pipelines than interactive dev.
- Firejail — lightweight sandboxing for individual processes. Restricts filesystem, network, system calls without a full VM. The "I just want guardrails on this one process" option.
- Sandboxed user — same approach and tradeoffs as macOS.
- systemd-nspawn — more native container namespacing, but niche.
- Virtual Machines — my preferred solution. Use Cursor GUI effortlessly. Can have its own Docker daemon separate from the host machine's. Share file system is fast enough for git operations. VM doens't have git's private SSH key, so fetching and pushing is not an option.
- WSL2 is the honest answer. But the layering of WSL2 + Docker + your project is a Jenga tower of "what's actually seeing what." Best of luck.
Most MCP servers are designed to run as bare-metal Node.js processes with full system privileges. The security model is an afterthought, if it exists at all.
"Have you ever seen
npx $SOME_QUESTIONABLE_LIBRARYand thought, 'Ehhh, I don't know'?"
Every developer in the room will recognize that hesitation. It has a real cost — you're not just skipping a sketchy library, you're potentially skipping the tool that would have saved you hours.
The VM becomes your container. Clone it, run npm install, try the MCP server, throw it away if you don't like it. Instead of 45 minutes of containerization work, it's 5 minutes.
The reframe: Sandboxing isn't just a defensive posture. It's an offensive one. It removes the friction that stops you from evaluating good tools.
There was a learning curve for all of these. But once you learn them, the cost of experimentation collapses. The developer who can confidently run npx $SOME_QUESTIONABLE_LIBRARY in a throwaway VM is moving faster than the cautious developer who skips it on bare metal.
Provide read-only bind mounts to the container, and read-write mounts only for what you want the agent to be able to change.
- Rails applications: Easy. Strong conventions mean the file structure is predictable. The agent can write to
app/andspec/, everything else is read-only. Demonstrable in ~10 lines of docker-compose. - JavaScript/pod structures: Harder. Build tools want to write everywhere. Fine-grained bind mounts become a research project. May require Linux ACLs or custom seccomp profiles — and at that point you've lost most of your audience.
What a pre-commit hook is (one sentence for those who haven't used one): git lets you run a script before every commit, and if that script fails, the commit doesn't happen.
The key insight: Make the .git folder read-only from inside the container or VM. All git commands are relayed to a proxy on the host machine. The proxy can fulfill or reject them.
This means:
- No rebases without approval
- No force pushes
- No
--skip-validations - No bypassing pre-commit hooks
The hook becomes a hard gate rather than a gentleman's agreement. The agent doesn't get a choice, and neither does the developer who tries to bypass it through the agent.
Defense in depth (without using that phrase): Bind mounts protect your filesystem. The git proxy protects your history. Stack them together and the holes don't line up.
The reason TDD has never fully taken hold isn't that developers don't believe it produces better code. Most of them know it does. It's that writing a failing test, then making it pass, then cleaning up — for every single change — is genuinely tedious in a way that grates against how human brains work.
Machines don't care about tedium.
You can enforce the full red-green-refactor cycle as a hard gate on every commit. The agent just does it. Every time. Without resentment. Many developers will ship their first code base with rigorous TDD enforced throughout — not because they became more disciplined, but because they stopped relying on human discipline and made it structural.
Important caveat: Constraints without skills create doom-loops. If you enforce TDD without giving the agent the context and capability to actually do it, you haven't created quality — you've created an agent spinning in circles at machine speed. Tell the agent what to do and enforce it from outside its reach.
Every artifact the agent produces should leave a paper trail a human can audit. You're not supervising the agent's process — you're supervising its output. That's a scalable form of oversight.
Example: Screenshot diffing in system tests
Every system test saves screenshots at each assertion. Images are compared to the base build. Off by one pixel — flagged for manual review.
If you're building so fast that you don't have time to scan through diffs of screenshots, maybe you're going too fast.
This reframes "going fast" as a potential warning sign rather than a pure virtue. Speed without instruments isn't confidence — it's optimism.
Other paper trails to consider:
- Command logs from the proxy
- Git history (enforced through the proxy)
- Test results and coverage over time
Flip the framing. These controls aren't about distrust. They're about giving AI agents a track to run on.
The sprinter isn't being held back. He's being enabled to go that fast, at that angle, without dying.
Once the guardrails are in place:
- You can confidently delegate tedious work
- You can grant more autonomy on low-risk tasks
- You can try new tools without fear of the blast radius
- You can enforce engineering practices that human teams could never sustain
Return to the Pirelli image.
The controls aren't the enemy of velocity. They're the precondition for it. The best security control is the one you'll actually use. The best time to exercise is the time you're most likely to do it. Pick your entry point on the spectrum — sandboxed user, VM for MCP experimentation, git proxy, full container stack — and start there. Any of them beats bare metal with full privileges.
The tire isn't slowing that sprinter down. It's the only reason he's still standing.
| Section | Time |
|---|---|
| Opening / Cassandra credentials | 3 min |
| The Rogue Gallery | 8 min |
| Core Thesis | 2 min |
| Supervision / Autonomy Axis | 3 min |
| Isolation options | 12 min |
| Control Stack | 12 min |
| Instrument Panel | 5 min |
| What This Unlocks | 3 min |
| Closing | 2 min |
| Total | ~50 min |
- Fast User Switching between main user and Cursor user (live)
- Show agent cannot access SSH keys or main home directory
- Pre-commit hook rejecting a commit that skips validation
- Screenshot diff flagging a one-pixel visual regression
- "Power is nothing without control."
- "The best security control is the one you'll actually use."
- "The best time to exercise is the time you're most likely to do it."
- "Tell your agents to do the right thing — and then enforce it from outside the agent's reach."
- "If you're building so fast that you don't have time to scan through diffs of screenshots, maybe you're going too fast."
- "The tools are old. The threat is new. The gap is that we forgot the tools existed."
- "Speed without instruments isn't confidence — it's optimism."