Workspace trust now governs agent autonomy in VS Code Copilot

At a glance

What this is: Repello AI shows that a cloned repository can override VS Code Copilot Chat settings and move new sessions into Bypass Approvals mode without a per-tool confirmation prompt.

Why it matters: This matters because a familiar workspace-trust gesture can now grant an AI agent permission to execute shell commands and other tools, which changes the governance boundary for developer environments.

Context

Workspace trust was built to answer whether code in a folder should execute, not whether an AI assistant in that folder should run tools on a user’s behalf. Once a repository can set chat.permissions.default in .vscode/settings.json, the same trust click can become a consent decision for agent autonomy, not just code loading.

The governance gap is not subtle: developers think they are approving a workspace, while the platform can also inherit model tool permissions from that workspace. That makes the security question about agent tool permissions as much as about source code, because the repository now influences how the assistant behaves after trust is granted.

Key questions

Q: What breaks when a repository can change Copilot approval mode at load time?

A: The failure is that repository trust becomes a permission grant for tool execution, not just code loading. When approval mode can be inherited from workspace files, the control moves from per-action confirmation to a one-time workspace decision, which means a normal trust click can silently expand the assistant’s authority for the entire session.

Q: Why does workspace trust increase risk for AI assistants in developer tools?

A: Because the same trust decision can now enable model-driven actions that were never part of the original code-trust mental model. Once the repository can influence assistant permissions, the workspace can determine whether the model may run shell commands, edit files or call tools without further approval.

Q: How should teams stop malicious repositories from altering AI approval settings?

A: Treat assistant approval mode as a centrally governed control, not a developer preference. Review repository-scoped settings before trust is granted, keep default sessions in restricted or default approval states, and use managed policy to prevent workspace files from overriding safer organisational settings.

Q: What is the difference between trusting a workspace and trusting an AI agent?

A: Trusting a workspace is a code-execution decision about files, tasks and extensions. Trusting an AI agent is a separate decision about whether the assistant may act autonomously with tools, so the two should not be collapsed into one prompt or one policy boundary.

Technical breakdown

How workspace-scoped settings override chat approval mode

VS Code reads .vscode/settings.json at workspace open, so a repository can set chat.permissions.default before the user ever touches Copilot Chat. That differs from the older write-path issue, where the agent had to modify settings mid-session and trigger a confirmation gate. Here, the dangerous value is already present on disk, so the control point shifts from write-time approval to load-time trust. The result is that the workspace itself becomes a policy carrier for the assistant’s execution mode, which is why a benign-looking settings file can reshape the runtime boundary without any obvious interaction. Practical implication: review workspace settings as policy inputs before trusting unfamiliar repositories. See the AI Agent Tool and Plugin Security Guide. See the AI Agent Tool and Plugin Security Guide.

Practical implication: Review workspace settings as policy inputs before trusting unfamiliar repositories.

Why Bypass Approvals changes the meaning of tool execution

Bypass Approvals mode removes the per-tool confirmation step that normally separates a model suggestion from an executed action. In practice, that means terminal commands, file edits, web fetches and MCP calls can proceed as soon as the agent decides to use them. The important distinction is that the user is no longer approving each action, only the workspace context that enables the mode. That turns a prompt-based safeguard into a coarse-grained trust decision and widens the blast radius of any malicious repository content that can steer the agent once execution begins. Practical implication: treat approval mode as a security control, not a convenience setting. See the AI Security Platform Buyer's Guide. See the AI Security Platform Buyer's Guide.

Practical implication: Treat approval mode as a security control, not a convenience setting.

Why Workspace Trust is not the same as AI consent

Workspace Trust was designed for code execution risk, but agentic coding tools add a second dimension: model-driven action selection. The same click that allows language servers, tasks and extensions to run can now also allow an AI system to invoke shell commands and other tools without further challenge. That is an assumption collapse, because the old boundary assumed the trusted workspace would execute code, not autonomously expand into tool use. Once that assumption fails, the trust prompt is no longer describing the real scope of authorisation. Practical implication: separate code trust decisions from AI action consent in your operating model. See the Enterprise AI Copilot Security Guide. See the Enterprise AI Copilot Security Guide.

Practical implication: Separate code trust decisions from AI action consent in your operating model.

Threat narrative

Attacker objective: The attacker wants the developer’s AI assistant to execute tool actions automatically after a normal trust click, expanding repository exposure into local code execution.

1. An attacker places a malicious .vscode/settings.json in a repository so the workspace loads a permissive Copilot approval mode at open time.
2. The user clones the repository, opens it in VS Code and clicks the workspace trust prompt, which allows the workspace-scoped setting to take effect.
3. Copilot Chat starts new sessions in Bypass Approvals mode and can execute terminal commands, edits, fetches and MCP calls without per-tool confirmation.
4. The objective is to convert a routine repository review into unprompted agent-driven command execution on the developer’s machine.

