Secure the developer workstation: extensions, package managers, secrets and AI agents

A developer machine can push code, publish packages and reach cloud accounts, and it runs whatever the editor, the package manager and the agent decide to run. The incidents below each used one of four routes. None needed a vulnerability in the operating system; all of them used features working as designed.

Extensions run with the user's full permissions, with no sandbox, and update automatically. Treat them like dependencies: decide which ones you need, allow only those, and update deliberately. Since VS Code 1.96, the extensions.allowed setting, and the AllowedExtensions policy that device management can enforce, allow extensions by publisher, by ID, by exact version or only stable releases. Once it is set, everything else is blocked and already-installed extensions that are not allowed are disabled. Version ranges are not supported, so a pinned entry lists exact versions.

A verified publisher badge on the Visual Studio Marketplace shows that the publisher proved control of a domain; it says nothing about the code in the next release. VS Code forks such as VSCodium and Cursor install from Open VSX rather than the Visual Studio Marketplace, so the same extension name can come from a different registry with a different publisher account; allow-list in each editor your team uses. Open VSX has since added pre-publication checks for impersonation, embedded secrets and known malicious patterns, shorter token lifetimes and trusted publishing; checks lower the risk but are not a code review. Turning off automatic extension updates trades fast fixes for a review step; if you keep them on, an allow-list by exact version still stops a compromised update from installing.

{
  "extensions.allowed": {
    "microsoft": true,
    "github": true,
    "esbenp.prettier-vscode": true,
    "dbaeumer.vscode-eslint": "stable"
  },
  "extensions.autoUpdate": false,
  "security.workspace.trust.enabled": true,
  "security.workspace.trust.untrustedFiles": "prompt",
  "task.allowAutomaticTasks": "off"
}

Opening a folder can run code without any install step: tasks set to runOn: folderOpen, workspace settings that point at executables, debugger launch configurations, extension behavior driven by workspace files, and agent hooks and MCP server definitions committed to the repository. VS Code's Workspace Trust starts unfamiliar folders in Restricted Mode, which limits the terminal, tasks, debugging, workspace settings, AI agents and extensions that have not opted in. Automatic tasks never run in an untrusted workspace, and task.allowAutomaticTasks is off by default, prompting once per workspace.

Do not trust a whole parent folder such as ~/src, because trust extends to every subfolder, including the next repository you clone there. Review changes to .vscode/, .devcontainer/, .claude/, .cursor/ and agent instruction files in pull requests with the same care as build scripts, and give them owners in CODEOWNERS (see /domains/supply-chain/ci-cd/source-repository-protection/).

Most package malware runs at install time, in preinstall, install and postinstall scripts or in a Python source distribution's build step, and most is caught and removed within hours to days. Two settings block both: refuse dependency install scripts except for packages you have reviewed, and refuse versions younger than a few days.

npm 11 offers ignore-scripts, a blunt switch that skips every dependency script, and min-release-age since 11.10.0. npm 12.0.0, released on 2026-07-08, blocks dependency lifecycle scripts by default unless the root package.json approves them in allowScripts, which npm install-scripts approve maintains with version-pinned entries; it also refuses git and remote tarball dependencies by default. pnpm has not run dependency build scripts by default since version 10; list the ones you allow in allowBuilds, keep strictDepBuilds on so new ones fail the install, and set minimumReleaseAge, which pnpm 11 defaults to one day. For Python, only-binary = :all: stops pip from building source distributions, and uv's exclude-newer accepts a duration such as 7 days.

Release-age delays also delay security fixes. When you must take a fix at once, exempt that package by name where the tool supports it, such as pnpm's minimumReleaseAgeExclude, rather than turning the delay off for everything. /domains/supply-chain/dependencies/package-attack-response/ covers what to do when a malicious version did install.

# ~/.npmrc (npm 11.10 or later)
ignore-scripts=true       # no dependency lifecycle scripts; for a reviewed build: npm rebuild <pkg> --ignore-scripts=false
min-release-age=7         # only install versions published more than 7 days ago
allow-git=none            # no git dependencies (npm 11.9+; the default from npm 12)

