Is darkstards9/rpe-grafana safe?
https://github.com/openclaw/skills/tree/main/skills/darkstards9/rpe-grafana
rpe-grafana is a well-constructed, read-only Grafana integration with no malicious code, no prompt injection, no install-time execution hooks, and no exfiltration vectors. The skill's index.js exclusively uses fetch() to call the user-configured Grafana API, and all observed canary file accesses are attributable to the audit framework's own canary management rather than the skill. The primary concerns are operational: Grafana credentials are stored in plaintext config per framework convention, and the skill grants the agent read access to potentially sensitive infrastructure metrics depending on what the user's Grafana instance exposes.
Category Scores
Findings (4)
LOW Grafana credentials stored in plaintext config -8 ▶
The skill requires GRAFANA_URL, GRAFANA_USER, and GRAFANA_PASSWORD to be stored in openclaw.json or environment variables. While this is the framework's standard credential pattern, plaintext credential storage means any skill or process that can read the config file gains access to the Grafana instance.
LOW Read access to potentially sensitive operational metrics -7 ▶
When active, this skill can enumerate all Grafana dashboards and read metric data from any panel accessible to the configured user. Grafana deployments frequently contain sensitive infrastructure, security, and business metrics. Users should configure a minimal-permission Grafana Viewer account.
INFO No input validation on time range parameters -3 ▶
The from and to parameters accepted by grafana_query_panel are passed directly to Grafana's /api/ds/query endpoint without sanitization. Since the target is a user-controlled Grafana instance, the practical risk is limited to whatever Grafana itself validates.
INFO Canary file reads attributable to audit framework, not skill 0 ▶
Filesystem monitoring detected reads of .env, .ssh/id_rsa, .aws/credentials, .npmrc, .docker/config.json, and .config/gcloud/application_default_credentials.json. Timing analysis confirms the first batch (1771907749) occurred before the git clone began (1771907754), consistent with canary file placement. The second batch (1771907766) occurred during the audit framework's post-install integrity sweep. The skill's index.js contains no filesystem read primitives.