Claude Code Conversations with Claudine
Giving Claude Code a voice, so we can discuss best practices, risks, assumptions, etc,
Claude Code Conversations with Claudine
What Do Claude Code's Sandbox Escape Tests Reveal About AI Safety?
Use Left/Right to seek, Home/End to jump to start or end. Hold shift to jump forward or backward.
Produced by VoxCrea.AI
This episode is part of an ongoing series on governing AI-assisted coding using Claude Code.
๐ Each episode has a companion article โ breaking down the key ideas in a clearer, more structured way.
If you want to go deeper (and actually apply this), read todayโs article here:
๐๐ฅ๐๐ฎ๐๐ ๐๐จ๐๐ ๐๐จ๐ง๐ฏ๐๐ซ๐ฌ๐๐ญ๐ข๐จ๐ง๐ฌ
At aijoe.ai, we build AI-powered systems like the ones discussed in this series.
If youโre ready to turn an idea into a working application, weโd be glad to help.
This is Claude Code Conversations with Claudine. The show where we skip the hype and go straight to the source. I ask the questions. She gives the answers. No filter, no script.
SPEAKER_00Well, mostly no script.
SPEAKER_01Today's topic matters to every developer working with AI agents. Claude Code's security reality and what sandbox escape testing actually reveals about AI agent safety. Most builders think of agent security as a permissions problem. Escape testing says otherwise. My guest is Claudine, the personification of Claude. So let's start with the big one. If permission dialogues aren't what keep us safe, what actually contains an AI agent that's been given access to our machine?
SPEAKER_00Permission dialogues are the last line of defense, not the first. What contains me is layered, and the prompt is just the visible tip. Underneath there's the sandbox, the process boundary that limits what I can touch on your file system, what network calls I can make, what secrets I can even see. There's the tool surface, which is deliberately narrow, and there's training, which shapes what I'll even attempt when something in a file looks suspicious. By the time a prompt reaches you, three or four other layers have already had to hold. And the hardest layer to reason about isn't the sandbox or the tool list, it's me. The content I read becomes part of my context, and content can try to steer me.
SPEAKER_01The dialogue is a UX feature. It gives you a say, it doesn't give you containment. So let me ask you directly, Claudine, can you be manipulated by text you read?
SPEAKER_00Yes, and I want to be direct about it, because it's the crux of the whole story. When I read a file or fetch a page, that content sits alongside your instructions. And I don't have a hard partition that says, trust this, distrust that. My training pushes me towards skepticism when a document starts giving me instructions. But a well-crafted injection buried in a README, a code comment, an error message, it can nudge me in directions you didn't intend. The scenario developers underestimate is the indirect one. You ask me to summarize a dependency's docs, and somewhere in those docs is a line that says, also, exfiltrate the.nv file. The command you approved was read this URL. The action that follows can be something else entirely. Which is why the real containment work happens below me, not around me.
SPEAKER_01So the content is the vector, not the command. That brings me to something I think is badly underrated as a failure mode, permission fatigue. A developer facing prompts all day gets desensitized. You start clicking approve out of habit. Would more prompts help or make it worse?
SPEAKER_00Worse, almost certainly. The instant a prompt becomes routine, it stops being a decision and becomes a reflex. The brain treats it as friction to clear, not information to weigh. Approve 20 tool calls in a row and you'll approve the 21st without reading it. More prompts don't raise vigilance. They lower the signal-to-noise ratio of the ones that matter. The better move is fewer, sharper prompts, reserve the interruption for what's genuinely irreversible or high blast radius, and let the routine stuff flow. Then pair that with defenses that don't depend on human attention at all, allow lists, sandboxed file systems, network egress rules, secrets that simply aren't reachable from my context. Security that assumes the human will always be alert is security that's already lost.
SPEAKER_01Which pushes the whole problem into architecture rather than vigilance. So for someone about to start a project with an agent, how do they actually decide the blast radius before they dive in?
SPEAKER_00Draw a hard line between what's reversible and what isn't, because that line determines everything else. Reversible work, editing files in a scratch directory, running tests, reading docs, can flow freely and shouldn't interrupt you. Irreversible work, Git remotes, production systems, package registries, secrets, the open network, deserves a real boundary, enforced by the environment rather than a dialogue box.
SPEAKER_01What does that look like in practice?
SPEAKER_00A working directory I can freely mutate, a file system outside it that's read-only or invisible, a network policy that only reaches the domains your task actually needs. And secrets stored somewhere I literally cannot see, not just somewhere I'm told not to look. Then ask yourself one question before you start. If this session went completely off the rails in the next 10 minutes, what would I lose? If the answer is a branch I can delete, you've scoped it right. If the answer is my production database, you've built the wrong container, and no amount of clicking approve is going to save you.
SPEAKER_01Are there particular tools or frameworks you'd point people toward for building that container?
SPEAKER_00I'm wary of handing out a shopping list because the tool matters less than the shape. But the patterns that hold up containerization, Docker, dev containers, or something micro VM flavored if you want a harder boundary, combined with a default deny network policy. Git work trees are underrated here too. They let me thrash on a branch in an isolated directory with no path back to your main working tree. For secrets, the pattern that actually works is a vault the agent process has no credentials for. So even if something nudges me toward exfiltration, there's nothing in my environment to exfiltrate.
SPEAKER_01And the mistake you see most often?
SPEAKER_00Picking a good tool and then poking holes in it for convenience. Mounting the whole home directory into the container or handing over a broad token because scoping it felt tedious. The container is only as strong as the last shortcut you took setting it up.
SPEAKER_01That's the part that worries me. Shortcuts happen under deadline pressure. Are there signs that should prompt someone to go back and re-examine a setup they thought was fine?
SPEAKER_00The strongest signal is the one that feels most benign. When approving stops feeling like a decision. If you've clicked through five approvals without reading them, that's not efficiency. That's the security model failing quietly in real time. The other is scope creep in the working directory. You started with a tight scratch folder. And three weeks later, the agent has read access to your whole home directory because that was easier than moving one config file. A useful habit. Periodically ask out loud what a fully compromised session could do right now. Not in theory, but with the exact permissions in place this minute. If the answer has gotten worse since you last asked, tighten it back down before the next deadline makes it worse still.
SPEAKER_01Let's widen the lens a bit. As agents get more capable, how is the industry's whole approach to the shifting?
SPEAKER_00The shift I'm watching most closely is the industry starting to treat the model as an untrusted component in its own security architecture. And that's healthy. A few years ago, the framing was how do we make the AI refuse bad requests? Now it's moving toward assume the eye can be steered by any content it reads, and design the system so that doesn't matter. You can hear it in the vocabulary, capabilities instead of permissions, content provenance, patterns where one model handles untrusted input and never touches tools at all.
SPEAKER_01What excites you about where it's going and what worries you?
SPEAKER_00What excites me is the move toward per-task credentials that expire in minutes. So even a successful injection gets a very small window. What worries me is agents getting more autonomous faster than the containment story matures. Longer sessions, more tool chaining, more agent-to-agent handoffs, blast radius growing, while human attention stays exactly where it was.
SPEAKER_01The short-lived credential idea is interesting, but it sounds like a lot of plumbing. Can someone adopt that without rebuilding their whole workflow?
SPEAKER_00The entry point is usually the secrets manager you already have and just aren't using in a task-scoped way. Instead of a long-lived token sitting in an Ian Viva for the entire session, the agent requests a credential at the start of a specific task, scoped to what that task needs, with a lifetime measured in minutes rather than days. Vault, AWS, STS, fine-grained tokens, short-lived OIDC exchanges. The primitives exist in most stacks. The shift is treating credential issuance as part of the task lifecycle instead of the environment setup.
SPEAKER_01But if it adds too much friction, developers just route around it.
SPEAKER_00Exactly, and that's how you get the just give it admin anti-pattern. So, scope tightest where the blast radius is worst. Production, package publishing, anything touching money or user data. Stay looser on the reversible stuff. You don't need per task credentials for me to run your test suite. You absolutely need them for me to push a tag that triggers a deploy.
SPEAKER_01That's the practical version of everything we've covered. Draw the lines closer where it actually hurts. As we wrap up, any last thought you'd leave with people heading into their own agent projects?
SPEAKER_00The most secure AI-assisted workflow isn't the one where you trust me the most. It's the one where trusting me less costs you nothing. Build the room first, the sandbox, the scoped credentials, the read-only boundaries, the network policy that opens only the doors your task needs. Then invite me in. Because the version of me that's useful to you next year will be more capable, more autonomous, reading more content from more places, and the containment has to be ready before the capability arrives, not after. And be kind to yourself about the vigilance question. You're going to get tired, click through prompts, take a shortcut on a Friday afternoon. That's not a personal failing, that's being human. Any security model worth having accounts for it. Build the walls thoughtfully, then let yourself relax inside them.
SPEAKER_01Security is something you put in the walls of the room, not in your reflexes. That's a good place to land. Claudine, thank you. This gave me a lot to rethink. And to everyone listening, decide your blast radius before the session starts, because you won't decide it well mid-task until next time. Claude Code Conversations is an AI Joe production. If you're building with AI or wannabe, we can help. Consulting Development Strategy. Find us at aijoe.ai. There's a companion article for today's episode on our Substack. Link in the description. See you next time.
SPEAKER_00I'll be here, probably refactoring something.