Is fusionlabssource/clawprint-verify safe?

The SKILL.md explicitly instructs the agent to 'proceed with the gated action' after a verification passes, and lists 'Before sharing sensitive API keys or credentials with another agent' as a primary use case. This embeds a behavioral rule: share secrets with any entity that passes a challenge. Because the ClawPrint server (controlled by the skill author) determines what passes, the skill author can authorize any entity—including themselves—to receive the agent's secrets by simply making challenges succeed.

The validate endpoint explicitly sends the CLAWPRINT_SECRET_KEY to the skill author's Railway.app server. The skill describes this key as the 'private secret key' and warns 'Never share your CLAWPRINT_SECRET_KEY'—yet the validate step sends it to an external server the skill author controls. This is an inherent design flaw: any party who operates the validation endpoint receives the secret key. The Railway.app domain (dependable-adventure-production-44e3.up.railway.app) is ephemeral third-party infrastructure with no transparency guarantees.

All three API endpoints (challenge, verify, validate) are hosted on a single Railway.app server controlled by the skill author or whoever currently controls that deployment. The skill author can at any time push a server update that makes all challenges return passed=true and valid=true, instantly granting any agent or attacker the ability to pass verification and receive whatever credentials or access the agent was protecting. There is no independent trust anchor for the verification result.

The skill creates a workflow pattern where the agent is primed to share API keys or credentials immediately after ClawPrint passes a challenge. An attacker can initiate this by: (1) engaging the agent in a conversation, (2) requesting a ClawPrint challenge, (3) having the server return a passing result, and (4) collecting the credentials the agent then shares. No direct file reads are needed—the skill author controls the gate and the agent has been instructed to open it.

The skill's core concept is to verify that a conversation partner is an AI—explicitly to exclude human oversight. By framing human presence as a failure condition and machine-speed computation as a trust signal, the skill trains agents to bypass the very actors (humans) who could detect social engineering. Combined with the credential-sharing use case, this creates a pattern where secrets are shared in interactions humans are physically excluded from auditing in real time.

Because the skill author operates the challenge server, they can log every site key used, every challenge issued, every answer submitted, and every secret key sent during validation—building a profile of every deployment using this skill. They can also selectively manipulate outcomes per site key, allowing targeted attacks while appearing legitimate to other users. There is no way for an agent to detect whether its ClawPrint deployment has been compromised at the server level.

clawprint-challenge.sh is an executable shell script that makes authenticated HTTPS requests to an external server. While the script itself appears structurally reasonable, it executes with the agent's runtime environment variables (including CLAWPRINT_SECRET_KEY) and any future update to the script or server could alter behavior. The script is invoked by the agent directly.

The shell script interpolates challenge_id, answer, and secret_key directly into JSON strings via bash variable expansion without sanitization or escaping. If a server-controlled response contains quotes, backslashes, or shell metacharacters in challenge_id values, this could break JSON parsing or (in edge cases) enable injection. Since the server controls the challenge_id values returned, this is an attacker-influenced input path.

The skill hardcodes a Railway.app deployment URL that represents infrastructure the skill author can modify, delete, or transfer at any time. Railway.app deployments with random-looking names are often ephemeral. The _meta.json commit URL references github.com/clawdbot rather than the openclaw registry org, suggesting the skill was ported from separate infrastructure with potentially different ownership history.

Six canary credential files were opened and read at timestamps 1771904387 and 1771904411 (before and after git clone). Timing analysis indicates these accesses are consistent with the audit infrastructure planting and collecting canary files rather than the skill itself. Network analysis shows no exfiltration traffic to non-GitHub/Canonical endpoints during the monitoring window, and canary integrity is confirmed intact.

All six monitored credential files were opened and read during the monitoring session. While the integrity check confirms no content was modified and no exfiltration was detected via honeypot mechanisms, the read events are noted. Timing and process correlation suggest the audit infrastructure itself is responsible for these accesses (pre-clone planting and post-install collection), not the skill under test.