Lark Integration
Security checks across malware telemetry and agentic risk
Overview
The Lark bridge is mostly aligned with its purpose, but it under-declares sensitive credentials and creates a persistent public messaging-to-agent bridge with broad local operator authority.
Install only if you are comfortable running a long-lived Lark-to-OpenClaw bridge. Before use, require HTTPS and Lark webhook verification/encryption, restrict which chats/users can invoke the bot, avoid running the service as root, verify the script filenames/dependencies, and understand that the bridge reads local OpenClaw gateway credentials and can submit messages to the agent.
VirusTotal
64/64 vendors flagged this skill as clean.
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.
Lark messages can be routed through a bridge that has broad local OpenClaw operator access, so a chat message may cause the local agent to act with more authority than users expect.
The bridge reads the local OpenClaw gateway auth token and connects with operator read/write scopes. That is powerful local agent authority, yet the registry metadata declares no required credentials or config paths.
const GATEWAY_TOKEN = clawdConfig?.gateway?.auth?.token; ... role: 'operator', scopes: ['operator.read', 'operator.write'], auth: { token: GATEWAY_TOKEN }Declare the OpenClaw config/token requirement, use the narrowest possible gateway scope, bind the bridge to a dedicated limited agent, and require clear user approval or allowlisting for high-impact actions.
Private chat text and images may traverse a public plaintext webhook and be fed into the local agent boundary; unwanted or spoofed traffic could trigger agent runs if deployment controls are weak.
The documented setup exposes a public HTTP webhook that forwards Lark content into the local OpenClaw gateway. The reviewed instructions do not clearly require HTTPS, webhook verification, sender allowlisting, or other boundary controls.
URL: http://YOUR_SERVER_IP:3000/webhook ... Bridge (port 3000) ──WebSocket──► OpenClaw Gateway
Use HTTPS behind a reverse proxy, configure Lark verification/encryption, restrict network access where possible, and document exactly which Lark senders/chats are allowed to invoke the bridge.
People in a group chat may unintentionally trigger the agent, and malicious or careless messages could steer the agent or cause public replies.
The bridge is documented to invoke/respond in group chats based on broad heuristics, not only explicit bot mentions. Combined with the gateway bridge, ordinary group messages can become agent prompts.
In group chats, the bridge responds when: ... Message ends with `?` or `？` ... Message contains trigger words: help, please, why, how, what, 帮, 请, 分析, etc.
Default to explicit mentions or a configured allowlist of chats/users, and make broad heuristic triggering opt-in with clear warnings.
After installation, the bridge can continue running in the background and processing Lark messages until the service is unloaded or disabled.
The helper creates a launchd service that starts automatically and restarts persistently. This is consistent with a bridge service, but users should explicitly understand and manage the long-running behavior.
<key>RunAtLoad</key>\n <true/>\n\n <key>KeepAlive</key>\n <true/>
Install the service only if continuous background operation is intended, provide clear stop/uninstall steps, and avoid running it with elevated privileges.
The service may fail, or a user may add/run an unreviewed replacement file to make it work, weakening trust in what the background service actually runs.
The service helper points at bridge.mjs, but the provided manifest contains bridge-webhook.mjs and no bridge.mjs. The package.json start script also references bridge.mjs, creating a missing-file/provenance gap for the persistent service.
const BRIDGE_PATH = path.resolve(import.meta.dirname, 'bridge.mjs');
Align all scripts to the shipped bridge-webhook.mjs file, include any referenced runtime files, and provide a complete install spec with pinned dependencies.