Security audit
Security checks for vulnerabilities and agentic risk
This skill is a disclosed IoT control tool, but it can open or close real-world water valves from broad natural-language commands without an explicit confirmation or device-specific selection.
Install only if you are comfortable letting the assistant control YZL IoT devices, including water valves. Use it in contexts where valve commands are deliberate, and prefer explicit manual commands with device IDs; review access to YZLIOT_API_KEY and be aware that each run may check ClawHub for version information.
The skill advertises runtime requirements and behavior implying environment access, file reads/writes, and network use, but does not declare an explicit tool/permission scope. This weakens least-privilege controls and makes it harder for users or the host platform to understand and constrain what the skill can access, especially since it performs outbound requests and caches update checks.
The skill enables remote opening and closing of water valves but does not prominently warn users that it can alter physical infrastructure state. Absent a clear warning and confirmation expectations, users may not appreciate that a simple natural-language command can trigger consequential real-world actions such as irrigation changes, water loss, or equipment stress.
The trigger phrases are broad everyday commands like '获取液位' and '打开电磁阀', which can be matched during ordinary conversation and cause the assistant to invoke the skill unexpectedly. Because this skill can send remote control commands to physical devices, accidental activation could change real-world system state without sufficiently explicit user intent.
The natural-language examples use casual phrases such as '帮我看看传感器数据' and '关闭水阀', which are ambiguous in normal conversation but map directly to device reads and control actions. In a voice or chat assistant context, this raises the risk of unintended skill execution and unauthorized physical actuation.
User-facing strings, help text, and natural-language command handling are all fixed to Chinese, including the smart-command trigger logic that checks for Chinese input and specific Chinese keywords. This effectively forces a language/locale without presenting the user with a choice or documenting an explicit opt-in.
The smart command path can open or close a real-world valve based on loose natural-language matching and immediately sends the command without a user confirmation step. In an IoT/actuator context, unintended execution can cause physical consequences such as water flow, equipment damage, waste, or safety incidents, making this significantly more dangerous than ordinary API automation.
The documentation states that every run performs a silent outbound version check, but it does not clearly warn users up front that normal use generates network traffic beyond the core IoT API operations. Silent background requests can create privacy, policy, and surprise-behavior concerns, particularly in restricted or sensitive environments.
The skill's stated purpose is managing YZL IoT devices, but these functions persist a .version_cache.json file solely for marketplace version checking. Local file persistence for self-update metadata is ancillary behavior outside the declared device-management scope.
The manifest description scopes the skill to '云智联 IoT 设备管理API', which reasonably covers communicating with the IoT platform for device operations. However, this file additionally contacts the external ClawHub registry to check skill versions and migration status, which is not part of IoT device management itself.
On startup, the skill contacts an external registry endpoint and writes a local .version_cache.json file, but this behavior is not disclosed in a user-facing warning within the code path that runs automatically. For safety/quality review, automatic network and file-write behavior should be visible to users unless clearly documented.
The manifest description only says the skill is an IoT device management API, but the implementation depends on reading YZLIOT_API_KEY from the host environment. While common for API clients, credential access is still a host-side capability not described in the manifest text provided.
