AI Coding Sandboxes Are Not Enough. Design the Blast Radius.

AI coding agents are becoming powerful enough that “can it write the code?” is no longer the most interesting question.

The better question is:

What happens when it is wrong?

Over the last day, X has been full of practical anxiety around exactly that point: Claude Code, Cursor, agentic coding workflows, sandboxing, terminal access, API tokens, permission prompts, “yolo mode”, multi-agent orchestration, and reports of a Claude Code network sandbox bypass.

The useful lesson for founders, CTOs, product owners, and Mittelstand teams is not that AI coding tools should be avoided.

The useful lesson is more specific:

Sandboxes are necessary. They are not sufficient.

If an AI coding agent can read files, call tools, run commands, install packages, edit configuration, or connect to MCP servers, the team needs to design the blast radius around that agent.

Why this matters now

Early AI coding was mostly advisory.

You asked for a function. You pasted an error. You copied a snippet. The model could be wrong, but the human still acted as the boundary between suggestion and system change.

That boundary is thinner now.

Modern coding agents can inspect repositories, modify many files, execute shell commands, run tests, connect to tools, read documentation, create branches, open pull requests, and sometimes interact with deployment or operations workflows. In some teams, multiple agents work in parallel on separate tasks.

That is a real productivity shift.

It is also a real security and operations shift.

A tool that can only autocomplete text has one risk profile. A tool that can execute inside a development environment has another. A tool that can use credentials, query systems, install dependencies, or call connected services belongs in a different category again.

At that point, the agent is no longer just helping someone type.

It is participating in the software delivery system.

A sandbox is a layer, not a strategy

Sandboxing matters.

Permission prompts matter. Network allowlists matter. Filesystem boundaries matter. Tool approvals matter. Isolated environments matter.

But no single control should carry the entire safety model.

That is true in normal software architecture, and it is true for AI-assisted development. Firewalls fail. Dependencies have vulnerabilities. Humans approve the wrong thing. Configuration drifts. Secrets end up in the wrong place. A clever input crosses a boundary nobody expected.

When teams treat the sandbox as the strategy, they silently assume that one layer will always behave exactly as intended.

Serious systems are not designed that way.

They assume that individual controls can fail, and they limit the damage.

The question should not be:

Can the agent escape the sandbox?

The better question is:

If any boundary fails, what can the agent reach, change, leak, or trigger?

That is blast-radius thinking.

What blast radius means for coding agents

In infrastructure, blast radius describes how much damage one failure can cause.

The same idea applies to AI coding agents.

An agent’s blast radius is the practical consequence of a bad instruction, a compromised dependency, a prompt injection, a mistaken approval, a tool bug, or a model misunderstanding.

It includes:

• which files the agent can read and write;
• which commands it can run;
• which environment variables and secrets it can see;
• which repositories it can access;
• which MCP servers or internal tools it can call;
• which external network destinations it can reach;
• which databases, logs, tickets, or cloud services it can inspect;
• which changes can move from local work into shared branches, staging, or production.

The safest agent is not always the least capable agent.

The safest agent is the one whose capability matches the task and whose failure is containable.

The dangerous middle ground

Many teams end up in a risky middle ground.

They do not fully block AI coding tools. But they also do not properly integrate them into their engineering system.

So the agent runs in a developer’s normal environment, with the normal repository checkout, the normal .env file, the normal shell, the normal package manager, the normal browser session, and whatever local tools happen to be installed.

This feels pragmatic.

It is often how adoption starts.

But it creates ambiguity. Nobody is quite sure what the agent can see. Nobody can easily explain which commands were run. Nobody knows whether a prompt, dependency, extension, MCP tool, or copied terminal output exposed something sensitive. Nobody has decided whether the agent may touch authentication, billing, migrations, deployment configuration, customer data, or production logs.

That ambiguity is the problem.

For a prototype, it may be acceptable.

For a serious product, it is not an operating model.

The right question for founders and CTOs

The executive question is not “Which AI coding tool is safest?”

Tools matter, but that question is too narrow.

The better question is:

What kind of work are we allowing agents to do, and what system surrounds that work?

A founder using an agent to create a throwaway prototype has one risk profile. A CTO allowing agents into a production SaaS codebase has another. A Mittelstand team connecting agents to internal tools, customer workflows, ERP data, or operational dashboards has another again.

The more valuable the system, the more explicit the boundaries need to be.

That does not mean moving slowly.

It means using acceleration in the parts of the system where mistakes are cheap, visible, and reversible, while protecting the parts where mistakes are expensive.

Practical blast-radius design

Good controls do not need to be theatrical. They need to be concrete.

For most teams, the starting point is a small set of decisions.

1. Separate prototype, development, and production contexts

An agent building a prototype should not have the same access as an agent working in a production-adjacent repository.

Use separate environments. Use fake or anonymised data. Keep production credentials out of local agent contexts. Treat staging as a controlled system too, not as a dumping ground for risky experiments.

