Run it where it cannot reach anything valuable: a throwaway container or virtual machine, a separate operating system account, no production credentials, and restricted network access. Most developer plugins run with the user's full permissions, so isolation has to come from where you run them, not from the plugin.
Why isolation is on you
The documentation for several common tools is consistent. VS Code says the extension host has the same permissions as the editor. Kubernetes says kubectl plugins are arbitrary programs running on your machine. The Model Context Protocol security guidance says local servers run with the same privileges as the client, and recommends sandboxing with minimal default privileges. None of these tools puts a wall around the plugin for you.
Four isolation options
| Option | Isolation strength | Convenience | Good for |
|---|---|---|---|
| Separate editor profile or workspace trust | Low: limits clutter and project code, not extension behavior | High | Keeping unfamiliar projects away from your main setup |
| Separate operating system account | Medium: separate files and credentials | Medium | Trying a tool without exposing your main home directory |
| Container or dev container | Medium to high, depending on mounts and network | Medium | Reproducible, throwaway trials |
| Virtual machine or spare device | High | Lower | Anything suspicious, or tools with native code |
Be careful with the first row. VS Code's Workspace Trust documentation says it cannot stop a malicious extension from executing code and ignoring Restricted Mode. A profile helps you separate sets of extensions, but it is not a security boundary.
What to restrict, in order of value
- Secrets. Start with nothing: no cloud credentials, no source host tokens, no SSH agent forwarded in. If the plugin needs access to do its job, give it a scoped, short lived credential created for the trial.
- Files. Mount only the project you are testing, read only if the tool allows it. Never mount your home directory.
- Network. Block outbound traffic or allow only the hosts the tool needs, and watch what it tries to reach. The attempts are informative.
- Privileges. Run as an unprivileged user. Avoid elevated rights and anything that modifies system configuration.
- Time. Use a disposable environment you can delete when finished.
A repeatable trial
- Write down why you want the plugin and what it should access.
- Create the isolated environment from a clean image.
- Install the exact version you plan to use and record its checksum or version string.
- Run the tool on a sample project with no real secrets.
- Capture network connections, file writes and processes created. Compare with what the README claims.
- Decide: approve, approve with limits, or reject. Record who decided and when.
- Destroy the environment.
If you approve, move to normal distribution: allowlist, pinned version, owner. The trial is not the approval, it is the evidence for it.
Limits to remember
A sandbox does not make a bad plugin good. It limits damage during evaluation. Some tools need real credentials to function, so the trial may not reveal behavior that only triggers with them. Some malicious code waits before acting, or checks whether it is in a virtual machine. Treat a clean trial as reassurance, not proof, and keep logging in production use.
Make it cheap
If trials are painful, people skip them. Keep a ready to use image, a short runbook and a shared place to record results. A five minute path to a safe trial changes behavior more than a policy document.
Where Safeguard fits
Safeguard's SBOM and dependency scanning can list what a plugin pulls in before you run it, and policies and gates can enforce your approval decision. The free scan is at gold.safeguard.sh/scan.
Quick check
Is a separate editor profile a sandbox?
No. It separates sets of extensions and settings, but extensions in a profile still run with the editor's permissions.
What should a trial environment contain?
A clean image, a sample project, no real secrets, limited network and a plan to delete it afterwards.
Sources
- Extension runtime security, Visual Studio Code documentation
- Workspace Trust, Visual Studio Code documentation
- Extend kubectl with plugins, Kubernetes documentation
- Security best practices, Model Context Protocol
Last reviewed: 19 October 2026.
