Skip to content

Working safely with agent

Agentic Coding present a high security risk if not used properly. The agent can be used to execute arbitrary code, which can lead to unintended consequences if the code is malicious or contains bugs. To mitigate these risks, it is important to follow best practices when working with agentic coding.

The best practices include:

  1. Use a sandbox environment: Always run agentic code in a sandbox environment that is isolated from your main system. This can help prevent any malicious code from affecting your main system.
  2. Review code before execution: Always review the code generated by the agent before executing it. This can help you identify any potential security risks or bugs in the code.
  3. Limit permissions: If possible, limit the permissions of the agentic code to only what is necessary for it to function. This can help prevent any malicious code from accessing sensitive information or performing harmful actions.
  4. Use version control: Use version control systems like Git to track changes to your codebase. This can help you identify when and where any malicious code was introduced, and allow you to revert to a previous version if necessary.
  5. Keep dependencies up to date: Ensure that all dependencies used by the agentic code are up to date with the latest security patches. This can help prevent any known vulnerabilities from being exploited by malicious code.
  6. Educate yourself and your team: Stay informed about the latest security best practices and educate your team on how to work safely with agentic coding. This can help create a culture of security awareness and reduce the risk of security incidents.

By following these best practices, you can help mitigate the security risks associated with agentic coding and ensure that your code is safe to execute.

Use a sandbox environment

Lima VM

We recommend Lima as it works on Mac, Linux and Windows.

The usage of Lima has been inspired by agent-vm.

brew install lima Brew works on Linux Mac and Windows (via WSL).

You have many options for your code with Lima:

  • Mount your code into the VM and run the agent there. You use you code editor on your local machine and run the agent in the VM. This is a good option if you want to keep using your local development environment and only run the agent in the VM. this way you could delete the VM without losing your code.
  • Clone the repo inside the VM and run the agent there. Then connect your VSCode inside the VM. This could be nice to avoid missing to use the VM when running agent as the code will only be in the VM.
  • Use --sync mode to sync your local file into the VM but be prompted before syncing from the VM to your local file.

To allow easy SSH to the VM, add the following line to ~/.ssh/config:

Include ~/.lima/*/ssh.config
limactl start --yes --name=codecarbon --mount-only .:w
# Install basic tools into VM
limactl shell codecarbon bash -l < "scripts/agent-vm.setup.sh"

Useful commands

List running VMs: limactl list

Enter the VM: limactl shell codecarbon

Stop a VM: limactl stop codecarbon

Start a VM: limactl start codecarbon

Delete a VM: limactl delete codecarbon

OpenCode configuration

We include a sample configuration file for OpenCode with Azure Cognitive Services. You can copy it and edit it with your credentials to set up your environment variables in the VM:

cp scripts/agent-vm.personal.config.sh-sample scripts/agent-vm.personal.config.sh
# Edit the file with your credentials and configuration, then run it to set up your environment variables
limactl start codecarbon
limactl shell codecarbon bash -l < "scripts/agent-vm.personal.config.sh"

Add a read-only GitHub token for GitHub CLI

If you want to use gh inside the VM to inspect issues, pull requests, or repository metadata without granting write access, use a fine-grained personal access token with read-only permissions.

  1. In GitHub, click on your avatar, go to Settings > Developer settings > Personal access tokens > Fine-grained tokens.
  2. Create a token scoped only to the repositories you need. For CodeCarbon's projects we allow only tokens with an expiration date.
  3. Grant only the minimum repository permissions you need. For read-only gh usage on this repository, Metadata: Read-only is required, and Pull requests: Read-only, Issues: Read-only, and Contents: Read-only are usually enough.
  4. Add the token to your VM configuration script scripts/agent-vm.personal.config.sh, then re-run:
limactl start codecarbon
limactl shell codecarbon bash -l < "scripts/agent-vm.personal.config.sh"

You can then verify that GitHub CLI sees the token:

limactl shell codecarbon bash -l -c "gh auth status"

Using GH_TOKEN keeps the setup explicit and avoids logging in interactively inside the VM. If you only need occasional anonymous access to public data, gh can work without a token, but GitHub rate limits are much lower.

Then, to use OpenCode in the VM, you can run:

limactl shell codecarbon bash -l -c "opencode"

Other options

If you are already comfortable with other containerization or virtualization tools, here’s a quick comparison of the most popular options for securely running agentic code:

Feature Docker Docker Sandbox Canonical LXC/LXD Lima
Isolation strength Medium (namespaces, seccomp) High (micro-VM) High (VM-like containers) High (actual VM)
Host escape risk Medium Very low Low Very low
Ease of use Excellent Excellent Moderate Moderate
Reproducibility Excellent Excellent Good Good
macOS support Via Docker Desktop Via Docker Desktop Poor Excellent
Windows support Via Docker Desktop Via Docker Desktop Poor Good
Linux native Excellent Via Docker Desktop Excellent Good
Performance Excellent Good (slight VM overhead) Excellent Slight overhead
Fine-grained security controls Limited Moderate Very strong Strong
Agent autonomy safety Medium High High Very high
Docker inside VM No No Possible Yes

Use Docker if:
Your agent is constrained, non-root, and runs with seccomp/AppArmor profiles.

Use Docker Sandbox if:
You want Docker's ease of use with micro-VM isolation — no extra setup needed.

Use LXC/LXD if:
You are serious about security and performance on Linux.

Use Lima if:
You don’t want Docker Desktop’s attack surface.