digital staff
Security checks across malware telemetry and agentic risk
Overview
This looks like a real OpenClaw dashboard, but it needs review because it can run as a network-reachable web service that reads sessions, copies API-key-backed model configs, and changes agents and skills.
Install only if you intentionally want a web dashboard with authority to manage OpenClaw agents and skills. Before running it, inspect the server configuration, bind it to localhost or protect it with authentication, back up your OpenClaw configuration, and understand that it may read session history and duplicate model/API-key configuration into agent files.
VirusTotal
VirusTotal findings are pending for this skill version.
Risk analysis
Artifact-based informational review of SKILL.md, metadata, install specs, static scan signals, and capability signals. ClawScan does not execute the skill or run runtime probes.
Someone who can reach the machine over the network may be able to access dashboard controls if authentication or firewall rules are not configured correctly.
The dashboard has been run bound to all network interfaces. Because the skill also documents management APIs that can create/delete agents and enable/disable skills, broad network exposure is a material control-boundary risk unless separate authentication and firewalling are in place.
* Running on all addresses (0.0.0.0) ... * Running on http://198.18.0.1:5181
Bind the server to 127.0.0.1 by default, require authentication and CSRF protection, and put mutating actions behind explicit user confirmation.
Agent behavior, available skills, and agent existence could be changed across the user's OpenClaw environment.
These endpoints can alter persistent agent definitions and skill permissions. A mistaken or unauthorized call can affect future OpenClaw sessions and agent behavior, not just the dashboard view.
POST /api/agents # Create new agent ... DELETE /api/agents/<name> # Delete agent ... POST /api/agents/<name>/skills/<id>/enable ... POST /api/agents/<name>/skills/<id>/disable
Back up OpenClaw configuration before use, add confirmation and audit logging for destructive or permission-changing actions, and document how to undo each mutation.
Provider API keys may be duplicated into additional agent directories, increasing the number of places secrets can be read, backed up, or accidentally shared.
The README indicates per-agent model configuration files may contain API keys, and elsewhere describes copying model provider configuration from the global OpenClaw config when creating agents. This is sensitive credential handling that is not declared in the registry credential metadata.
└── models.json # 模型配置（API密钥、模型列表）
Avoid copying raw API keys when possible, use references to a protected credential store, document exactly which secrets are read or written, and set restrictive file permissions.
Private agent session history could be visible through the dashboard API, especially risky if the server is reachable beyond localhost.
The dashboard exposes stored agent sessions through an API. Those sessions can contain private conversation history, instructions, and operational context.
GET /api/agents/<name>/sessions - 获取指定 Agent 的会话
Require authentication, bind locally by default, redact sensitive session content where possible, and let users choose which sessions are exposed.
Installation may pull whatever package versions are current at install time.
The installer fetches unpinned Python packages. This is common for a Flask dashboard and user-directed, but it reduces reproducibility and increases dependency supply-chain exposure.
$PYTHON_CMD -m pip install --user flask flask-cors 2>/dev/null || true
Install in a virtual environment and prefer pinned dependency versions or a reviewed lockfile.
If enabled, the dashboard can keep running in the background and remain reachable until stopped or disabled.
The installer can create a persistent user-level service, but it asks the user first and documents the service commands.
Create systemd service for auto-start? (y/N): ... Restart=on-failure ... systemctl --user enable ${SERVICE_NAME}.serviceOnly enable the service if you need background operation, and disable it with systemctl when not in use.