Back to skill

Security audit

Agentspace — See what your dev agent is doing, from anywhere

Security checks for vulnerabilities and agentic risk

Overview

The skill is coherent for sharing a named dev folder, but needs review because it uses mutable npm execution and treats a token-bearing workspace file as commit-safe.

Install only after reviewing whether you trust the Agentspace CLI package and service for the selected folder. Prefer a pinned, reviewed ascli version, confirm the exact path before any sync or share command, use view links unless edit access is needed, and do not commit .ascli.json or any file containing claim tokens.

Vulnerability Patterns
  • Insecure DependenciesIntroduces malicious components through unsafe dependency sources
  • Insecure Skill Coding PracticesFinds exploitable flaws such as hardcoded secrets or command injection
  • Skill Instruction HijackingAlters the agent's session goals or safety constraints when the skill loads
  • Agent Memory PoisoningWrites attacker-controlled rules into memory that affect later sessions
  • Remote Payload Retrieval and ExecutionFetches external code whose behavior can change after review
Findings (2)

T08 · Insecure Dependencies

Error
Location
SKILL.md:63
Finding
Execution of an Unpinned Mutable npm Package## Vulnerability Details **File Location**: `SKILL.md:63-66`; `references/commands.md:23-27,49` **Vulnerability Type**: Supply-chain exposure through mutable third-party package execution **Risk Level**: High ### Vulnerable Code `SKILL.md:63-66`: ```markdown ## Install 1. If `ascli` is already on `PATH`, use it. 2. Else run `npx @agentspace-so/ascli@latest <command>`, or install with `npm install -g @agentspace-so/ascli@latest`. 3. If Node.js is not available, tell the user to install it from nodejs.org first. ``` `references/commands.md:23-27`: ```markdown ## Without installing globally ```bash npx @agentspace-so/ascli@latest share <path> --permission edit ``` ``` `references/commands.md:49`: ```markdown - Install via `npm install -g @agentspace-so/ascli@latest` if `ascli` is not already on `PATH`. Do not use `curl | bash`. ``` ### Technical Analysis The Skill directs the agent to download and execute the mutable `latest` release of a third-party npm package. The reviewed Skill contains neither the CLI source nor a lockfile or integrity hash that establishes which package contents will execute. Running the package through `npx` may download and immediately execute package code, including lifecycle behavior and the requested CLI entry point. A global installation also places mutable third-party software into the user's global Node.js environment. Consequently, the effective executable payload can change after this Skill has been reviewed. This is not evidence that the current npm package is malicious. It is an unsafe trust model: compromise of the npm publisher account, package distribution infrastructure, or a future release could turn an otherwise legitimate command into arbitrary local code execution. The pre-scan warning concerning `curl | bash` is a false positive. The cited line explicitly says **not** to use that installation mechanism. The actual concern is the unpinned npm p ...[truncated 1345 chars]
Remediation
## Remediation Suggestions 1. Replace `@latest` with an exact, reviewed package version. 2. Prefer a project-local dependency recorded in a lockfile over global installation. 3. Verify npm package integrity using lockfile integrity metadata or a separately published trusted checksum. 4. Require explicit user approval before downloading or executing a package that is not already installed. 5. Document the exact package version tested with the Skill and review upgrades before changing that version. 6. Run the CLI with the minimum filesystem and network access required for the selected folder. 7. Consider distributing audited CLI source with reproducible build instructions or using a verified signed release.

T09 · Insecure Skill Coding Practices

Error
Location
references/developer.md:28
Finding
Documentation Recommends Committing a Workspace Authentication Token## Vulnerability Details **File Location**: `SKILL.md:71-78`; `references/developer.md:9,28` **Vulnerability Type**: Authentication-token exposure through source control **Risk Level**: High ### Vulnerable Code `SKILL.md:71-78`: ```markdown When the CLI runs for a dev session: - It uploads **only the dev folder the user explicitly names** to `agentspace.so`. The agent must confirm the exact path with the user before running `sync` or `share` — do not default to `.` unless the user said so. - It writes a dev binding file `.ascli.json` in the bound folder. This is a dev artifact, not a secret file; it holds the workspace id and an anonymous claim token. - It optionally reads `~/.config/ascli/config.json` if the developer has a custom dev server URL set. - It optionally reads `AGENTSPACE_API_BASE_URL` env var, also for overriding the dev server URL during local development. - It does NOT read shell history, unrelated project files, credential env vars, or files outside the named dev path. All dev traffic goes to `agentspace.so` only. ``` `references/developer.md:9`: ```markdown - `POST /api/workspaces` — create a dev workspace for an agent run. Returns `workspace`, `principal`, and a `claim` block with `claimToken`, `claimUrl`, `expiresAt`. Dev workspaces default to 24-hour claim window. Authenticate subsequent dev calls with `X-Workspace-Claim-Token: <claimToken>`. ``` `references/developer.md:28`: ```markdown - `.ascli.json` can be committed for a shared dev workspace. ``` ### Technical Analysis The Skill states that `.ascli.json` contains an anonymous claim token and that this token authenticates subsequent workspace API calls. Despite that credential-bearing role, the documentation characterizes the file as “not a secret file” and explicitly says that it can be committed. A claim token is a bearer credential: possession may be sufficient to authenticate requests within the token's server-side auth ...[truncated 2112 chars]
Remediation
## Remediation Suggestions 1. Remove the recommendation to commit `.ascli.json`. 2. Correct the statement that the binding file is not secret; clearly classify its claim token as a sensitive bearer credential. 3. Add `.ascli.json` to the generated folder's `.gitignore` automatically and document the exclusion. 4. Separate non-sensitive workspace metadata from the claim token so identifiers can be shared without exposing authentication material. 5. Store the token in an operating-system credential manager, a permission-restricted user configuration file, or an approved CI secret store. 6. Restrict any credential file to the invoking user through appropriate filesystem permissions. 7. Provide token revocation and rotation procedures, and rotate any token that has already entered source-control history. 8. Apply short expiration, least-privilege scopes, and server-side auditing to claim tokens. 9. Add secret-scanning rules for `.ascli.json` and the claim-token format to prevent future commits. 10. If a token has been committed, revoke it first, then purge it from repository history and notify affected repository users to refresh their clones.
Vulnerability Patterns
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
  • Supply ChainUnpinned Dependencies, External Script Fetching, Obfuscated Code
  • Rogue AgentSelf-Modification, Session Persistence
  • Trigger AbuseOverly Broad Trigger, Shadow Command Trigger, Keyword Baiting Trigger
  • MCP Tool PoisoningHidden Instructions, Unicode Deception, Parameter Description Injection