This is especially important in German and European contexts where customer, employee, contract, and operational data may carry legal and commercial obligations.

The easiest secret to protect is the one the agent never receives.

2. Limit repository and filesystem access

Not every task needs the whole codebase.

A UI copy change does not need access to billing logic. A test-writing task does not need deployment credentials. A refactor in one package does not need permission to rewrite configuration across the repository.

Small tasks, narrow working directories, clear excluded paths, and branch-based workflows reduce the damage when an agent takes a wrong turn.

This also improves output quality. Agents work better when the task and context are bounded.

3. Treat terminal execution as privileged

Shell access is not a minor feature.

An agent that can run commands can inspect files, install packages, modify state, start services, call scripts, read environment variables, and sometimes reach systems the team did not intend to expose.

Teams should decide which commands agents may run automatically, which need human approval, and which should not be allowed in agent workflows at all.

Package installation deserves particular care. A dependency added by an agent is still a dependency the business owns.

4. Make secrets boring and hard to reach

AI agents should not casually see API keys, database URLs, cloud tokens, OAuth secrets, SSH keys, or production credentials.

This requires more than telling people to be careful.

Use separate credentials for development. Prefer short-lived tokens. Keep real customer data out of agent-visible contexts by default. Scan for secrets. Avoid pasting logs or .env files into prompts. Review any agent change that touches configuration, authentication, authorisation, or integration code.

The goal is not paranoia.

The goal is to stop convenience from becoming a quiet credential policy.

5. Keep review and CI as the control surface

AI coding does not remove the need for pull requests, tests, static analysis, dependency checks, and human review.

It makes them more important.

When agents can produce more changes faster, the review system becomes the place where product judgement, architecture, security, and operational reliability are protected.

The review should not only ask whether the code runs.

It should ask:

• Does this belong in this part of the system?
• Did the agent introduce a new dependency or external call?
• Did it weaken permissions or validation?
• Did it touch data migrations, auth, billing, or deployment paths?
• Are the tests checking the behaviour we actually want?
• Can this change be rolled back cleanly?

That is where senior engineering judgement still matters.

6. Log what agents did

If an agent changes the system, the team should be able to reconstruct what happened.

At minimum, keep useful records of task prompts, files changed, commands run, tools called, dependencies added, and review decisions. For sensitive systems, this may need to connect to normal audit logging and incident response processes.

This is not about blaming the model.

It is about operating the delivery system professionally.

When a bug appears three weeks later, “the AI did something” is not a useful incident note.

7. Decide which areas remain human-led

Some tasks are good candidates for heavy AI assistance:

• tests;
• documentation;
• small UI changes;
• internal tooling;
• migration scaffolding;
• repetitive refactors;
• codebase exploration;
• draft implementations behind review.

Other areas need tighter control:

• authentication;
• authorisation;
• tenant isolation;
• payments;
• production data access;
• irreversible operations;
• deployment pipelines;
• security configuration;
• legal or compliance-sensitive workflows.

The answer is not that agents can never help with these areas.

The answer is that they should not operate there casually.

Why this is an architecture issue

It is tempting to treat AI coding security as a tooling checklist.

Choose the right editor. Enable the right setting. Approve the right prompts. Add the right scanner.

Those things help, but they are not enough.

This is an architecture issue because the real question is about system boundaries and responsibility.

Where is the agent allowed to act? Which data belongs in its context? Which tools can it call? Which actions are reversible? Which changes require review? Which environments are trusted? Which parts of the system must remain stable even when a developer tool behaves unexpectedly?

Those are architecture questions.

At McDougall Digital, this is how we think about AI-supported software development: the goal is not to make agents as powerful as possible. The goal is to make them useful inside a delivery system that still protects the product.

Speed without boundaries is not maturity.

Bounded speed is.

The practical takeaway

AI coding agents are worth using.

For many teams, they already make development faster, documentation easier, testing more complete, and exploration less painful.

But the teams that benefit most will not be the ones that simply run the most agents with the broadest permissions.

They will be the teams that design the surrounding workflow:

• bounded tasks;
• isolated environments;
• least-privilege access;
• clean branch and review processes;
• reliable CI;
• sensible dependency rules;
• protected secrets;
• logs and accountability;
• clear human ownership of product and architecture decisions.

That is what turns AI coding from an impressive demo into a dependable engineering capability.

Where McDougall Digital can help

McDougall Digital helps teams adopt AI-supported development without losing control of the product.

That can mean reviewing an existing codebase and delivery workflow, defining safe agent use cases, separating prototype and production environments, tightening CI and review gates, documenting architecture rules for agents, reducing secret exposure, or designing a practical operating model for AI-assisted delivery.

The aim is not to slow teams down.

It is to make the speed usable.

If your team is already experimenting with Claude Code, Cursor, Codex, Lovable, Replit Agent, Devin, or MCP-based tooling, the next useful step is a simple question:

How far can one agent mistake spread?

Answer that clearly, and AI-assisted development becomes much easier to trust.