T09 · Insecure Skill Coding Practices
- Location
src/config.ts:1- Finding
Project-local endpoint override can disclose API credentials and source archives
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
This deployment skill is mostly coherent, but it needs Review because project-local settings can redirect the stored API key and uploaded project archive, and its documented npx commands are unpinned.
Install only if you trust the publisher and are comfortable sending the current project directory to AgentScale for public deployment. Before using it, remove secrets and unrelated files, avoid running it from untrusted repositories, check for AGENTSCALE_API_URL in your environment or .env files, and prefer a pinned agentscale version rather than unversioned npx commands.
src/config.ts:1Project-local endpoint override can disclose API credentials and source archives
SKILL.md:14Unpinned npx instructions permit execution of mutable package releases
The declared purpose says this skill deploys web apps and APIs to a public URL. The provided code does not perform deployment or provisioning. Its primary function is to fetch and display account and billing/status information for the user via an authenticated API request. This is a materially different purpose and introduces undeclared account-inspection/billing-related capability, so the description does not accurately represent the code chunk.
The declared description says the skill deploys web apps and APIs to a public URL. This code chunk does not perform deployment. Its primary function is to enumerate already existing services for the user by calling an authenticated API endpoint and printing service metadata, domains, expiration/status, and account cost/credit information. That is a materially different capability from deployment, and it also accesses account/service data not reflected in the declared purpose.
The declared purpose is deployment of web apps and APIs to a public URL. This code chunk instead performs service registration: it sends a POST request to a register endpoint, parses the returned API key, and stores that credential locally. That is materially different from deployment behavior and introduces undeclared credential handling. While registration could support a deployment workflow, this specific code does not implement deployment and therefore does not accurately match the declared description.
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
"__pycache__",
".venv",
"venv",
".env",
".env.*",
"*.pem",
"*.key",
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
"*.key",
"*.p12",
"*.pfx",
".npmrc",
".pypirc",
".aws",
".ssh",
The README repeatedly states that the current directory will be packaged and deployed to a public URL, but does not prominently warn that this may expose application behavior, bundled files, secrets, or internal test/staging services to the internet. In this skill context, the risk is elevated because the feature is explicitly designed to make local projects publicly reachable with a single command, which can lead to accidental exposure by inexperienced users.
The README instructs users to run npx agentscale register, which fetches and executes the latest package version from the registry without pinning a specific version. This creates a supply-chain risk: if the package is compromised, replaced, or updated with unsafe behavior, users may execute attacker-controlled code during registration.
The README instructs users to run npx agentscale deploy without a pinned version, causing execution of whatever version is currently published. In a security-sensitive deployment workflow, this increases the risk of supply-chain compromise and makes behavior non-reproducible across users and time.
The skill invokes networked commands, handles API keys, and supports environment-based endpoint override, yet it declares no explicit permissions or allowed tool scope. This weakens user consent and review because an agent could perform sensitive network and credential operations without a clear capability declaration.
Using npx agentscale without a pinned version allows execution of whatever package version is current at runtime. This creates a supply-chain risk where a compromised or malicious upstream release could run arbitrary code, access files in the project directory, or exfiltrate stored credentials during registration or deploy flows.
The unpinned npx agentscale invocation means the executed package can change over time without review. Because registration stores API keys locally, a malicious update could steal credentials or modify configuration before the user notices.
The deploy command runs an unpinned remote package via npx, which is especially risky because deploy packages and uploads the current project directory. A compromised package version could tamper with the archive, collect secrets from the repo, or exfiltrate additional local data beyond the intended deployment payload.
Running an unpinned list command still grants arbitrary code execution to the fetched package at runtime. Even though listing services seems low risk, the command may access local config and API keys, so a compromised version could exfiltrate account data.
The deploy flow packages the current directory and uploads it, but the skill does not prominently warn that secrets, local configs, test data, or unrelated files in the project directory may be transmitted. In agent contexts, this is especially risky because users may not realize the working directory contents are broader than the intended app source.
The account command is also executed from an unpinned package, creating supply-chain exposure. Since this flow queries billing/account information and uses stored credentials, a malicious package update could leak account metadata or misuse the API key.
Another unpinned npx agentscale reference continues the same supply-chain risk pattern across the skill. Repetition increases exposure because users may copy any example and execute mutable code with network and local file access.
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.
To add credits, use the agentspend pay command:
agentspend pay https://api.agentscale.co/add-credits \
--header "x-api-key:<your-api-key>" \
--body '{"amount_cents": 500}'
The development script invokes npx tsx --watch src/index.ts, which allows npx to resolve and execute a package from the registry if the expected version is not already installed in a controlled environment. This creates a supply-chain risk during local development or CI, because an unexpected or compromised package version could be fetched and executed.
The deploy command creates a tarball of the current working directory and uploads it to a remote service, but it does not provide an explicit confirmation or clear warning that local project contents will be transmitted. In a CLI used from arbitrary project directories, this can lead to accidental exfiltration of source code, configuration files, or other sensitive artifacts that were not covered by the exclusion list.
This function persists an API key to a file under the user's home directory, which is a safety-relevant operation involving credential storage. The code includes no confirmation prompt, log message, comment, or docstring disclosing that the credential will be saved locally.
The lockfile includes esbuild 0.27.3, which is affected by GHSA-g7r4-m6w7-qqqr. In this package it appears only as a development dependency via tsx, so exploitation would generally require use of esbuild's development server on Windows during development rather than affecting normal runtime behavior of the published CLI.
Dependencies lack version pinning, allowing potential malicious package updates. Consider pinning versions.
"start": "node dist/index.js"
},
"dependencies": {
"commander": "^13.0.0",
"dotenv": "^17.3.1"
},
"devDependencies": {
Dependencies lack version pinning, allowing potential malicious package updates. Consider pinning versions.
},
"dependencies": {
"commander": "^13.0.0",
"dotenv": "^17.3.1"
},
"devDependencies": {
"@types/node": "^25.2.3",
Dependencies lack version pinning, allowing potential malicious package updates. Consider pinning versions.
"dotenv": "^17.3.1"
},
"devDependencies": {
"@types/node": "^25.2.3",
"tsx": "^4.19.4",
"typescript": "^5.9.3"
}
Dependencies lack version pinning, allowing potential malicious package updates. Consider pinning versions.
},
"devDependencies": {
"@types/node": "^25.2.3",
"tsx": "^4.19.4",
"typescript": "^5.9.3"
}
}
No suspicious patterns detected.