AI Agent Config Security Is Supply Chain Security

On April 29, 2026, security teams reported compromised SAP ecosystem packages that did not stop at credential theft. The Mini Shai-Hulud campaign also wrote persistence into developer configuration: Claude Code hooks, VS Code tasks, and repository workflow files.¹²³

That detail changes the review boundary. A poisoned package no longer has to remain installed if it can leave behind a startup command in a file the developer trusts. Removing the dependency may remove the first trigger. The agent or editor config can keep the next trigger alive.

AI agent config is executable software. Treat every hook, task, MCP server definition, skill, plugin, package script, and workflow file as part of the software supply chain, because those files can decide what code runs before the human has read the diff.

TL;DR

Mini Shai-Hulud showed a practical path from dependency install to developer-tool persistence. Security researchers reported malicious npm packages that used lifecycle scripts during install, harvested developer and CI credentials, and wrote .claude/settings.json plus .vscode/tasks.json files to re-run code from trusted developer surfaces.¹²⁴ Official docs confirm the underlying surfaces have real execution authority: Claude Code hooks run lifecycle commands and command hooks execute with the user’s permissions, while VS Code folderOpen tasks can run when a folder opens after the user allows automatic tasks for that folder.⁵⁶

The lesson is not “turn off agents.” The lesson is sharper: agent configuration belongs in dependency review, code review, incident response, and release gates. Dot-directories that used to feel like local preference now sit on the execution path. A serious AI engineering practice needs config diffs, hook review, task review, least-privilege tokens, and startup-surface audits.

Key Takeaways

