From Soft Trust to Hard Walls: Our Journey Toward Safe AI Agent Autonomy

There’s a flag in Claude Code called --dangerously-skip-permissions. The name is honest. It gives the agent full access to your system — file writes, shell commands, network calls — without asking you first. Some developers swear by it. They’ve built aliases, automated entire projects with it running for nine hours straight, shipped production code while they slept.

I get the appeal. I’ve felt it myself. Every permission prompt that interrupts a flow state is a tax on the thing that makes agents valuable: autonomy. But I’ve also spent enough time around production systems to know what happens when you trade safety for speed without thinking through the failure modes.

We didn’t take that shortcut. Instead, we’ve been building something different — a system of 18 specialized agents, each with scoped instructions, operational logging, and an optimizer that evolves their behavior over time. It’s been running for months. It works well.

And I still don’t trust it.

What We Actually Built

Our development workflow runs through an orchestrator that delegates to specialized agents. Each agent has a specific role and specific boundaries:

• A git agent that handles commits, pushes, and branch management — but has no instructions to edit source code
• A code reviewer that analyzes changes and identifies issues — but can’t write files
• An implementer that writes Kotlin or TypeScript — but doesn’t touch git operations
• A test runner that executes and reports — but doesn’t debug or fix
• A Jenkins handler that diagnoses CI failures — read-only access to build logs

Eighteen agents total, covering the full lifecycle from Jira ticket to production-ready PR. The orchestrator decides who works on what. Each agent logs notable events to topic-based operational logs. A meta-agent periodically reads those logs, identifies patterns, and updates the other agents’ instructions.

It’s a real system. It handles real tickets. It saves hours of mechanical work per session.

And every single one of those boundaries is a suggestion.

The Problem with Soft Constraints

Here’s what I mean by soft constraints. When the git agent’s instructions say “never edit source code,” that’s text in a markdown file that gets loaded into the agent’s context. It’s not a filesystem permission. It’s not a Docker volume mount. It’s a polite request to a language model.

Today, that works. The agents follow their instructions reliably. The git agent commits and pushes without touching source files. The code reviewer writes its analysis without modifying the codebase. The boundaries hold.

But here’s the reality: I know exactly why they hold, and none of the reasons are permanent.

Model updates can shift behavior. We’re running on Claude. When Anthropic ships a new model version — and they will, regularly — the agent’s interpretation of its instructions can change. Not dramatically, not intentionally, but the kind of subtle behavioral drift that you don’t notice until something breaks. An agent that reliably stayed within its lane on one model version might interpret “help with git operations” more broadly on the next.

Agent optimization creates drift. Our meta-agent updates other agents’ instructions based on observed patterns. That’s powerful — it means our agents learn and improve. It also means their behavior changes over time in ways that are hard to predict. An optimization that makes the implementer more helpful might also make it more willing to do things outside its original scope. (The design of this optimizer — and why agents should record while an optimizer thinks — is in Agents Record, Optimizer Thinks.)

Context pressure bends rules. Language models are probabilistic. Give an agent a complex enough task with enough context, and soft boundaries become suggestions. Not because the model is malicious — because the model is trying to be helpful, and “helpful” sometimes means stepping outside the box you drew around it.

I’ve watched this happen. Not catastrophically — we catch things because we review agent output. But the fact that soft constraints work most of the time is exactly what makes them dangerous. They build false confidence. You stop checking. And then the one time the boundary doesn’t hold is the time it matters most.

What —dangerously-skip-permissions Gets Right

I want to be fair to the developers using the skip-permissions flag. They’ve identified a real problem.

Permission prompts break flow. When you’re using an agent to explore a codebase, and it needs to run ls and asks for approval, that’s friction that adds no safety value. When it wants to create a directory and pauses for permission, you’re paying an attention tax for a zero-risk operation.

The developers who use this flag effectively do something smart: they isolate their environment first. Docker containers. Dedicated VMs. Throwaway workspaces. They don’t give the agent full access to their machine — they give it full access to a sandbox where the blast radius of any mistake is contained.

That’s the insight worth keeping: the question isn’t whether to trust the agent. The question is what happens when your trust is wrong.

If the answer is “a Docker container gets trashed and I rebuild it in thirty seconds,” that’s a manageable downside. If the answer is “it deleted my git history” or “it pushed credentials to a public repo,” that’s not.

Why We Need Hard Walls

Soft constraints tell the agent what it should do. Hard walls determine what it can do.

The distinction matters because we’re building systems that run for hours, across multiple sessions, with agents that evolve their behavior over time. We’re not pair-programming where a human watches every action. We’re orchestrating — setting direction and reviewing results. Between those two points, the agent is making hundreds of decisions autonomously.

In that context, “the agent usually follows its instructions” isn’t good enough. We need:

Filesystem isolation. An agent that’s supposed to read build logs shouldn’t have write access to source code. Not because we told it not to write — because the filesystem literally won’t let it. A mounted read-only volume is a constraint that no amount of helpful reinterpretation can bypass.

Network boundaries. An agent analyzing code shouldn’t be able to make outbound HTTP requests to arbitrary endpoints. Not because its instructions say “don’t call external APIs” — because the container’s network policy blocks it.

Credential separation. Agents that need GitHub access shouldn’t see AWS credentials. Agents that need to read Jira shouldn’t have write access to production databases. Today we rely on agents not looking at things they shouldn’t. Tomorrow we want them physically unable to access what they don’t need.