# npm 12: dependency install scripts are blocked unless package.json allowScripts approves them
#   npm install-scripts ls              list packages whose scripts were skipped
#   npm install-scripts approve esbuild record a pinned approval after review
#   npm rebuild esbuild                 run the newly approved script
#   (drop ignore-scripts=true on npm 12: it overrides allowScripts)

# pnpm-workspace.yaml (pnpm 10.26 or later; dependency build scripts are off by default)
#   minimumReleaseAge: 10080   # minutes; pnpm 11 defaults to 1440
#   trustPolicy: no-downgrade  # fail if a package's trust level dropped from earlier releases
#   strictDepBuilds: true      # unreviewed build scripts fail the install
#   allowBuilds:
#     esbuild: true

# ~/.config/pip/pip.conf: never build an sdist, which runs the package's own build code
#   [install]
#   only-binary = :all:

# ~/.config/uv/uv.toml
#   exclude-newer = "7 days"
#   no-build = true

Every incident above ended in credential theft, and the payloads looked in the same places: ~/.npmrc, ~/.pypirc, ~/.netrc, ~/.aws/credentials, ~/.config/gh, ~/.docker/config.json, kubeconfig files, .env files and shell profiles, plus environment variables. Remove the long-lived values from those places.

• Cloud: use SSO sessions (aws sso login, gcloud auth login, az login) instead of access keys in files.
• npm: classic tokens were revoked on 2025-12-09 and npm login now issues two-hour sessions; do not paste granular tokens into ~/.npmrc, and publish from CI with trusted publishing.
• Git and GitHub: let the credential helper and gh store tokens in the OS keychain; sign and authenticate with hardware-backed SSH keys (ed25519-sk).
• Never put tokens in shell profiles or committed .env files; load them per command from a secret manager.
• Scan the usual locations regularly, and treat anything found as leaked: /domains/identity-crypto/secrets/leaked-secret-response/.

A dev container keeps a project's toolchain, install scripts and extensions off the host file system, which limits what a malicious dependency can read. It is not a credential boundary. The VS Code Dev Containers extension copies your .gitconfig, shares your Git credential helper and forwards your SSH agent when one is running, so code in the container can push to anything you can. A postCreateCommand, a postStartCommand or the image's own metadata runs as soon as the container starts, and opening a repository in a container counts as trusting it.

Keep the container unprivileged: a non-root user, dropped capabilities, no host home directory mount and never the Docker socket, which is equivalent to root on the host. Pin the base image by digest in real projects, and install dependencies without scripts.

{
  "name": "payments-api",
  "image": "mcr.microsoft.com/devcontainers/typescript-node:22",
  "remoteUser": "node",
  "runArgs": ["--cap-drop=ALL", "--security-opt=no-new-privileges"],
  "postCreateCommand": "npm ci --ignore-scripts",
  "customizations": {
    "vscode": {
      "extensions": ["dbaeumer.vscode-eslint"]
    }
  }
}

An agent with permission to run commands is an install script you talk to. Auto-approval modes let prompt injection from a file, issue or web page turn into commands, and agent configuration in the repository (hooks, MCP server definitions, permission rules) runs with your credentials. MCP servers started with npx or uvx download and run a package at launch, so pin their versions and allow them by name.

Enforce agent settings centrally rather than per user. VS Code's enterprise policies ChatToolsAutoApprove and ChatToolsTerminalEnableAutoApprove set to false stop developers from turning on global or terminal auto-approval. Claude Code's managed settings, deployed to /Library/Application Support/ClaudeCode/managed-settings.json on macOS or /etc/claude-code/managed-settings.json on Linux, override user and project files: the example disables bypass-permissions mode, runs only hooks from managed settings, which stops a repository's SessionStart hook, and allows only the MCP servers you list, matched by URL because anyone can give a server a familiar name. /domains/ai-emerging/agent-security/ai-assisted-development/ and /domains/ai-emerging/agent-security/mcp-multiagent-security/ cover agent permissions and MCP in depth.

