Understand trust and safety for AI agents

AI-generated output requires review. Visual Studio Code includes multiple mechanisms to keep you in control of what changes reach your codebase. This article explains the control mechanisms, AI limitations, and security considerations you should be aware of.

Stay in control

Agents can read files, edit code, run terminal commands, and call external services. VS Code's trust model layers several control mechanisms so you remain in charge of what reaches your codebase:

• Review before integrating. Agents can save edits directly in the session folder or worktree. Inspect the changes in a diff before you commit, merge, or create a pull request. For supported sessions, checkpoints restore affected workspace files and chat to an earlier point.
• Approve sensitive actions. With Manual permissions in Agent Host sessions, actions that aren't covered by your approval settings require confirmation. File edits might be auto-approved. Configure sensitive-file approval when an edit must require confirmation before it is applied.
• Constrain autonomy. Permission levels decide how much the agent runs on its own, from per-call approvals to broad auto-approval, up to fully autonomous operation with Autopilot.
• Enforce boundaries at the OS level. Agent sandboxing restricts file system and network access for terminal commands so auto-approved actions cannot escape a defined scope.
• Trust boundaries. VS Code prompts you before granting trust to workspaces, extensions, MCP servers, and network domains.

For step-by-step configuration of these controls — approval rules, sensitive-file protection, sandboxing setup, organization policies — see AI security in VS Code.

Always review AI-generated code before committing. Verify that it handles edge cases, follows your project's conventions, and doesn't introduce security issues. Stopping a request or restoring workspace files doesn't reverse completed terminal commands, network requests, deployments, or changes to external services.

Trust boundaries

VS Code's security model uses trust boundaries to limit the potential impact of untrusted code. Each trust boundary requires explicit consent before it is considered trusted:

• Workspace: controls whether VS Code enables features like tasks, debugging, and workspace settings that can execute code from the project. An untrusted workspace runs in restricted mode, which also disables agents.
• Extension publisher: controls whether extensions from a given publisher can be installed and run. VS Code prompts you to trust the publisher before activating their extensions.
• MCP server: controls whether an MCP server can start and provide tools. VS Code prompts you to trust each MCP server before it runs, and re-prompts after configuration changes.
• Network domain: controls whether the agent can fetch content from a URL. VS Code prompts you to trust a domain before making requests to it, integrated with the Trusted Domains list. You can also enable chat.agent.networkFilter Open in VS Code Open in VS Code Insiders to restrict which domains agent tools and sandboxed terminal commands can access.

You can revoke trust at any time through dedicated commands in the Command Palette. For steps to configure these controls, see AI security in VS Code.

Agent sandboxing

Agent sandboxing uses operating system-level isolation to restrict what agents can access on your machine. Instead of relying solely on approval prompts before each action, sandboxing defines strict boundaries for file system and network access that are enforced by the OS itself.

VS Code applies sandboxing to terminal commands (runInTerminal agent tool) that are executed during an agent session, including Copilot Agent Host sessions. Learn how to configure agent terminal sandboxing.

By default, VS Code automatically approves terminal commands that run in the sandbox without a confirmation prompt because they already run in a controlled environment.

Why sandboxing matters

Approval-based security requires you to confirm each terminal command or tool call before it runs. While this provides control, it has practical limits:

• Approval fatigue. Repeatedly approving commands can cause you to pay less attention to what you're approving, especially during long agent sessions.

• Parsing limitations. Auto-approval rules use best-effort command parsing, which has known limitations. Shell aliases, quote concatenation, and complex shell syntax can bypass the rules and slip through undetected.

• Prompt injection. Malicious content in files, tool outputs, or web pages can attempt to trick the agent into running harmful commands. If you approve without careful review, it might result in unintended actions and security risks.

• Unintended actions on external services. Even without malicious intent, an agent with network access can perform actions on your behalf that are difficult to reverse. For example, the agent might provision cloud resources, modify infrastructure settings, push code to a remote repository, or call an API that triggers a deployment or a financial transaction. Network isolation ensures the agent can only reach domains you explicitly permit, reducing the risk of unintended side effects on external services.

Sandboxing addresses these challenges by enforcing boundaries at the OS level. The sandbox prevents auto-approved commands from accessing files or network resources outside the permitted scope. If additional permissions are required, VS Code prompts you to run the command outside the sandbox. You can configure VS Code to try the command inside the sandbox before showing that elevation prompt.

How sandboxing works

Sandboxing enforces two types of isolation:

• File system isolation limits read and write access to configured paths. It protects sensitive locations, such as SSH keys and shell configuration, and applies to child processes such as package managers and build scripts.
• Network isolation limits outbound connections to configured domains. It reduces the risk of data exfiltration and unintended actions on external services.

Both boundaries are applied at the operating system level and inherited by child processes. You can configure file system and network access separately. For default behavior and configuration steps, see Sandbox agent terminal commands.

OS-level enforcement

Agent sandboxing relies on OS-level security primitives to enforce file system and network restrictions. Because the enforcement happens at the kernel level, sandboxed processes and all of their child processes cannot bypass these boundaries, even if a command is crafted to attempt it.

WSL version 1 is not supported because bubblewrap requires Linux kernel features (user namespaces) that are only available in WSL2.

What sandboxing does not cover

Agent sandboxing applies to shell subprocesses, including terminal commands from VS Code agent sessions and Copilot agent-host sessions. It does not cover built-in file tools. The agent's read, edit, and write tools use VS Code's permission system directly, rather than running through the sandbox.

Use the review flow and sensitive file protection to control these operations.

For full environment isolation, pair sandboxing with a dev container. Dev containers provide a complete boundary around the entire development environment, including all tools, file access, and network access.

Agent sandboxing continues to evolve to cover more tools and scenarios.

AI limitations to watch for

Incorrect output. Models can generate code that looks correct but contains bugs, uses deprecated APIs, or doesn't handle edge cases. Always test AI-generated code, especially for logic that affects security, data integrity, or critical flows.

Prompt injection. Malicious content in files, tool outputs, or web pages can attempt to redirect the agent's behavior. This is why VS Code includes tool approval gates and trust boundaries. Learn more about AI security.

Treat AI-generated output as a first draft: useful as a starting point, but always requiring your review and judgment. For more on how models work, including nondeterminism, knowledge boundaries, and context limits, see Language models.

Related resources

• AI security considerations
• Terminal sandbox configuration
• Reviewing code edits