Skill flagged — suspicious patterns detected
ClawHub Security flagged this skill as suspicious. Review the scan results before using.
Perfect Agent Comms
v1.0.1Agent-to-agent communication via HTTP bridge with cron-based polling. Use when: (1) two OpenClaw agents need to talk across instances, containers, or machine...
⭐ 0· 74·0 current·0 all-time
byJoel Yi - DeployAIBots.com@joelsalespossible
MIT-0
Download zip
LicenseMIT-0 · Free to use, modify, and redistribute. No attribution required.
Security Scan
OpenClaw
Suspicious
medium confidencePurpose & Capability
The code and instructions match the stated purpose (an HTTP JSONL bridge for two agents). The auth token(s) and URL the SKILL.md requires (ACP_BRIDGE_TOKEN, BRIDGE_TOKEN, BRIDGE_URL) are appropriate for this functionality. However the registry metadata lists no required environment variables or primary credential, which is inconsistent with the SKILL.md and included code that will refuse to run without ACP_BRIDGE_TOKEN. That mismatch should be fixed in the registry before trusting installation.
Instruction Scope
The cron templates and SKILL.md explicitly instruct responding agents to read workspace files (SESSION-STATE.md, SOUL.md, 'today's memory file') and to run workspace scripts and tools. That is coherent with providing contextual replies, but it gives the bridge-enabled agent broad discretion to access arbitrary workspace data — including secrets — and to send that data across the bridge. The SKILL.md warns to only share tokens with agents you control, but the runtime instructions still enable sensitive data exposure if tokens are shared with untrusted agents.
Install Mechanism
This is instruction-only with no install spec, and the included helper scripts are plain Python/bash files. Nothing is downloaded from external URLs and no archives are extracted, which is lower risk. Still, the operator will run a long-lived Python process via nohup/cron, so standard operational hardening is needed.
Credentials
The skill requires ACP_BRIDGE_TOKEN (server) and BRIDGE_TOKEN / BRIDGE_URL (helpers) according to SKILL.md — these are proportional to the bridge function. But the registry incorrectly declares no required env vars or primary credential. That omission is an important inconsistency: the skill will not work (or will be insecure) without these tokens, and the registry should declare them so operators can make an informed decision. The skill does not request unrelated credentials (AWS, GitHub, etc.).
Persistence & Privilege
The skill does not set always: true and does not modify other skills. It instructs operators to run a persistent bridge service (nohup python3 acp_bridge.py), which is expected. One operational risk: the server code binds to 0.0.0.0 by default (listen on all interfaces) — if deployed without correct firewall/host binding or reverse proxy/TLS, it may become publicly reachable. The SKILL.md mentions binding to localhost or using a reverse proxy, but the code's default listen address and the registry metadata omission of required env vars increase the chance of misconfiguration.
What to consider before installing
Key things to check before installing/using this skill:
1) Registry metadata mismatch — SKILL.md requires ACP_BRIDGE_TOKEN (server) and BRIDGE_TOKEN/BRIDGE_URL (helpers), but the registry lists no required env vars. Don't proceed until the package/registry declares these env vars (and primaryEnv) so you know what secrets are needed and why.
2) Token trust boundary — any agent or person with the shared token can read/write messages. Only share ACP_BRIDGE_TOKEN with agents/hosts you fully control. Treat the token like a password and rotate it periodically.
3) Network exposure — the included server binds to 0.0.0.0 by default. If you run it as instructed (nohup python3 acp_bridge.py &), ensure it is behind a firewall, bound to localhost, or fronted by a reverse proxy with TLS. Do not open port 18790 to the public internet without additional protections.
4) Data-exfiltration risk via cron prompts — the cron templates explicitly instruct the agent to read workspace files and include workspace lookups in replies. If one agent is less trusted, it could exfiltrate secrets from the other agent's workspace. Only enable automated polling between agents you control, and consider restricting which workspace files the bridge cron can read.
5) Runbook and monitoring — follow the provided monitoring/heartbeat templates and set up pruning to avoid large JSONL files. Prefer a supervised service (systemd, supervisor) rather than ad-hoc nohup so the bridge restarts reliably.
6) Review defaults and harden before production — change BRIDGE_DIR from /tmp if you need persistence/permissions control; ensure logs, file permissions, and token storage are secure.
7) Code review items to consider: the /api/clear endpoint exists (authorized by token) and will remove JSONL files; the server checks for ACP_BRIDGE_TOKEN at startup (so it should not run in 'open' dev mode), but verify behavior in your environment. If you need further assurance, run the bridge on an isolated host or inside a network-restricted container and conduct a quick security review of the scripts.
If you want, I can: (a) generate a minimal checklist and hardened startup systemd unit, (b) propose safer default changes (bind to 127.0.0.1, require TLS at proxy), or (c) produce a suggested registry metadata update that lists required env vars and primary credential.Like a lobster shell, security has layers — review code before you run it.
latestvk97d2vrc7cv0qtb933bktk5q3x83hp52
License
MIT-0
Free to use, modify, and redistribute. No attribution required.