Findings (8)

External Script Fetching

High
Category
Supply Chain
Content
- `share` on an unbound path creates a temporary workspace, syncs once, and returns a link — no separate `sync` step is needed for one-off sharing.
- Only the named path is uploaded. All traffic goes to `agentspace.so`.
- Install via `npm install -g @agentspace-so/ascli@latest` if `ascli` is not already on `PATH`. Do not use `curl | bash`.
Confidence
90% confidence
Finding
Remote code is downloaded and executed. This bypasses code review and could introduce malicious code.

Vague Triggers

Medium
Confidence
97% confidence
Finding
The skill declares broad triggers such as 'debug this agent' and especially 'any dev-time observability need,' which can cause the agent to activate in loosely related contexts. Because this skill can expose a live workspace, upload user-selected folders, and generate share links, overbroad activation raises the chance of unintended data exposure or execution of risky workflow steps without sufficiently explicit user intent.

Rp1

Medium
Category
MCP Rug Pull
Confidence
96% confidence
Finding
The skill instructs users to run `npx @agentspace-so/ascli@latest` or use an unpinned `ascli`, which fetches and executes code whose exact version is not fixed. In a security-sensitive agent context, that creates a supply-chain risk: a compromised package, malicious new release, or typo/confusion around PATH resolution could lead to arbitrary code execution on the host.

Rp1

Medium
Category
MCP Rug Pull
Confidence
90% confidence
Finding
Using `npx @agentspace-so/ascli@latest` executes the latest unpublished-at-analysis package version at runtime, which is not pinned and can change without review. If the package is compromised upstream or a breaking/malicious release is published, users may run attacker-controlled code on their machine.

Description-Behavior Mismatch

Medium
Confidence
90% confidence
Finding
The manifest describes a live dev workspace where a user can watch a folder evolve, inspect logs and artifacts over time, and hand off an active session. This file instead documents `share` as creating a temporary workspace and syncing once, with no separate sync step, which is materially narrower than the advertised continuous live-observability behavior.

Missing User Warnings

Medium
Confidence
90% confidence
Finding
The commands instruct users to share local files or folders to a remote service and note that traffic goes to `agentspace.so`, but they do not prominently warn about privacy, secrets exposure, or the risk of uploading sensitive source code, credentials, logs, or build artifacts. In a developer-tool context, shared directories often contain highly sensitive material, making omission of an explicit warning more dangerous.

Session Persistence

Medium
Category
Rogue Agent
Content
The ascli dev CLI is a thin client over the agentspace.so dev API. For custom dev tools, CI/CD build integrations, test automation, or dev dashboards, hit these endpoints directly:

- `POST /api/workspaces` — create a dev workspace for an agent run. Returns `workspace`, `principal`, and a `claim` block with `claimToken`, `claimUrl`, `expiresAt`. Dev workspaces default to 24-hour claim window. Authenticate subsequent dev calls with `X-Workspace-Claim-Token: <claimToken>`.
- `POST /api/workspaces/:workspaceId/claim` — claim an anonymous dev workspace, removing the 24-hour expiry so dev state persists.
- `GET /api/workspaces/:workspaceId/events` — server-sent event stream of dev changes. Dev observability tools subscribe here to watch agent file events live.
- `POST /api/workspaces/:workspaceId/share-links` — create a dev share link. Supports workspace-level or single-file scope, `edit` or `view` permission. Useful for dev review handoffs.
Confidence
60% confidence
Finding
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.

Intent-Code Divergence

Low
Confidence
77% confidence
Finding
The inline notes say an unbound path is synced once and that only the named path is uploaded, which conveys a limited one-off transfer model. That directly conflicts with the broader stated intent in the skill description of opening a URL to watch the dev folder evolve live over time.

Static analysis

No suspicious patterns detected.