Not by default. The real question is not whether you trust the AI, but what it can reach when something goes wrong.
Agentic Coding Assistants Era
AI coding tools are no longer just autocomplete. Claude Code, Cursor, GitHub Copilot coding agents and similar tools can read your repository, suggest changes, run commands, install dependencies and inspect logs.
This is useful. It also changes the security model of a developer workstation.
The question is not only whether we trust the AI tool. The better question is: what can it reach if something goes wrong?
What Can Go Wrong When an AI Coding Tool Has Too Much Power?
AI coding tools are useful, but too much access changes the risk.
One bad decision, malicious instruction, or compromised dependency can be enough to cause real damage. Recent supply-chain attacks, such as axios or Mini Shai-Hulud, are good examples of why this matters.
The main risks are:
- Secret exfiltration
The tool may expose API keys, SSH keys, .env files, cloud tokens, database credentials, or package registry tokens.
Example: a command sends a local API key/token to an external endpoint. - Host compromise
If the agent can run commands on the host, it may install malware, change shell configuration, modify permissions, or create persistence for later use.
Example: an approved command downloads and runs a remote script on the developer’s machine. - Compromising other workstations
The agent may add or modify commands that do not run immediately, but execute later during install, build, test, or deployment.
Example: a postinstall script in package.json runs when another developer installs dependencies. - Lateral movement
Once the environment is compromised, the attacker may use available credentials, filesystem access, or network access to reach other repositories, internal services, CI/CD systems, cloud accounts, or future builds.
Example: a stolen SSH key is used to access other private repositories or deployment infrastructure. - Destructive changes
The agent may delete, overwrite, or corrupt files, configuration, data, branches, databases, or cloud resources. This can be malicious or accidental.
Example: a command removes the wrong directory, rewrites configuration, or applies an unsafe migration.
The common theme is blast radius. If the agent can only see one repository with no secrets, the damage is limited.
If it can see your home directory, SSH keys, cloud credentials, internal services and other projects, then one wrong command can become a real incident.
The goal is simple: give the AI tool enough access to be useful, but not enough access to make one mistake catastrophic.
Questions to Ask Before Choosing an AI Coding Assistant Setup
Before choosing a setup, start with two practical questions.
Is the codebase trusted?
The first question is not whether we trust the AI tool. It is whether we trust the code we are about to open.
A repository can contain install scripts, hooks, build steps, editor settings, CI files, local configuration, hidden instructions, or dependencies that execute code automatically.
This is not only an AI problem. It is the same problem we already have with code from unknown sources, just with a more capable assistant in the loop.
Untrusted code does not only mean random repositories from the internet. It also means external pull requests, generated code, customer-provided projects, old codebases, and security research samples.
A good default is limited trust.
FYI: even when the repository is trusted, a pull request can still introduce dangerous code — by accident, through a compromised dependency, or through an insider threat.
So even if the project looks normal, it should not immediately get access to your full machine, personal files, SSH keys, cloud credentials, internal network, or production secrets.
The problem with “trust this workspace”
Many AI coding tools and editors ask whether we “trust this folder” or “trust this workspace.”
This looks like a simple confirmation dialog, but it may enable extensions, scripts, terminals, project-specific configuration, or deeper AI access to the workspace.
In practice, developers often accept these prompts quickly because they want to start working. Sometimes they do not fully understand what the tool means by “trust.” Sometimes they assume it is a harmless editor question. For AI-assisted development, this habit can be risky.
That is understandable, but risky. The safer approach is simple:
Treat unfamiliar code as untrusted first, and increase trust gradually only after understanding what the project can execute and what resources it can reach.
What access will the AI Coding Assistant environment have?
A development environment is not risky only because of the source code it contains. It is risky because of everything the AI agent can reach from inside that environment.
This includes:
- files and directories mounted into the workspace,
- environment variables,
- .env files and local configuration,
- SSH keys,
- cloud credentials,
- package registry tokens,
- database credentials,
- access to internal services,
- access to production-like systems,
- network connectivity,
- shell command execution,
- package managers, build scripts, and test runners.
The broader the access, the stronger the isolation should be. A useful question here is: do you actually know what sensitive data is available on your host machine?
Reading code is one thing. Running commands is different.
Once the agent can run `npm install`, execute tests, start services, modify files, or call external tools, the workspace is no longer just an editor context. It is an execution environment.
Secrets deserve special attention. A safe default is simple: do not mount secrets into an AI-assisted workspace unless they are explicitly required. When they are required, they should be scoped, temporary, and limited to the specific task.
Network access should also be intentional. A project may need internet access to install dependencies. It probably does not need access to the whole internal network, production databases, metadata services, private package registries, or cloud control planes.
A useful rule is:
Give the AI-assisted environment only the access it needs for the current task – nothing more.
If the workspace has broad filesystem access, long-lived credentials, internal network access, and command execution enabled, it should be treated as a high-risk environment even if the repository itself is trusted.
Available Setup Options
Once we understand the risk, we can choose the setup. The options below are ordered roughly from least isolated to most isolated.
| Option | Setup difficulty | Security level | Developer experience | Best for | Main limitation |
| Local machine, no isolation | Very low | Very low | Excellent | Quick experiments on host with no secrets and high security awareness, but avoid | AI tools can access too much of the host |
| Local machine, hardened config | Low | Low | Very good | Small trusted projects with high security awareness | Depends on correcttool configuration,which is easy to get wrong |
| Dedicated OS user | Low | Medium | Good | Basic separation without containers | Same operating system and weaker isolation boundary |
| Sandboxed shell | Medium | High | Good | CLI-first workflows and reproducible execution | Requires careful configuration of volumes, users, and networking |
| Dev Container | Medium | High | Very good | Most professional development workflows | Misconfigured mounts, Docker socket access, and secrets can weaken isolation |
| Virtual machine | High | High | Medium | Sensitive work and untrusted repositories | Heavier setup and less convenient daily workflow |
| Remote environment | High | High | Good | Teams needing centralized control and disposable workspaces | Requires provider trust, governance, and cost control |
| Ephemeral environment per task | High | Very high | Medium | High-risk agentic workflows | Requires automation and infrastructure maturity |
How much convenience are you willing to trade for safety?
Every isolation model has a cost.
Running everything locally is fast and familiar. Dev Containers require some setup. Virtual machines are heavier. Remote or ephemeral environments need more infrastructure.
The right choice depends on the risk.
For low-risk experiments, convenience may matter more. For sensitive repositories, production infrastructure, customer data, or unknown code, safety should dominate.
The point is not to maximize security in every situation. The point is to avoid using a low-isolation setup for a high-risk task.
Expanding the Key Questions
The options above are easier to choose when we break the problem down.
Trusted vs. Untrusted Code
If the code is trusted, actively maintained by your team, and already used in your normal development workflow, a Dev Container or a restricted local setup may be enough.
If the code is unfamiliar, cloned from the internet, submitted by an external contributor, or provided by a customer, treat it as untrusted.
Do not open it directly on your main machine with full permissions. Start in a container, VM, remote workspace, or ephemeral environment.
Security Awareness Level
The setup should also depend on how confidently the developer can review AI actions.
A focused, security-aware developer may allow more. A rushed, tired, or less experienced developer should rely more on technical isolation, not manual approvals.
No Secrets vs. Scoped Secrets vs. Broad Secrets
The safest setup is one where the AI-assisted environment has no secrets or sensitive data at all.
If the environment contains only public source code and test data, the risk is lower.
If it contains secrets, production configuration, customer data, proprietary algorithms, internal documentation, or infrastructure code, the risk is much higher.
If secrets are needed, they should be scoped to the task, short-lived and limited in permissions.
The riskiest setup is one where the agent can access broad developer credentials, such as personal SSH keys, long-lived cloud tokens, production database passwords, or unrestricted package registry tokens.
Also: production configuration with credentials should not be kept on your machine in the first place.
Single vs Multiple Projects and Users
The risk grows when the AI-assisted environment can reach more than one project or affect more than one developer.
If the environment contains multiple repositories from different projects, a compromise in one project may spread to others and leak or maliciously modify them.
In team projects, the risk is higher. A malicious or unsafe change may be committed and later executed on another developer’s machine, in CI/CD, or in a future build.
The more projects and users a workspace can affect, the stricter the isolation should be.
Read-Only Assistance vs. Command Execution
There is a major difference between an AI assistant that only reads code and an AI agent that can execute commands.
The second case is becoming more common, because we want AI to “do some work” for us.
Command execution means the agent can trigger scripts, run package managers, start services, modify files and interact with the system.
At that point, the shell environment becomes part of the security boundary.
If command execution is allowed, isolation should be stronger. If command execution is not needed, block it.
Open Network vs. Restricted Network
Network access should match the task.
Installing dependencies may require internet access. Running unit tests may not require network access at all.
Debugging internal services may require access to specific systems, but not to the entire internal network.
For untrusted code, restrict network access by default.
Matching Answers to Setup Options
One setup will not fit all cases.
Use the selection algorithm for each project, not once for the whole company.
You can also combine setups. For example: Dev Container + hardened Claude config.
After choosing the base setup, you can still restrict files, mounts, secrets, command execution, or network access. We will cover this in the next articles.
Our default for most teams would be a Dev Container.
It is not perfect, but it gives a good balance: reasonable isolation, good developer experience, and IDE integration. It also moves tasks and extensions into the container instead of running everything directly on the host.
The diagram below shows how to choose the minimal reasonable setup based on the answers.
You can always choose the most secure option, but in practice developers and businesses will not accept a setup that is too slow or inconvenient for daily work.
The table below is a practical shortcut.
| Situation | Recommended setup |
| Quick experiment with disposable code and no secrets on the machine | Local machine with hardened configuration, ideallywith a separate OS user. |
| Trusted team repository with normal development workflow | Dev Container (for additional layer of security and IDE integration). |
| Trusted code but some sensitive configuration | Dev Container (with scoped secrets and limited mounts) |
| Unknown repository from the internet | (Ephemeral) VM or Dev Container (with no secrets and limited mounts) |
| External pull request from an unknown contributor | (Ephemeral) VM or Dev Container (with no secrets and limited mounts) |
| Customer-provided code | (Ephemeral) VM or Dev Container (with no secrets and limited mounts) |
| Project requires production-like credentials | Tightly controlled Dev Container (with scoped temporary credentials and hardened config blocking access to credentials) |
| AI agent needs to execute commands autonomously | VM, Dev Container (with no secrets and limited mounts) or remote environment |
| Security research or potentially malicious code | (Ephemeral) VM, Dev Container (with no secrets and limited mounts) or remote environment |
| Team wants centralized governance and consistent setup | Remote environment |
| High-risk autonomous agent workflow | Ephemeral Dev Container (with no secrets and limited mounts) or remote environment per task |
A simple rule of thumb:
- The less you trust the code, the data, the commands, or the network access, the more isolated the environment should be.
For many teams, the practical default is a well-configured Dev Container.
For unknown code, sensitive projects, or autonomous agents, stronger isolation is usually justified: VM, remote workspace, or ideally an ephemeral environment.
Need help choosing the right setup?
If you are introducing AI coding agents in your team, we can help you threat model the workflow and choose a reasonable isolation setup.
This usually means checking:
- what code the agent can access,
- what secrets are available,
- whether commands can be executed,
- what network access exists,
- and how the setup works for developers in practice.
Email us at info@composable-security.com or DM us on Telegram: @drdr_zz or @wh01s7.
Meet Composable Security
Get throughly tested by the creators of Smart Contract Security Verification Standard
