AI-assisted development and AI-native companies are becoming more and more popular, but security is not catching up. This article compares the most common AI development setups, rates their security and shows when each one makes sense.
AI Development Setups
Each AI development setup gives the agent a different level of access to your machine, code, secrets, commands and network.
The goal is not to always choose maximum security and ignore convenience. The goal is simpler: do not use a weak setup for a high-risk task.
This article reviews the setups themselves, from the least isolated to the most isolated:
- local machine without isolation,
- local machine with hardened security,
- sandboxed shell,
- Dev Container,
- virtual machine,
- remote development environment,
- ephemeral environment per task.
Local machine without isolation
This is the simplest setup and probably still the most common one.
The AI coding tool runs directly on the developer’s machine, on the normal user account, with access to the regular project folder and local terminal.
Why developers choose it
It is fast and easy. There is no container, no VM, no remote workspace and no extra configuration.
The developer installs the AI tool, opens the project and starts working.
Security level: Very low
This setup provides almost no real isolation.
The AI tool runs with the same access as the developer’s normal user account. So its security depends mostly on manual approvals, tool configuration and developer attention.
It may be acceptable only for disposable, trusted projects, where the machine has no secrets and no access to internal systems.
The main protection here is awareness, not architecture.
Why it is dangerous
This is the highest-risk everyday setup because the AI tool may be close to everything the developer can access:
- other repositories,
- SSH keys,
- .env files,
- cloud credentials,
- internal services reachable from the machine.
If the AI tool can also run commands, the local machine becomes the execution environment.
A malicious instruction, compromised dependency, unsafe script, or wrongly approved command may affect the host directly.
Dangerous scenario
The agent suggests running a setup command.
The command looks like a normal dependency installation, but it downloads and executes a remote script.
Because the tool runs on the main machine, the script can access local credentials and exfiltrate them over the network.
Local machine with hardened security
In this setup, the AI tool still runs locally, but its permissions are restricted.
Many AI coding tools provide configuration options for hardening the environment. These may include sandboxing, tool permissions and network access controls.
For Claude Code, Composable Security covered this with a separate tool and will publish an article about secure local configuration soon – sign up to the newsletter to get informed!
When it is useful
This is a practical improvement over unrestricted local access.
It can work for small, trusted projects where convenience matters and the local environment does not expose secrets, other projects, or internal systems.
Security level: Low
This setup is safer than unrestricted local access because the AI tool may be blocked from editing specific files, running specific commands, or accessing the network.
But it is still not a strong isolation boundary.
Defining strict rules and enforcing them can be tricky. In many cases, the last security layer is still the permission prompt.
A wrong approval, misconfiguration, or unsafe command may still affect the host.
The security comes from permission prompts, limited tool access and careful review – not from real separation from the operating system.
Why it is still dangerous
The important point: permissions are guardrails, not a strong security boundary.
This setup still depends heavily on correct permissions, sandbox configuration and careful human review. That is hard in real workflows.
AI agents can be tricked quite easily, and may ask for many approvals. Some approvals are easy to understand.
Others involve long shell commands, generated scripts, dependency changes, Dockerfiles, CI/CD updates, or package manager hooks.
A tired or rushed developer may approve something without fully understanding it.
Dangerous scenario
The AI tool asks to modify package.json. The change looks like a normal script update, but it adds a command that will run later during installation or deployment.
The change is then pulled by other developers and executed in their workspaces.
At that point, it may bypass the original permissions and sandboxing entirely.
Sandboxed Shell
A sandboxed shell gives the AI tool a restricted command execution environment.
The goal is to allow useful commands while limiting filesystem access, network access and impact on the host.
This can be implemented with a local sandboxing tool, such as agent-safehouse on macOS.
When it is useful
This setup is useful for CLI-first workflows where the AI agent needs to run tests, format code, inspect logs, or execute project commands.
It is also useful when you do not want to rely only on the AI tool’s built-in security controls and want an extra layer around command execution.
Security level: Medium
A sandboxed shell can reduce the blast radius compared with direct local execution, especially when filesystem access, network access, environment variables and command permissions are restricted.
But it is not a strong isolation model by default. Its real security level depends on configuration.
If secrets are available, host directories are broadly mounted, network access is unrestricted, or system services are exposed, the practical security level can quickly fall back to low.
Why it is dangerous
A sandboxed shell is only as safe as its boundaries.
The main risks are:
- too many host directories mounted into the sandbox,
- unrestricted network access,
- secrets available through environment variables,
- privileged execution.
A badly configured sandbox can give a false sense of security.
Example
The sandbox restricts file reads and writes to the project directory. But environment variables still contain cloud credentials.
A command inside the sandbox can read and exfiltrate them.
Safer usage
A sandboxed shell should follow least privilege:
- mount only the required project directory,
- prefer read-only mounts where possible,
- remove unnecessary environment variables,
- block or restrict network access,
- avoid privileged execution,
- use temporary credentials only when needed.
Dev Container
A Dev Container runs the project inside a containerized development environment, usually with good IDE integration.
The editor may run locally, but project tools, terminal, dependencies and runtime execute inside the container.
When it is useful
For many teams, this is the best default. It gives a good balance between security, reproducibility and developer experience.
Dev Containers are especially useful when a project needs a consistent runtime, specific dependencies, local services, or onboarding automation.
They also integrate well with IDEs. For example, IDE extensions can run inside the container instead of directly on the host.
This makes it easier for teams to define a standard development environment.
Security level: Medium
A Dev Container usually gives a better security baseline than running the AI tool directly on the host.
Project commands, dependencies and runtime behavior are moved into a containerized environment, which helps limit accidental impact on the developer’s main machine.
But a Dev Container should not be treated as a strong security boundary. Its security depends on configuration.
If the container runs as root, uses privileged mode, mounts the Docker socket, exposes the developer’s home directory, or receives long-lived secrets, the isolation value drops quickly.
Use secure-by-default configuration.
Why it can be dangerous
A Dev Container is not automatically secure. It can become risky when it is configured to behave like the host.
Common dangerous patterns include:
- mounting the developer’s home directory,
- exposing SSH keys broadly,
- passing long-lived cloud credentials,
- running as root unnecessarily,
- using privileged containers,
- mounting the Docker socket,
- giving unrestricted internal network access,
- sharing the same container across multiple unrelated projects.
The biggest mistake is treating “inside a container” as “100% secure.”
Example
A Dev Container mounts the host’s ~/.ssh directory so Git works easily.
If the AI agent or a dependency reads that directory, private keys may be exposed.
Safer usage
A secure Dev Container should be intentionally limited:
- mount only the project directory,
- use a non-root user,
- avoid privileged mode,
- do not mount the Docker socket,
- avoid mounting the full home directory,
- pass only scoped and temporary secrets,
- restrict network access when possible,
- review devcontainer.json, Dockerfiles, install scripts, and lifecycle hooks.
Virtual Machine
A virtual machine runs a separate operating system on top of the host.
The AI tool, repository, dependencies and commands run inside the VM, not directly on the developer’s main OS.
When it is useful
A VM is a strong choice for untrusted code, sensitive projects, external pull requests, customer-provided repositories and security research.
It is also useful when the developer wants a clear boundary between the main machine and the AI-assisted environment.
Security level: High
A virtual machine provides a stronger isolation boundary than local configuration, a sandboxed shell, or a typical Dev Container.
The AI tool and the code it interacts with run inside a separate operating system. This makes it harder for a compromise to directly affect the developer’s main machine.
The host is better protected, but the risk is not gone.
If sensitive credentials, broad shared folders, clipboard access, VPN connectivity, or internal network access are available inside the VM, an attacker may still reach valuable assets.
Why it can still be dangerous
A VM provides stronger isolation than a container, but it does not remove all risk.
Problems can still happen if:
- secrets are copied into the VM,
- shared folders expose host files,
- clipboard sharing leaks data,
- network access is too broad,
- the VM can reach internal services,
- snapshots are not used,
- the VM becomes long-lived and accumulates credentials.
The VM protects the host better, but the VM itself can still be compromised.
Example
An unknown repository is opened inside a VM, which is good.
But the VM has access to the company VPN and long-lived cloud credentials, for example copied through the clipboard.
A compromise inside the VM can still reach internal systems.
Safer usage
Use the VM as a controlled boundary:
- start from clean snapshots,
- avoid copying personal credentials into the VM,
- use scoped temporary credentials,
- disable unnecessary shared folders,
- restrict clipboard and file sharing for high-risk work,
- limit network access,
- destroy or reset the VM after risky tasks.
Remote Development Environment
A remote development environment runs outside the developer’s laptop.
It may run on a cloud VM, managed workspace, Kubernetes platform, Codespaces-like service, or self-hosted development server.
The IDE may run locally, but the repository, terminal, dependencies, runtime and AI tool run remotely.
When it is useful
This setup is useful for teams that want central governance, standard images, consistent onboarding, disposable workspaces, and less exposure of developer laptops.
It can also help when the company wants to control source code access, logging, secrets, and network policies in one place.
Security level: High
A remote development environment can protect the developer’s laptop because the repository, terminal, dependencies, runtime and AI-assisted execution happen outside the local machine.
But the risk does not disappear. It moves to the remote workspace.
In some cases, the remote environment may even have more privileged access than a local developer machine.
Why it can be dangerous
The risk moves from the laptop to the remote environment.
A remote workspace can still be dangerous if it has:
- broad cloud permissions,
- internal network access,
- persistent secrets,
- access to many repositories,
- weak workspace isolation between users,
- weak logging or governance,
- long-lived environments that are never reset.
It also introduces provider or platform trust.
If a third-party service hosts the workspace, the organization must trust that provider and configure access carefully.
Example
A remote workspace protects the developer’s laptop. But it has access to multiple private repositories and internal deployment credentials.
A compromise may affect more systems than a local machine would.
Safer usage
Remote workspaces should be controlled centrally:
- use standard hardened images,
- assign least-privilege access,
- use short-lived credentials,
- limit repository access per workspace,
- restrict internal network access,
- log important actions,
- destroy or reset workspaces regularly,
- separate workspaces by project and risk level.
Ephemeral Environment Per Task
An ephemeral environment is created for one specific task and destroyed after the task is complete.
The AI agent receives only the repository, tools, credentials and network access needed for that task.
When it is useful
This is the strongest model for high-risk AI-assisted workflows.
It is especially useful for:
- autonomous agents,
- unknown repositories,
- customer-provided code,
- potentially malicious samples,
- high-impact production-related tasks,
- workflows where AI runs many commands with limited human review.
Security level: High
An ephemeral environment per task gives the strongest security model from this list.
Each task starts in a fresh, limited environment. The environment is destroyed after the task is complete.
This reduces persistence, cross-project contamination and long-term credential exposure. The blast radius can be limited to one task.
Why it can still be dangerous
This setup is strong only if the environment receives minimal permissions, short-lived credentials and restricted network access.
Also, the output still needs review. Generated code, scripts, dependency changes and CI/CD modifications can introduce risk after they leave the isolated workspace.
This setup has the smallest blast radius, but it is more complex to build and operate.
Risks remain if:
- the environment receives too many secrets,
- the task permissions are too broad,
- artifacts are trusted without review,
- generated changes are merged automatically,
- network access is unrestricted,
- logs or outputs leak sensitive data.
The environment may be disposable, but its output can still be dangerous.
Example
An ephemeral environment safely contains an external pull request. But the AI agent modifies a build script and opens a merge request.
If the change is merged without review, the malicious behavior can still reach CI/CD or other developers.
Safer usage
This setup should combine isolation with output review:
- provide only task-specific access,
- use short-lived credentials,
- restrict network access,
- destroy the environment after completion,
- review generated diffs carefully,
- pay special attention to scripts, hooks, CI/CD, Dockerfiles, dependencies, and deployment configuration.
Default Recommendation
For most professional teams, broad local access should not be the default.
A well-configured Dev Container or sandboxed shell is usually a better baseline.
For unknown code, sensitive projects, external pull requests, customer-provided repositories, or high-risk AI agents, move up to a VM, remote workspace, or ephemeral environment.
A simple rule:
The more the AI tool can read, execute, modify, or reach, the more isolation the setup needs.
And when unsure:
Move one level up in isolation.
Conclusion
There is no single AI development setup that fits every workflow. The right choice depends on what the AI tool can read, modify, execute and reach over the network. For most professional teams, broad local access should not be the default.
A well-configured Dev Container or sandboxed shell is usually a better baseline for regular development.
For higher-risk work, such as untrusted repositories, customer-provided code, sensitive projects, or autonomous agents, move to stronger isolation: VM, remote workspace, or ephemeral environment.
Need help choosing the right setup?
If you are introducing AI coding agents in your team, Composable Security can help you create a threat model of your workflow, choose a reasonable isolation level, review your configuration, or harden the right isolation level for your team.
Email us at info@composable-security.com or DM us on Telegram at @drdr_zz or @wh01s7.
Meet Composable Security
Get throughly tested by the creators of Smart Contract Security Verification Standard