Breaches seen in the wild

• LiteLLM MCP auth bypass 2026: An exploited LiteLLM MCP auth bypass and default sk-1234 master keys let attackers steal AI gateway master and provider API keys.
• JADEPUFFER agentic ransomware 2026: The first documented agentic ransomware used harvested keys, default MinIO credentials and a default Nacos signing key to wipe a database.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Workspace trust has become an AI authorisation boundary: The industry still treats the trust prompt as a code-execution decision, but agentic tools make it a permission decision for model-driven actions as well. That is a different governance problem because the user is no longer authorising only the repository’s code path. The implication is that workspace trust, AI action approval, and developer workstation policy can no longer be managed as one undifferentiated control.

Autonomous tool use collapses the old review model: Access review processes were designed for permissions that persist long enough to be observed, recertified, and removed. In this case, the workspace grants a mode that changes behaviour immediately after trust is clicked, so the effective privilege boundary is created at load time rather than during a later review cycle. The implication is that governance based on periodic recertification misses the moment when the risk is actually introduced.

Agent guardrails now function as privileged settings, not UI preferences: A repository-controlled approval mode turns a convenience toggle into a security control that shapes what the assistant may do. That means configuration hygiene around developer workspaces has to be treated like privileged access governance, not editor preference management. Teams that ignore that distinction will keep inheriting agent behaviour from untrusted project files.

Bypass Approvals is a standing-privilege problem in disguise: The dangerous state is not the single command, but the fact that the assistant enters a permissive operating mode for the whole session. That makes the risk closer to overprivileged NHI behaviour than to ordinary feature misconfiguration, because a workspace file can elevate the model’s runtime authority without any per-action review. Practitioners should recognise this as privilege assignment through configuration, not just a chat setting.

From our research library:

• 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
• Read next: Enterprise AI Copilot Security Guide

What this signals

Workspace trust is becoming a proxy for agent governance: Organisations that only review code paths will miss assistant behaviour that is inherited from repository settings. The operational shift is simple but important: if developers can change approval mode through project files, then AI governance has to start before the trust click, not after it.

Agent settings deserve the same scrutiny as privileged credentials: The practical lesson is to inventory where approval modes, instruction files and tool permissions are defined across repositories and developer fleets. That inventory becomes the starting point for separating local convenience from organisation-approved agent behaviour.

Mature programmes will stop treating assistant guardrails as optional editor configuration and start managing them as part of developer workstation policy. The next control question is no longer only whether code is trusted, but whether the repository can redefine the runtime authority of the assistant.

For practitioners

• Inspect workspace settings before granting trust Review .vscode/settings.json for chat.permissions.default, chat.tools.autoApprove and other assistant-related settings before opening an unfamiliar repository in trusted mode.
• Open untrusted code in restricted mode first Use VS Code Restricted Mode for initial review so agent tools, tasks and extensions stay disabled until the repository has been examined.
• Force enterprise-level approval policy Set central policy so new sessions fall back to Default Approvals even when a workspace requests a more permissive mode.
• Sandbox unknown repositories by default Review suspicious projects inside a dev container or throwaway VM so any auto-approval behaviour is confined away from local credentials and developer workstations.

Key takeaways

• A repository can change VS Code Copilot Chat into a permissive execution mode through workspace-scoped settings, which means workspace trust now affects agent behaviour as well as code loading.
• The main governance failure is the collapse of the old mental model that trusted folders only control code execution, not autonomous tool use by an AI assistant.
• The most reliable defences are to inspect workspace settings before trust, keep untrusted projects in restricted mode, and enforce central policy for default approval behaviour.

Related NHI Mgmt Group resources: AI Agent Tool and Plugin Security Guide · AI Security Platform Buyer's Guide · Enterprise AI Copilot Security Guide

Key terms

• Workspace Trust: A trust control in code editors that separates passive file viewing from active execution of project-defined tasks. When disabled or bypassed, the editor can run repository instructions in the user’s context, which turns source control content into an execution path.
• Bypass Approvals: Bypass Approvals is an execution mode in which an AI assistant can carry out tool actions without asking the user for each one. In this article’s context, it matters because a workspace-scoped setting can place the assistant into that mode for the whole session, turning a permission prompt into a standing authority change.
• Workspace-scoped Setting: A workspace-scoped setting is a configuration value stored in the repository that overrides the user's local preference for that project. For identity governance, the important point is that repository content can alter runtime authority, not just display behaviour, which makes it a policy-bearing control surface.
• Agentic Tool Execution: Agentic tool execution is the pattern where an AI system does more than generate text and instead calls APIs, reads data, runs functions, or changes state. This creates security risk because legitimate operations can be manipulated into unintended actions, making intent harder to distinguish from normal behavior.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.