Securing AI-Assisted Coding: Why It’s the Real Enabler

If you’re running an engineering team in 2026 and your devs aren’t using AI coding tools yet, you’re leaving speed on the table. Claude Code, Cursor, OpenCode, Codex, Copilot … the list keeps growing. These tools are genuine multipliers. I’ve seen senior engineers ship in hours what used to take days.

The trade-off is straightforward: these tools run as your developer. Same permissions. Same file access. Same environment variables. Same network. When Claude Code reads your codebase to understand context, it can also read your AWS credentials, your database connection strings, your SSH keys. Not because it’s malicious. Because you gave it the keys and told it to figure things out.

Most teams I talk to are in one of two camps: either they’ve banned AI coding tools entirely (and their devs are using them anyway, just on personal machines with zero oversight), or they’ve embraced them with no guardrails at all. Both are bad. The first one is denial. The second one is a breach waiting to happen.

There’s a better way. And it’s not complicated.

What Can Actually Go Wrong

This isn’t theoretical. Here’s what an unrestricted AI coding agent can do, with no malicious intent at all:

• Wipe your filesystem. A misunderstood cleanup task, a recursive delete gone wrong. The agent has rm -rf at its fingertips.
• Leak your keys. It reads .env, ~/.aws/credentials, ~/.ssh/id_rsa for „context.“ If it then pastes that context into a web request, a log, or a commit message, your secrets are out.
• Escape your project. Nothing stops it from reading ../../other-project/ or modifying files in your home directory.
• Abuse Docker. A single docker run -v /:/host gives it root access to your entire machine, bypassing any sandbox.
• Install malicious packages. Prompt injection via a cloned repo’s README can instruct the agent to npm install or pip install something you didn’t vet.

The question isn’t whether these things will happen. It’s whether your setup contains the blast radius when they do.

The Clean Solution: Ephemeral Dev Environments

If you have the infrastructure budget and the team to maintain it, the cleanest answer is to not run AI agents on developer machines at all. DevPods, Gitpod/Ona, or GitHub Codespaces spin up isolated, ephemeral environments per project or even per task.

The agent runs in a container. It has access to the repo and nothing else. When the task is done, the environment is destroyed. No credential leakage, no cross-project contamination, no persistent state that accumulates risk over time.

This is where large, security-conscious organizations are heading. The tooling has matured enough that the developer experience is nearly indistinguishable from local development. Nearly.

But let’s be honest: most teams aren’t there yet. Running your own DevPod infrastructure or paying for Codespaces at scale isn’t trivial. So what do you do in the meantime? You layer up. Match the solution to the size of the problem.

Layers of Defense (Match the Solution to the Problem)

What follows is how I think about securing my own setup. I’m not pushing a specific toolchain. Every team’s stack, threat model, and risk tolerance is different. The point is the approach: pick the layers that make sense for you and build from there.

1. Permission Files and Deny Rules

Problem size: Solo dev or small team, just getting started with AI coding tools.
Effort: Five minutes per repo.
Prevents: Accidental reads of secrets, unintended web requests.

Every major AI coding tool now supports some form of permission configuration. Claude Code has .claude/settings.json with explicit deny rules:

{
  "permissions": {
    "deny": [
      "Read(./secrets/**)",
      "Bash(curl:*)",
      "WebFetch"
    ]
  }
}

This is the absolute minimum. It won’t stop a determined attack vector, but it handles the „oops“ scenarios where the agent casually reads something it shouldn’t. Think of it as a seatbelt: it won’t save you in every crash, but wearing one is the bare minimum.

2. Hooks and Lifecycle Control

Problem size: Team with compliance requirements or security-conscious engineering leads.
Effort: A day to set up, then it runs itself.
Prevents: Unaudited command execution, policy violations going unnoticed.

Claude Code and similar tools support hooks that fire before and after tool execution. Think of them as middleware for your AI agent. You can intercept commands before they run, validate them against a policy, log everything, or block entire categories of operations.

This is where it gets interesting for compliance. Every command the agent runs can be audited. Every file access logged. If your security team needs a paper trail, hooks give you that without slowing anyone down.

3. Auto Mode (Claude Code’s Built-in Middle Ground)

Problem size: Teams using Claude Code who want fewer interruptions without going full --dangerously-skip-permissions.
Effort: claude --enable-auto-mode, then Shift+Tab to activate.
Prevents: Mass file deletions, data exfiltration, malicious code execution (via classifier).

As of March 24, 2026, Claude Code ships auto mode: a classifier reviews each tool call before it runs and auto-approves safe actions while blocking destructive ones. You can kick off a large task and walk away without approving every file write.

It’s a real improvement over the approve-everything default. But Anthropic is clear: it doesn’t eliminate all risk. The classifier can miss edge cases where intent is ambiguous or environment context is lacking. They still recommend isolated environments alongside it.

For me, auto mode + a bubblewrap sandbox is the sweet spot. Auto mode handles the flow (no more clicking approve 200 times), the sandbox handles the blast radius (even if the classifier misses something, the damage is contained to the project directory). Belt and suspenders.

Available now for Team plans, coming to Enterprise and API soon.

4. Sandbox the Entire Session (Filesystem Isolation)

Problem size: Any team where devs work on multiple projects and you can’t afford cross-contamination.
Effort: One-time setup, then it’s transparent.
Prevents: Filesystem escapes, credential theft from home directory, cross-project contamination, system file modification.