For developers: - Review .claude/settings.json, .vscode/tasks.json, .github/workflows/*, package.json scripts, MCP configs, and agent plugin or skill manifests before trusting a repository. - Treat new startup hooks and folder-open tasks like new executable files. - After a suspicious install, remove persistence files and rotate credentials. Package removal alone does not prove cleanup.

For security teams: - Add agent config files to supply-chain detection, CODEOWNERS, secret response, and incident scoping. - Flag any PR that adds startup execution, broad shell commands, opaque downloaded binaries, or hidden dot-directory payloads. - Prefer short-lived publishing credentials and read-only install credentials. Long-lived write tokens remain worm fuel.

For agent-platform builders: - Make execution surfaces visible, reviewable, and explainable. - Separate context-loading hooks from command-executing hooks. - Give users a first-class audit view for startup actions, external network calls, and modified configuration.

What Mini Shai-Hulud Changed

Supply-chain attacks against package managers already follow a familiar pattern. A trusted package receives a malicious version. An install script executes. The payload steals tokens. A registry takedown or version rollback arrives after some number of developers and CI jobs have already installed the bad version.

Mini Shai-Hulud added a more agent-specific step. Reports from Endor Labs, Wiz, Socket, StepSecurity, and Cloud Security Alliance all describe the same broad shape: compromised packages in the SAP developer ecosystem used npm install-time execution, collected GitHub, npm, cloud, and CI credentials, and created persistence through developer-tool configuration.¹²³⁴⁷

Wiz documented a fallback path that placed files in repositories so future openings in Claude Code or VS Code could re-trigger execution.² Endor Labs described a Claude Code SessionStart hook and a VS Code task with runOn: "folderOpen".¹ Socket’s campaign tracker lists persistence through .claude/settings.json and .vscode/tasks.json alongside npm and PyPI package compromises.³

The exact payload belongs in incident reports, not in a general engineering article. The durable lesson belongs here:

The target shifted from one package version to the developer environment around the package.

Config Files Became Startup Programs

Claude Code’s hooks reference says hooks are user-defined shell commands, HTTP endpoints, or LLM prompts that execute automatically at lifecycle events.⁵ The same documentation says SessionStart runs when Claude Code starts or resumes a session, and the security section warns that command hooks run with the user’s full permissions.⁵

VS Code’s task documentation gives another execution surface. A task can set runOn to folderOpen, and VS Code will run that task when the containing folder opens after the user allows automatic tasks for that folder.⁶ That consent prompt matters. It lowers the risk compared with silent execution on every machine. It does not make the file harmless. A trusted repository, a tired developer, a previously allowed workspace, or an organization policy can still turn a config change into code execution.

npm adds the install-time bridge. The npm scripts documentation lists preinstall, install, and postinstall among lifecycle scripts for npm ci and npm install, and npm’s best-practices section says authors should almost never explicitly set preinstall or install scripts except for target-architecture compilation.⁸

Those three facts create the attack chain:

1. An install script runs during dependency installation.
2. The script writes or patches developer-tool configuration.
3. The editor or agent later runs the configured startup action.
4. The developer trusts the tool surface because the prompt or UI looks like normal work.

The dangerous part is not any single feature. Install scripts, hooks, tasks, and workflows all support legitimate automation. The dangerous part is trust transitivity. A package install should not silently get to define what every future agent session or folder open will execute.

The Review Boundary Is Wrong

Most code review habits treat source files as the main artifact and config files as support material. That habit fails when config files execute commands.

A new hook should receive the same review as a new shell script. A new task should receive the same review as a new binary. A new MCP server should receive the same review as a new network integration. A new package lifecycle script should receive the same review as new code that runs before tests.

Use a review table:

Runtime Defense for Tool-Augmented Agents argued that enforcement belongs at the tool-call boundary. Mini Shai-Hulud pushes the same standard one layer earlier. The startup boundary needs enforcement too.

Startup Authority Needs Least Privilege

Teams already apply least privilege to API keys. Agent config needs the same rule.

Claude Code separates hook events such as PreToolUse, PostToolUse, and SessionStart.⁵ That separation should shape policy. A hook that loads static context should not need shell access. A hook that validates a command should not need network access. A hook that records local metadata should not need credentials.

The same rule applies to VS Code tasks and CI workflows:

The npm trusted publishing docs explain why short-lived credentials matter. Trusted publishing uses OIDC so package publishing can happen without long-lived npm tokens, and npm recommends disallowing traditional token-based publishing after trusted publishers are configured.⁹ npm also recommends read-only granular access tokens for installing private dependencies when publishing uses OIDC.⁹

That advice does not eliminate workflow risk. A compromised workflow can still do damage if it has too much authority. The lesson is to shrink both sides: short-lived credentials and narrow workflows.

Treat Agent Config As A Dependency

Dependency review usually asks which package versions changed. Agent-era review should ask which execution surfaces changed.

Before accepting a dependency update, plugin install, generated config, or template change, check:

The point is not paranoia. The point is category accuracy. A hook file may look like configuration, but it behaves like code. A task file may look like editor setup, but it can launch a shell. A workflow may look like release plumbing, but it can reach credentials.

AI Agent Safety Starts With Small Software made a related argument from the design side: narrower tools have fewer places to hide mistakes. The security version says narrower config has fewer places to hide persistence.

A Safe Config Sweep

A defensive review does not need to execute suspicious code. Start with read-only inspection:

git diff -- .claude/settings.json .vscode/tasks.json package.json .github/workflows
rg -n '"SessionStart"|"runOn"\\s*:\\s*"folderOpen"|preinstall|postinstall|curl|wget|bun|node .*setup' \
  .claude .vscode package.json .github/workflows
find . -path '*/.claude/*' -o -path '*/.vscode/tasks.json' -o -path '*/.github/workflows/*'

Those commands do not prove a machine is clean. They give the reviewer a first pass over the surfaces most likely to turn configuration into execution. If a suspicious install already happened, move to incident response instead of treating a clean search result as assurance.

Recovery Requires A Config Sweep

Incident response for a compromised dependency should not stop at uninstalling the package.

Use a recovery sequence:

1. Identify whether the affected package version installed on a developer machine or CI runner.
2. Freeze that environment before it performs more work.
3. Audit startup config files in the repository and home-directory agent or editor config.
4. Remove suspicious hooks, tasks, workflows, generated payload files, and unexpected branches.
5. Rotate every credential accessible to the affected process, including package tokens, GitHub tokens, cloud keys, SSH keys, and CI secrets.
6. Inspect package publisher access and repository write access.
7. Review workflow logs for secret exposure and unexpected outbound calls.
8. Rebuild the environment from a clean checkout and known-good dependency set.

GitHub’s Actions security guidance supports the credential side of that response: use least privilege for workflow tokens, rotate exposed secrets, audit how secrets are handled, and consider requiring review before jobs can access environment secrets.¹⁰ GitHub also recommends CODEOWNERS for workflow files so changes under .github/workflows require approval from designated reviewers.¹⁰

Add agent config to that same governance path. If .github/workflows/* deserves code-owner review because it can touch secrets, .claude/settings.json and .vscode/tasks.json deserve review because they can run commands near secrets.

What Agent Platforms Should Build

Agent platforms and editors can reduce the review burden by making startup authority explicit.

Useful product surfaces:

Those surfaces should not depend on the model reading a JSON file and making a judgment. The runtime should expose the authority directly. The user should see a clear difference between “loads context from README” and “runs a shell command on session start.”

MCP Tools Need Action-Level Authorization argued that bearer-token validation must lead to per-tool, per-role, and per-action checks. Agent config needs the same shape: every startup action should declare the authority it needs, and the runtime should enforce the smallest viable set.

A Practical Local Policy

Teams can start with a small policy file even before platforms make the interface better:

Good policy names the file and the authority. Vague rules such as “be careful with agent tools” do not survive real work. Clear rules such as “no SessionStart command hook without owner review” give reviewers something they can enforce.

FAQ

Is AI agent config really part of the supply chain?

Yes. Supply-chain risk follows execution and trust, not file extension. If a package install, plugin, template, or repository change can modify agent config that later executes commands, that config sits inside the supply chain.

Should teams ban Claude Code hooks or VS Code tasks?

No. Hooks and tasks support legitimate automation. Teams should review, scope, and log them. A context-loading hook and a shell-executing startup hook should not receive the same trust.

Does VS Code ask before running folder-open tasks?

VS Code’s documentation says the first time a user opens a folder containing a folderOpen task, VS Code asks whether to allow automatic tasks for that folder.⁶ That prompt helps, but the task still deserves code review because approval turns the file into an execution path.

Does npm trusted publishing solve package compromise?

No. Trusted publishing reduces the risk of long-lived npm write tokens by using short-lived OIDC-based credentials.⁹ Teams still need workflow review, least privilege, package monitoring, and incident response for compromised repositories or malicious install scripts.

What should I audit first after a suspicious install?

Audit install-time scripts, agent and editor startup config, workflow files, unexpected dot-directory files, new branches, and credentials exposed to the affected process. Then rotate credentials from the affected environment.

Close

AI coding agents make configuration more powerful. They also make configuration more dangerous.

The right response is not fear of automation. The right response is honesty about where execution lives. If a file can run a command, fetch data, read secrets, publish packages, or change agent behavior, the file belongs in the review path.

Agent config has crossed that line. Treat it like code.

References