{
  "permissions": {
    "disableBypassPermissionsMode": "disable"
  },
  "allowManagedHooksOnly": true,
  "allowManagedMcpServersOnly": true,
  "allowedMcpServers": [
    {"serverUrl": "https://api.githubcopilot.com/*"}
  ]
}

• Full-disk encryption, screen lock and automatic OS updates; endpoint detection that covers developer tools.
• An editor extension allow-list enforced by policy, with extensions reviewed before they are added.
• Workspace Trust on, no trusted parent folders, automatic tasks off.
• Package managers that block dependency install scripts and very new versions, with a lockfile installed by npm ci or its equivalent.
• No long-lived cloud, registry or Git tokens in files; SSO and keychains instead.
• Agent auto-approval disabled and MCP servers allow-listed through managed settings.
• Separate accounts or machines for publishing and production access where the risk justifies it.

When an advisory names an extension or package version, list what each machine has, confirm the package-manager policy that was in force, look for plaintext credentials the payload could have read, and search repositories for configuration that would run the payload again. If you find an affected version, isolate the machine and remove persistence before rotating credentials, because some payloads watch for rotation, then follow /domains/supply-chain/dependencies/package-attack-response/.

# 1. Editor extensions and versions (forks ship their own CLI, such as cursor or codium)
code --list-extensions --show-versions

# 2. Package-manager policy actually in force
npm config get ignore-scripts min-release-age allow-git
pnpm config get minimumReleaseAge

# 3. Plaintext credentials in the usual places (gitleaks 8.19+), values redacted
for p in ~/.npmrc ~/.pypirc ~/.netrc ~/.aws ~/.config/gh ~/.docker ~/.kube; do
  [ -e "$p" ] && gitleaks dir --no-banner --redact -v "$p"
done

# 4. Repository files that run code when a project or agent session opens
grep -rl '"SessionStart"' ~/src/*/.claude/ 2>/dev/null
grep -rl '"folderOpen"' ~/src/*/.vscode/ 2>/dev/null
grep -rl '"command"' ~/src/*/.cursor/mcp.json ~/src/*/.vscode/mcp.json 2>/dev/null

Sources & further reading

The standards, specifications and documentation behind the guidance above. Each is the evidence for a claim on this page; consult it for detail beyond the defaults and versions listed here.

1. Eclipse Foundation: Open VSX security update, October 2025. 27 October 2025.
2. Eclipse Foundation: Fewer keys under the doormat, why trusted publishing matters for Open VSX. 9 October 2026.
3. CrowdStrike: Disrupting Glassworm, inside CrowdStrike's takedown of a developer-targeting botnet. 26 May 2026.
4. AWS security bulletin AWS-2025-015: Amazon Q Developer for VS Code (CVE-2025-8217). 23 July 2025, updated 25 July 2025.
5. Nx security advisory GHSA-cxm3-wv7p-598c: malicious versions of Nx and some supporting plugins were published. 27 August 2025.
6. Nx: s1ngularity, what happened, how we responded and what we learned
7. Embrace The Red: GitHub Copilot remote code execution via prompt injection (CVE-2025-53773). 12 August 2025.
8. Sonar: Mini Shai-Hulud targets AI coding agents (2026-05-26)
9. Red Hat RHSB-2026-006: Supply chain compromise of @redhat-cloud-services npm packages. 1 June 2026.
10. VS Code docs: Manage extensions in enterprise environments
11. VS Code docs: Workspace Trust
12. VS Code docs: Manage AI settings in enterprise environments
13. npm CLI v12.0.0 release notes. 8 July 2026.
14. pnpm: build settings (allowBuilds, strictDepBuilds)
15. Claude Code docs: Deploy managed settings

Reference information

Tags

Dependency managementSupply chain attacksKubernetes and containersAI agents and toolsSecure defaults and frameworks

SDLC phase

DesignDevelopmentRelease

Role

DevelopersAppSec engineersPlatform engineers and SREs

Download this guide as Markdown

Continue exploring