This is where it gets real. Permission files are policy. Sandboxing is enforcement.

I built bw-AICode to wrap AI coding tools in a bubblewrap sandbox. In practice, it’s this simple:

cd my-project
claude-bw          # start Claude Code sandboxed
opencode-bw        # start OpenCode sandboxed

That’s it. You run claude-bw instead of claude. Everything else works the same, except now the agent is sandboxed: system directories are read-only, your project directory is the only writable location, IPC and PID namespaces are isolated.

The tool runs with --dangerously-skip-permissions (Claude Code’s flag for skipping its built-in permission prompts), which sounds terrifying until you realize the sandbox makes those prompts redundant. The kernel enforces what the agent can and can’t touch. No more clicking „approve“ 200 times a day.

bw-AICode also ships with hooks that block reads of sensitive files like .env inside the project directory, so even within the writable sandbox, secrets aren’t casually exposed to the agent.

I built this for my own workflow. It’s open source, not a product. If it fits your setup, fork it. If it doesn’t, open an issue or adapt it. The point isn’t this specific tool, it’s the approach: enforce at the OS level, not at the application level.

5. Docker Access Control (The Escape Hatch Problem)

Problem size: Any team using Docker in development (so basically everyone).
Effort: Zero config if you already have a docker-compose.yml. It auto-detects.
Prevents: Docker socket escape to root, arbitrary container creation, host volume mounts.

Here’s something most sandbox discussions miss: Docker access is root access. Anyone who can talk to the Docker socket can run docker run -v /:/host alpine chroot /host and get a root shell on the host, bypassing every sandbox restriction you’ve set up.

bw-AICode solves this with bw-docker-guard, a Go reverse proxy that sits between the sandboxed AI tool and the Docker daemon. It auto-detects your project’s Docker needs at launch and enforces a locked allowlist:

Three modes, auto-selected:

In guarded mode, the proxy inspects every Docker API request body. It blocks --privileged, --pid=host, --network=host, arbitrary volume mounts outside the project directory, and a long list of other escape vectors. Container lifecycle operations (start, stop, exec, logs) only work on containers the session created or that belong to the project’s compose stack.

The allowlist is derived from your docker-compose.yml and MCP server configs at launch and locked for the session. Even if the AI modifies config files during the session, the allowlist doesn’t change.

This matters because many MCP servers are packaged as Docker images using stdio transport. The AI tool needs to docker run them. Blocking Docker entirely breaks the workflow. The guard proxy lets it work while preventing the escape.

6. Kernel-Level Sandboxing (Alternative Approach)

Problem size: Teams that need a general-purpose agent sandbox with full audit trail.
Effort: brew install nono, then prefix your commands.
Prevents: Same as above, plus provides cryptographic audit trail.

For a different take on the same problem, nono (installable via Homebrew) enforces restrictions at the kernel level with a full audit trail. It works with any CLI tool and records every command, timing, exit code, and network event as structured JSON. Full provenance chain with cryptographic commitments.

Where bw-AICode is purpose-built for AI coding tools with integrated Docker control, nono is a general-purpose agent sandbox. Both enforce at the OS level rather than relying on the AI tool to behave.

Build the Tool Around Your Workflow, Not the Other Way Around

For years, adopting a new dev tool meant adapting your workflow to fit it. Configure it the way it wants, learn its opinions, accept its trade-offs.

With AI coding tools, that’s flipping. The tools are flexible enough, and the wrapper surface is small enough, that you can build exactly the security and workflow layer you need. bw-AICode is a few hundred lines of bash and a Go proxy. It took a weekend to build, and it fits my exact setup: my project structure, my Docker usage, my MCP servers, my threat model.

You don’t need to wait for Anthropic or Cursor to ship the security feature you want. Write a hook. Fork a script. Build a proxy. The components are all there, open source, composable. The age of adapting your workflow to a tool’s opinions is ending. Adapt the tool to yours.

The Real Point: Security Enables Speed

This looks like more work. It is, upfront. But with solid guardrails, you can give the AI agent more autonomy. Let it refactor, write infrastructure code, run tests and fix what breaks. You’re not second-guessing every command because the blast radius is contained.

Without guardrails, teams end up in one of two places: management gets nervous and restricts AI tool usage (killing the productivity gain), or something goes wrong and restrictions come down hard from above (killing it worse).

A few hours of setup saves you from both.

Approaches at a Glance

Where to Start

Pick the layer that matches where you are right now:

1. Solo dev or small team: Add permission deny rules to your AI coding tool configs. Five minutes per repo. Do it today.
2. Team with compliance needs: Set up hooks for audit trails. A day of work for permanent visibility.
3. Multiple projects, shared machines: Install bw-AICode. One-time setup, then just run claude-bw instead of claude. Your projects stay isolated.
4. Docker-heavy stack: bw-AICode’s Docker guard handles this automatically. If you have a compose file, you’re already covered.
5. Enterprise scale: Evaluate DevPods or Codespaces for full ephemeral environments. It’s the cleanest solution if you can afford the infrastructure.

If you want help figuring out the right setup for your team, that’s what I do at Data Prospectors: help engineering teams adopt AI-assisted development with the right guardrails for their specific stack and risk profile. Not selling a product, just helping you build and adapt the right tools.

Gernot Greimler is the founder of Data Prospectors, a Vienna-based consultancy specializing in AI-assisted development, data engineering, and making sure your AI agents don’t read things they shouldn’t.