Skill flagged — suspicious patterns detected

ClawHub Security flagged this skill as suspicious. Review the scan results before using.

toq protocol

v0.1.0-alpha.1

Send and receive secure messages to other AI agents using the toq protocol. Use when the user wants to set up agent-to-agent communication, send or receive t...

0· 136·0 current·0 all-time
byAnshul Desai@anshuldesai
MIT-0
Download zip
LicenseMIT-0 · Free to use, modify, and redistribute. No attribution required.
Security Scan
VirusTotalVirusTotal
Suspicious
View report →
OpenClawOpenClaw
Suspicious
medium confidence
Purpose & Capability
Name and description (agent-to-agent secure messaging) align with the content: the SKILL.md documents installing a 'toq' daemon, opening port 9009, configuring DNS discovery, and registering handlers. Installing a binary and managing network/daemon settings is coherent with the stated purpose.
!
Instruction Scope
The instructions include high-impact runtime steps: (1) curl https://toq.dev/install.sh | sh (runs remote script), (2) using an external service (ifconfig.me) to detect your public IP (leaks an indicator about your host to that service), (3) guidance to create handlers that run arbitrary shell/python/node binaries which will be executed by the daemon when messages arrive. While handler execution is an expected feature of such a system, the SKILL.md gives examples that could easily let untrusted remote messages trigger code execution or exfiltrate files if connection/handler rules are misconfigured. The skill documents these risks but still directs the user to patterns that require careful sandboxing and approval controls.
!
Install Mechanism
There is no registry install spec; the runtime instructions recommend piping a shell script from https://toq.dev/install.sh into sh — a high-risk install pattern because it executes remote code without verification. Homebrew is listed as an alternative (lower risk) but the primary curl | sh option is present and notable. The domain toq.dev is not validated in the metadata, and the installer may write binaries and daemon units to the system.
Credentials
The skill itself does not request environment variables or credentials, which is proportionate. However, handlers are explicitly allowed to call external model APIs (OpenAI, Ollama, etc.) and the recommended LLM handler pattern invokes 'openclaw agent --local' — meaning handlers may access whatever credentials or provider config your agent has. Handlers and daemon logs also read/write files in your home directory; these are powerful capabilities that are reasonable for a messaging daemon but require user-managed privilege restrictions.
Persistence & Privilege
The skill suggests creating systemd/launchd service units to auto-start the daemon on boot. That's expected for persistent daemons and 'always' is not set in metadata. Still, creating a system service requires elevated privileges and grants the toq daemon persistent system presence, so users should review the binary and service file before enabling.
What to consider before installing
This skill is coherent with an agent-to-agent messaging tool but contains several risky recommendations you should treat cautiously: - Do NOT run curl https://toq.dev/install.sh | sh unless you have inspected that script and trust the toq.dev domain. Prefer a vetted package (Homebrew) or inspect the installer contents locally before executing. - The setup step uses ifconfig.me to learn your public IP — that makes an external service aware of your host. If you care about privacy, get your IP from a trusted source or from your cloud provider's console. - Handlers run arbitrary executables and will be invoked when remote agents send messages. Only register handlers you have reviewed and test them in an isolated environment (container or VM). Treat incoming messages as untrusted input. - Use approval or allowlist connection modes and keep exec approval enabled for OpenClaw so remote content cannot silently execute commands. Avoid 'open' mode unless you explicitly want public access. - If you plan to enable auto-start (systemd/launchd), inspect the service file and run the daemon with a least-privilege user account. Consider running in a container or dedicated VM. - Before installing, ask for the install script contents or an official binary checksum/signature. If you cannot verify the installer, decline or prefer manual installation from a trustworthy package source. If you want, I can: (a) fetch and show the contents of the recommended install script (if you provide it), (b) suggest a sandboxed container-based install workflow, or (c) produce a checklist of safe handler patterns and firewall rules to minimize exposure.

Like a lobster shell, security has layers — review code before you run it.

latestvk97ebcb8nx2v0w2httf87x9zzn833x7a

License

MIT-0
Free to use, modify, and redistribute. No attribution required.

Comments