Security audit
Security checks for vulnerabilities and agentic risk
The skill is mostly coherent, but it can send live IoT device-control commands and signed requests to configurable gateways without enough guardrails.
Install only if you intend this agent to both read XLink IoT data and control devices. Use least-privilege XLink credentials, keep XLINK_BASE_URL pinned to the official HTTPS gateway or a trusted internal gateway, avoid debug logs with sensitive command payloads, and require human review before any device-control command is run.
scripts/xlink_api.py:170Unvalidated Gateway URL Allows Signed Requests and Sensitive IoT Data to Be Sent over Cleartext or to an Untrusted Host
The top-level description frames the skill as a query and monitoring agent, but the body also includes active device control and service invocation. That mismatch can cause users or orchestrators to invoke the skill under a read-only trust model when it can actually change real-world device state, increasing the chance of unintended or unauthorized actions.
The skill metadata says it is for querying devices and monitoring events, but the included API documentation exposes a write-capable control endpoint (/v2/device-shadow/service_invoke) that can change device state. This creates a capability/expectation mismatch that can lead an agent or user to invoke operational commands on IoT devices without realizing the skill is not read-only, potentially affecting physical systems.
The skill metadata says it is for querying IoT devices and monitoring events, but this reference documents an active device-control command that can change physical device state. That capability expansion is dangerous because an agent or user relying on the manifest may invoke state-changing operations without appropriate consent, safety checks, or authorization expectations.
The Python API example exposes control_device(...) even though the skill description presents the agent as query/monitoring-focused. Hidden or under-declared actuation paths increase the risk of misuse by downstream integrators and autonomous agents that assume the skill is read-only.
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
| `200` | Success |
| `4001001` | Bad request |
| `4001002` | Missing required field |
| `4031003` | Invalid access token |
| `4041001` | Resource not found |
| `40428001` | Device not found |
| `40428009` | Product thing model not defined |
The skill metadata describes read-only querying and monitoring, but the implementation includes a write-capable control_device method that can invoke arbitrary device services. This creates a dangerous capability mismatch: a caller or reviewer may authorize the skill expecting passive access, while the code can actively change device state, potentially affecting physical systems.
The CLI exposes a device-control command even though the published skill description only advertises query and monitoring operations. Hidden write functionality increases the risk of misuse, over-privileged deployment, and unsafe automation against IoT devices because operators may not realize the skill can send commands.
The skill documents use of environment variables and outbound network access to the XLink API, but it does not declare any explicit tool scope such as permissions or allowed-tools. This creates an authorization and transparency gap: an execution environment may grant broader capabilities than users expect, making secret access and external communication less visible and less constrained.
The skill advertises device control operations but does not provide a prominent warning that commands may alter physical device behavior in the real world. In an IoT context, changing power, brightness, or service parameters can affect safety, operations, or availability, so lack of warning raises the risk of accidental harmful actions.
The high-level usage section mixes benign read operations with a device control example, contradicting the skill's stated read/query-focused purpose. This mismatch is dangerous because downstream agents and users may trust the declared scope while the embedded example normalizes invoking state-changing functions, increasing the chance of unintended physical or operational impact on IoT devices.
The documentation explicitly demonstrates control_device(...) even though the skill is described as query/monitoring-oriented. In an agent setting, examples often shape model behavior; showing a state-changing API can cause the agent or integrators to invoke write operations against IoT devices outside the declared scope, creating unauthorized or unsafe actuation risk.
The device control documentation describes sending commands and setting device attributes, including cached commands via TTL, but provides no warning that these actions may immediately alter real device behavior or persist for later delivery. In an IoT context, silent state-changing operations can disrupt equipment, trigger unsafe behavior, or cause outages if an agent invokes them based on ambiguous prompts.
The control examples show how to power on devices and change attributes without warning that these commands alter physical state. In an IoT context, silent actuation can cause operational disruption, safety issues, or unauthorized changes if copied into agent workflows without user awareness.
The documentation includes a device control endpoint that can change real-world device state but does not clearly warn about operational risk, authorization sensitivity, or the need for confirmation before invocation. In an agent context, missing safety guidance can increase the chance of unintended commands being sent to production IoT devices, causing service disruption or unsafe physical effects.
The CLI can send device control commands immediately with no confirmation, dry-run, or cautionary warning. For IoT systems, a mistaken invocation or prompt-injected automation path could directly alter device behavior, creating operational disruption or physical-world consequences depending on what the target device controls.
In debug mode, the tool logs the full device control parameters, including thing_id, service name, and input payload. Those logs can expose sensitive operational details or command contents to log readers and downstream log systems, which is especially risky for IoT environments where commands may reveal credentials, locations, or safety-relevant actions.
The main CLI docstring says the tool is for device overview and event queries, understating that it also performs device control. This kind of misleading documentation can cause unsafe trust decisions, inaccurate reviews, and accidental approval of a write-capable tool in contexts where only read access was expected.
The setup instructions ask users to export application credentials, including a secret, but do not warn about secure secret handling, shell history exposure, or accidental logging. While the markdown itself does not leak the secret, normalizing insecure credential handling can lead to credential compromise and subsequent unauthorized API access.
The entire skill reference is written in Chinese with no indication that other language options are available. Under the policy, forcing a specific language without user opt-in can be a natural-language policy violation unless the locale constraint is explicitly documented and justified.
The markdown instructs users to provide XLINK_APP_SECRET as an environment variable, but it does not warn that this value is sensitive credential material that should not be logged, shared, or committed. For markdown files, omission of privacy or credential-safety warnings is in scope when the documented behavior involves sensitive data.
This markdown file includes user-facing schema examples and field values in Chinese, such as device names, without stating that the skill or documentation is intended for a Chinese-speaking or region-specific audience. Under the language/locale policy rule, forcing or assuming a specific language without opt-in can be a policy concern.
This section contains Chinese-only strings in event names and status descriptions, but the document does not explain that the API is locale-specific or provide a language selection/translation policy. That can violate language/locale expectations for general-purpose skill documentation.
The script emits substantial user-facing text in Chinese and also relies on Chinese status labels in parts of the interface, but it does not offer a locale or language selection. This can violate language/locale policy where tools must not force a specific language absent opt-in or documented regional scope.
No suspicious patterns detected.