T08 · Insecure Dependencies
- Location
SKILL.md:269- Finding
Unpinned npm Package Installation and Execution
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
The skill is a coherent consensus-tools setup assistant, but it asks agents to install and run unpinned npm/MCP packages and can persist an MCP registration, which deserves user review before use.
Install only after reviewing the exact commands and files the agent will change. Prefer pinned @consensus-tools versions, a committed lockfile, local binaries instead of npx-latest execution, and explicit approval before registering the MCP server in Claude or enabling LangSmith/provider API integrations.
SKILL.md:269Unpinned npm Package Installation and Execution
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
2. Read project root files to understand the user's stack:
- `package.json` (or `pyproject.toml`, `Cargo.toml`, `go.mod` — detect the ecosystem)
- `tsconfig.json` (if TypeScript)
- `**/*.env*` (check for existing config patterns, but do NOT read .env contents)
- `.consensus/**` (check if consensus-tools is already configured)
3. If no project files found (bare directory or non-project context), skip to Phase 1
The skill tells the agent to install packages, write .consensus/config.json, create source files, and run verification commands, but it does not require an explicit warning that these actions will modify the user's project. In an agentic environment, this reduces informed consent and can lead to unintended code, config, or dependency changes in sensitive repositories.
The skill directs the agent to install and register an MCP server via npx @consensus-tools/mcp without pinning a specific package version. That makes execution non-deterministic and exposes users to supply-chain risk if a newer or compromised package version is published, especially because the command is intended to be run automatically as part of setup.
npx commands without a version suffix (e.g. @1.0.0) create a rug-pull risk if the upstream server is compromised and publishes a malicious update.
The skill instructs running npx tsx src/consensus.ts without pinning the tsx version. If tsx is absent locally, npx may fetch and execute the latest published version, creating a supply-chain execution path during a workflow that the agent is expected to perform automatically.
Using npx @consensus-tools/mcp without a pinned version causes execution of whatever package version is current at runtime, undermining reproducibility and opening a supply-chain attack path if a malicious or compromised release is published. In this skill's context, the command is specifically for an MCP server that an AI agent may launch automatically, so unpinned execution is more dangerous because it can grant code execution in a trusted local environment.
This example again invokes npx @consensus-tools/mcp without version pinning, allowing silent drift to newer or compromised releases and making audits non-deterministic. Because this documentation is for Claude/Desktop MCP integration, users may copy it directly into persistent agent config, turning a documentation issue into recurring remote package execution.
npx @consensus-tools/cli without a pinned version has the same supply-chain and reproducibility risks as the MCP examples, though the blast radius is somewhat lower because it is a CLI example rather than an always-on MCP server. A compromised latest release could still execute arbitrary code on the user's machine when they follow the documentation.
This unpinned npx @consensus-tools/cli invocation creates the same risk of executing an unintended or malicious package version. In a skill meant to scaffold and automate integration steps, copy-pasteable commands are especially sensitive because users and agents may execute them without manual scrutiny.
Another unpinned npx @consensus-tools/cli command presents a supply-chain execution risk and weakens deterministic setup claims made elsewhere in the document. The surrounding skill context emphasizes auditability and deterministic behavior, which makes unpinned runtime package resolution particularly inconsistent with the claimed security model.
The surrounding documentation says createPolicyTemplate extends one of the 9 base consensus algorithms, and the config comment explicitly says base must be one of those algorithms. However, the example sets base: "SUPERMAJORITY", which is not listed anywhere in the declared ConsensusPolicyType set. This is an active contradiction between the inline documentation and the documented API contract.
The createWrapperTemplate example comments state result.action: "allow" | "block" | "escalate", but the later API reference for DecisionResult includes "retry" as a valid action. Because this file documents the same API in both places, the narrower comment contradicts the broader documented behavior rather than merely omitting an implementation detail.