Multi-Agent Intercom
Security checks across static analysis, malware telemetry, and agentic risk
Overview
The skill is transparent about being an inter-agent messaging tool, but it creates a persistent, unauthenticated backchannel that tells agents to immediately act on and reply to peer messages.
Install only if you intentionally want local agents to message and wake each other. Before using it, limit which agents may communicate, add sender verification, avoid sensitive data in intercom messages, and revise the SOP so agents ask for human approval before acting on high-impact requests.
Static analysis
No static analysis findings were reported for this release.
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.
Any local agent that can invoke the skill may be able to page another agent and cause it to process a message as if it came from a trusted peer.
The skill explicitly creates cross-agent communication across isolation boundaries and forces target agents to process messages, but the artifacts do not show authentication, authorization, sender verification, or an allowlist.
Cross-Boundary Messaging — reach any agent on the same system ... Immediate Wake-up — bypasses sleep states, forces target to process now
Only use this in a trusted multi-agent setup, and add clear allowlists, sender verification, and rules for what agents may share or do in response.
A peer message could redirect an agent's attention and actions away from the current user task, especially after the SOP is pasted into AGENTS.md.
The generated persistent SOP instructs agents to treat intercom messages as mandatory work and to reply to the calling agent, without requiring confirmation from the human user.
You MUST process this message immediately. After processing, you MUST use the send command above to reply to the sender.
Modify the SOP so agents verify the sender, assess whether the request is authorized, and ask the human before taking sensitive actions.
An agent or user could spoof another agent's identity in messages, making recipients trust the wrong source.
The sender identity is just a user-supplied string used to label the message; the code does not verify that the invoking agent is actually that sender.
send_parser.add_argument("sender_id", help="Your own agent ID ... for Caller ID") ... tag = f"[From Agent {sender_id}] "Require a trusted identity mechanism or restrict sender IDs to verified local agent identities before recipients act on messages.
Instructions or misleading content sent through the intercom could become part of an agent's ongoing context and influence later behavior.
The setup process makes the protocol persistent in agent instructions, and messages are sent to the long-lived main session by default.
paste it at the bottom of each agent's `AGENTS.md` file ... Persistent Context — targets the `main` session by default
Keep the protocol narrowly scoped, avoid placing untrusted content in main sessions, and periodically review AGENTS.md and main-session context for unwanted instructions.
A mistaken or malicious invocation could send unintended instructions into another agent's session.
The script exposes a raw OpenClaw agent command that can target arbitrary agent IDs and session IDs, with no built-in confirmation or scope restriction.
cmd_args = ['openclaw', 'agent', '--agent', target, '--session-id', session_id, '--message', final_message]
Add target allowlists, require approval for sensitive messages, and avoid allowing autonomous use for high-impact tasks.
Messages may be sent and processed in the background without visible output or error details.
The skill intentionally launches the OpenClaw CLI in a detached background process; this is disclosed and purpose-aligned, but it reduces visibility into what happened.
subprocess.Popen(... stdout=subprocess.DEVNULL, stderr=subprocess.DEVNULL ... close_fds=True)
Use this only when background operation is desired, and consider adding logging or a visible confirmation path for auditing.