Security audit
Security checks for vulnerabilities and agentic risk
This skill is mostly aligned with Alibaba Cloud SysOM diagnosis, but it can change local tooling settings and cloud alert/SysOM state while explicitly suppressing confirmation and partly describing diagnosis as read-only.
Review this skill before installing. It is not clearly malicious, but installing it means an agent may use existing Alibaba Cloud credentials, modify Aliyun CLI/plugin state, initialize SysOM authorization, run diagnosis, install a local SDK environment, and create DingTalk alert resources without a confirmation checkpoint once required inputs are available. Use a least-privilege RAM profile and be prepared to remove alert destinations/strategies from the SysOM console if they are created.
The skill exercises sensitive capabilities beyond plain text guidance: it reads local credential/config state and references additional local files, yet no explicit permission declaration is present. In an agent framework, undeclared capabilities reduce transparency and can bypass expected consent or policy review for filesystem and environment access.
The declared description emphasizes diagnosis, but the workflow also modifies local tooling state, installs SDK dependencies, reads credential sources, and creates remote alerting resources. This mismatch can cause users or reviewers to authorize the skill for a narrower purpose than what it actually does, increasing the chance of unanticipated local and cloud-side changes.
The document says credentials must only be configured outside the session, but later instructs the agent to run 'aliyun configure set --auto-plugin-install true', which changes CLI configuration during execution. Contradictory security guidance makes operator behavior unpredictable and can normalize in-session modification of local auth/tooling state.
The skill claims operations are read-only, but its workflow updates plugins, changes CLI configuration, initializes roles, and can create alert destinations and alert strategies. Misrepresenting mutating behavior as read-only undermines user trust and can lead to unauthorized persistent changes in local or cloud environments.
The file states in Cleanup that 'diagnosis is read-only,' but the documented workflow includes aliyun sysom initial-sysom --check-only false, which can perform role authorization changes rather than a purely read-only action. This mismatch can mislead an agent or operator into running a mutating command under the assumption that it has no side effects, increasing the risk of unintended privilege or configuration changes in the cloud environment.
The workflow instructs the agent to update plugins, alter CLI settings, and later set up a Python virtual environment/SDK without clearly warning the user in the top-level description. Silent modification of the execution environment can introduce supply-chain risk, alter future command behavior, and create persistence on the host running the agent.
The acceptance criteria explicitly require English-only keywords for ocd_description and mark passing non-English text as incorrect, which can force translation or transformation of user input without consent. This creates a safety and integrity risk because meaning can be altered, user intent may be misrepresented, and multilingual users may be excluded or have diagnostic context degraded.
The workflow instructs the agent to immediately use a user-supplied DingTalk webhook to create an alert destination, but it does not require any explicit disclosure that operational alerts and potentially sensitive system metadata will be transmitted to a third-party endpoint. In a security-sensitive diagnostics skill, silent forwarding to an external service creates a real data-sharing and privacy risk, especially if users do not understand that DingTalk is outside the primary cloud environment or if the webhook is misconfigured to an unintended recipient.
The guide shows users how to pass long-lived access keys directly on the command line and via exported environment variables, but it does not immediately warn that these values can be exposed through shell history, process listings, terminal scrollback, CI logs, and shared session transcripts. In an agent/automation context, this is more dangerous because users may paste real secrets into scripted or logged environments, leading to credential disclosure and subsequent cloud account compromise.
The document explicitly shows that access keys are stored in ~/.aliyun/config.json, including a sample containing plaintext secrets, without an immediate warning that this file is sensitive. Readers may underestimate the risk and leave the file world-readable, back it up insecurely, or commit similar files, enabling theft of cloud credentials and unauthorized access.
The skill explicitly directs the agent to proceed with diagnosis without a confirmation round once two parameters are present. Because the workflow includes external API calls and some state-changing setup steps, removing confirmation increases the risk of unintended actions against the wrong resource or without informed consent.
For detailed workflow, see [references/diagnose-workflow.md](references/diagnose-workflow.md).
**Step 4 — Parameter Collection (No Confirmation Round)**
`region` and `instance_id` are the only blocking inputs. The `instance_id` must be a **lingjun node ID** (`e01-cn-xxxxx`). If either is missing from the user's request, ask for it explicitly; once both are known, **go straight to Step 5 — do NOT ask the user to confirm the parameters or to approve starting the diagnosis**. Also extract optional `ocd_description` (must be translated to English) and the time range from the description.
The workflow explicitly suppresses a confirmation step and instructs the agent to start diagnosis immediately once region and instance_id are known. Because the skill can trigger cloud-side diagnostic actions and polling without an explicit user approval checkpoint, it increases the risk of unintended operations against the wrong resource or of running a potentially sensitive diagnosis the user did not mean to launch yet.
---
## Step 4 — Parameter Collection (No Confirmation Round)
Only the following two parameters are blocking. If the user's question does not include them, ask for them — **do NOT guess or use default values**. Once both are known, start the pipeline immediately: **do NOT open a confirmation round** asking the user to approve the parameters, the diagnosis mode, or the workflow.
No suspicious patterns detected.