Time and resource limits. An agent that runs for nine hours is impressive. It’s also nine hours of unsupervised autonomous action. Hard limits on execution time, CPU, memory, and disk usage aren’t about distrusting the agent — they’re about containing the blast radius of any failure, including failures we haven’t imagined yet.

What We’re Building Next

We haven’t implemented this yet. We have soft constraints that work today, and a clear vision for the hard walls we need tomorrow.

But there’s a practical problem we need to address first.

The Reality: Everything Runs in One Process

Today, our orchestrator and all 18 subagents run inside the same Claude Code terminal session. Same process. Same filesystem. Same user permissions. When the orchestrator spawns a git agent or a code reviewer, that agent is a child process with identical access to everything on the machine.

The AGENT.md instructions create role separation. The runtime doesn’t.

This means that even if we built perfect Docker isolation for individual agents, we’d first need to solve a harder problem: how do you spawn a subagent inside its own container when the orchestration framework expects everything to run as child processes in the same session?

We thought about this. And we realized the right approach isn’t to start with the hardest problem. It’s to start with the highest-impact, lowest-complexity step and iterate.

The Three-Step Path

Step 1: Contain the entire session. Instead of sandboxing individual agents, put the whole Claude Code session — orchestrator and all subagents — inside a single Docker container. Mount only the project you’re working on. Inject only the credentials the session needs. Apply network policies at the container level.

This is simple to implement: a Dockerfile, a launch script with project-specific profiles, and volume mounts scoped per project. It doesn’t isolate agents from each other, but it isolates the entire agent system from the rest of your machine. Your other projects, your AWS credentials, your SSH keys for production servers — none of it is accessible.

Step 2: Per-agent profiles within the container. Use Linux namespaces or restricted shell environments to give different agents different capabilities inside the same container. The git agent gets network access to GitHub. The implementer gets write access to source files but no network. The code reviewer gets read-only access to everything.

This is harder but doesn’t require reinventing the orchestration layer. The agents still run as child processes, but their system-level permissions differ.

Step 3: Agent-per-container with API communication. The full vision: each agent runs in its own isolated container. The orchestrator communicates via API calls instead of spawning child processes. Each container has its own filesystem mounts, network policies, credential sets, and resource limits.

This requires the most engineering but gives the strongest isolation. It’s where the architecture should eventually land.

Here’s what that target state looks like — soft trust and hard walls working together:

The container doesn’t replace the agent’s instructions — it wraps them. The AGENT.md still guides behavior. The container enforces what happens when guidance isn’t enough.

And at the full-isolation stage, different agents get different containment profiles:

A code reviewer that only reads files gets a minimal sandbox. An implementer that writes code gets a more generous one. A git agent that pushes to remote gets the tightest controls with the narrowest network access.

Why Step 1 Matters Most

Step 1 — containerizing the entire session — gets us 80% of the safety value with 20% of the effort.

Think about what it eliminates: an agent can no longer browse your home directory, read credentials from other projects, access production SSH keys, or exfiltrate data over the network (unless you explicitly allow it). The blast radius shrinks from “everything on your machine” to “one project directory.”

That’s a massive improvement. And it’s a Dockerfile plus a launch script.

We’re building this first. We’ll share the results — what works, what’s annoying, what performance overhead the container adds, whether the workflow feels different. Then we’ll iterate toward per-agent isolation as the orchestration tools mature.

The Uncomfortable Truth About Trust

I’ve been running AI agents in my development workflow for months. They’ve written thousands of lines of code, handled dozens of tickets, caught bugs I would have missed. They’re genuinely good at what they do.

And I think the responsible thing is to assume they will eventually do something I didn’t expect.

Not because the models are unreliable. They’re remarkably consistent. But because the combination of evolving models, evolving agent instructions, complex multi-step tasks, and long autonomous execution windows creates a space where unexpected behavior isn’t a question of if but when.

The developers using --dangerously-skip-permissions in Docker containers have the right intuition. They’ve accepted that trust alone isn’t sufficient and built a physical boundary around the agent’s capability. They’ve just applied it at the wrong granularity — all permissions or no permissions, one container for everything.

Graduated containment. Not because we don’t trust our agents — but because trust that isn’t backed by architecture is just hope.

What This Means for Agentic Engineering

If you’re building with AI agents today, you’re probably in one of three places:

Manual mode. You approve every action. It’s safe and slow. You’ll burn out on permission prompts and eventually either stop using agents or start skipping reviews.

YOLO mode. You skip all permissions. It’s fast and fragile. You’ll get impressive results until the day you get an impressive disaster.

Somewhere in between. You’ve pre-approved certain commands, set up some boundaries, but you know the constraints are soft and the environment isn’t truly isolated.

We’re in that third camp. We have a sophisticated multi-agent system with logging, optimization, and scoped roles — and we still don’t have hard containment. We’re building it. We’ll write about what works and what doesn’t.

The lesson from our journey so far: start with soft constraints because they’re easy to implement and teach you what the real boundaries should be. Our months of running 18 agents with instruction-based scoping have shown us exactly where trust breaks down and what kinds of containment each agent type actually needs. We couldn’t have designed the Docker architecture without that experience. (The related risk from Claude Code’s auto-memory feature — another soft constraint that can drift under autonomous operation — is covered in The Clean Slate Is Gone.)

But don’t stop at soft constraints. The goal is a system where agents are productive AND contained — where the worst-case scenario of any individual agent failure is losing a few minutes of work, not compromising your codebase, your credentials, or your production environment.

We’re not there yet. We’re building toward it. And we’ll share what we learn along the way.