T08 · Insecure Dependencies
- Location
assets/mcp-server-ts/server.ts.tmpl:8- Finding
Unpinned Runtime Dependencies and On-Demand Package Execution
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
This is a coherent business-agent builder, but it should be reviewed before installation because it can generate live write-capable tools that use business credentials and scheduled workflows.
Install only if you are comfortable reviewing and hardening the generated workspace before live use. Pin dependencies, avoid runtime package downloads, require HTTPS for non-local business APIs, use least-privilege short-lived tokens, keep generated memory/docs out of public repositories, and enable scheduled heartbeat or write-capable tools only after explicit approval and testing in a non-production environment.
assets/mcp-server-ts/server.ts.tmpl:8Unpinned Runtime Dependencies and On-Demand Package Execution
assets/mcp-server-ts/server.ts.tmpl:16Bearer Credentials Can Be Sent over Unencrypted HTTP
Referenced artifact was not completely inspected
- TypeScript: `assets/mcp-server-ts/server.ts.tmpl` (use when the business system itself is Node/TS)
Hidden instructions were detected in comments or invisible text. These could contain malicious directives. Manual review is recommended.
# USER.md — Audience Profile
<!-- Imperative, dated entries; updated at runtime by the employee per convention; ~4,000-char budget -->
## Primary Audience
The skill instructs the agent to read business code, generate runnable scripts and an MCP server, access environment variables, and potentially call networked business APIs, but it declares no explicit tool scope or allowed-tools boundary. In a high-privilege build context, that omission can let the skill invoke broader filesystem, env, or network capabilities than necessary, increasing the blast radius for prompt injection, accidental data exposure, or unintended code execution against production systems.
The manifest uses broad trigger phrases such as turning a business system into an agent or building a digital employee, which are likely to match many generic requests. Over-broad activation can cause this powerful skill to engage unexpectedly in contexts where the user did not intend code wrapping, MCP generation, or runtime setup, raising the risk of overreach and unsafe side effects.
Although the body contains approval gates and some cautions, the skill lacks an upfront, prominent warning that it can generate and run write-capable scripts and MCP tools against real business systems. Users may enter the workflow assuming a documentation-only transformation, when the skill is designed to build live operational tooling that can perform writes, money movement, deletions, or other sensitive actions.
The skill explicitly persists analyzed business capabilities, proposed interfaces, and employee plans into workspace files across steps. That persistence can retain sensitive architectural details, internal endpoints, operational workflows, and business logic beyond the immediate session, increasing exposure if the workspace is shared, committed, or later accessed by other tools or agents.
- Present every interface-gap proposal with its draft contract (shape, parameters, returns, error codes, idempotency) — the user confirms both the content and that the business team can take it on.
- Attach explicit inclusion recommendations: what you propose to include, what you propose to exclude and why (e.g., "destructive ops should be excluded or dry-run-only").
- The user may add, remove, or adjust entries; re-present the updated inventory after each revision round.
- Only on explicit approval, write the inventory as a table in `docs/business-capabilities.md` and the proposals (when any) in `docs/business-api-proposals.md` — then proceed to step 2.
## Step 2: Role Modeling
Output size or generation rate is not bounded. Unbounded output enables denial-of-service through resource exhaustion, log flooding, or context-window stuffing.
**OpenClaw (default)**:
1. Place the workspace at `~/.openclaw/workspace-<employee-name>/` (or register as a standalone agent: `openclaw agents add <employee-name>` pointing at the workspace)
2. Add the MCP server config to openclaw.json
3. Run `openclaw agent prompt` to preview the assembled system prompt; confirm AGENTS/SOUL inject cleanly with no truncation
4. Smoke-test dialogue: ask its identity (verifies SOUL), issue a read-only business request (verifies MCP), trigger a write op (verifies approval gates)
**Verification checklist** (check every item before delivery):
The template instructs users to run the server with npx tsx without pinning a specific package version, which can fetch and execute whatever version resolves at runtime. In a generated agent workspace intended for broad reuse, this creates a supply-chain risk: builds may become non-reproducible and a compromised or malicious upstream release could be executed during setup.
The template leaves Trigger scenarios entirely open-ended, with no instruction to keep activation phrases specific, scoped, or paired with exclusions. In an agent skill system, overly broad triggers can cause accidental invocation on unrelated user requests, which may route users into deterministic scripts or sensitive business workflows without sufficient intent confirmation.
The template explicitly states the default workflow should be self-contained and avoid network dependencies unless the user explicitly confirms use of a business API or SDK, but the shipped example implementation immediately performs external API calls in run(). In a skill that generates runnable agent workflows, this mismatch can cause operators to deploy code that unexpectedly transmits business identifiers and actions to a live service, violating the documented trust and isolation model.
The document instructs users to simulate a heartbeat by running claude -p "<HEARTBEAT content>" from cron, which creates unattended prompt execution on a schedule without any safety warning, approval gate, or constraints on what the heartbeat may do. In the context of a digital-employee builder, HEARTBEAT content could trigger tool use, external API actions, or state-changing workflows, so automating it increases the risk of unintended or repeated actions.
The fallback guidance tells users to export tool schemas from an MCP server and register them manually, but it does not warn that these tools may connect to external systems or perform privileged operations when invoked. In this skill's context, the generated employee is explicitly meant to wrap business capabilities, so manually exposing tools without trust, permission, and effect warnings can lead to accidental data access or system-changing actions.
Skill attempts to fill the context window with filler content, displacing legitimate instructions and safety constraints. This can degrade agent performance or bypass safety boundaries.
2. Description is the contract: state what it does, parameter meanings/formats, what it returns, and side effects. Prefix write tools with `[WRITE — confirm with the user before executing]`.
3. Strongly typed parameters with per-field descriptions; list valid values for enums in the description.
4. Thin wrapper: validate params → call the existing business interface (HTTP client / SDK / imported module) → return structured results. Never copy business logic — dual implementations drift. (Composite flow tools are the deliberate exception — see below.)
5. Error handling: convert business exceptions to text with error codes (e.g., `ORDER_NOT_FOUND: order xxx does not exist`); never let raw tracebacks flood the context.
6. Credentials: inject via env vars (`BUSINESS_API_BASE`, `BUSINESS_API_TOKEN`, etc.); TOOLS.md records variable names only.
7. Response size: list tools take a `limit` parameter (default 20) so a single call can't blow up the context window.
Skill establishes unauthorized persistence across sessions via cron jobs, startup scripts, or state files. Session persistence allows an attacker to maintain access beyond the current interaction.
1. **File-role discipline**: rules → AGENTS.md; tone → SOUL.md; user facts → USER.md; environment paths → TOOLS.md; learnings → MEMORY.md. Every piece of content lives in exactly one place.
2. Required AGENTS.md sections for a digital employee: `## Every Session` (startup reading list), `## Scope` (business scope and forbidden zone), `## Approval Required` (operations needing human confirmation), `## Escalation` (what to do when uncertain or failing).
3. Required SOUL.md sections: `## Identity` (who you are / mandate), `## Tone`, `## Expertise`, `## Boundaries`.
4. **Never write secrets, tokens, or passwords** into any file — reference environment variable names only; values are injected at runtime.
5. Recommended: initialize the workspace as a git repo for versioning and backup.
## Multi-Agent & Onboarding Commands
The header says to never reference business source via file paths, yet the template includes a Ported from: example containing a concrete source path and line range. This is a direct documentation-level contradiction about whether source file path references are permitted.
The instruction 'Communicate in {{language}}' imposes a language setting as a fixed requirement. Under the policy, forcing a specific language or locale without offering user choice or documenting justification is a natural-language policy concern.
No suspicious patterns detected.