T08 · Insecure Dependencies
- Location
references/cli-installation-guide.md:35- Finding
Unverified Mutable CLI Binary Installed into a System-Wide Executable Path
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
This skill is a legitimate PAI-EAS troubleshooting guide, but it gives an agent broad autonomous cloud-reading behavior and includes risky credential, token, and CLI installation guidance that users should review before installing.
Install only with a least-privilege read-only EAS/RAM identity, avoid pasting real AccessKey secrets into agent-visible commands, verify any CLI downloads before installation, and require the agent to confirm the exact region and service before it reads logs, events, endpoint data, or container details.
references/cli-installation-guide.md:35Unverified Mutable CLI Binary Installed into a System-Wide Executable Path
references/cli-installation-guide.md:116Long-Lived Cloud Credentials Exposed Through Command Arguments and Environment Variables
references/diagnosis-flow.md:164Service Authentication Token Can Be Disclosed by Unfiltered Endpoint Queries
The file explicitly identifies .Token as an access credential, and in the context of troubleshooting APIs this creates a realistic path for accidental credential access and exposure. While the doc does not itself steal credentials, surfacing a retrievable token in a quick-reference skill without safeguards makes sensitive data easier to retrieve and mishandle.
|-------|-------------|
| `.InternetEndpoint` | Public endpoint |
| `.IntranetEndpoint` | Internal endpoint |
| `.Token` | Access Token |
---
This file is materially out of scope for an EAS diagnosis-only skill: it provides broad Aliyun CLI installation and account configuration guidance rather than narrowly scoped troubleshooting content. In an agent skill, this increases the chance the agent will prompt for or rely on cloud credentials and perform unrelated actions, expanding the attack surface and violating least-privilege expectations for the skill.
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
| Cause | Solution |
|-------|----------|
| Incorrect image address | Check image address format, use VPC internal address |
| Insufficient permissions | Configure image registry access credentials |
| Image does not exist | Confirm image has been pushed to registry |
| Network unreachable | Use VPC internal image address |
Broad trigger phrases like '看日志' and '响应慢' can cause the skill to activate in situations where the user did not clearly intend cloud-service diagnostics. Because the skill then performs autonomous inspection of services, logs, events, and containers, accidental invocation can lead to unnecessary access to sensitive operational metadata.
The skill expands from diagnosing EAS services into inspecting the caller's RAM policies via RAM APIs that are not part of the declared tool scope or permissions. That broadens access from service diagnostics to identity/authorization reconnaissance, which can expose sensitive IAM structure and encourage execution of extra-privileged actions beyond the stated purpose.
The skill explicitly directs autonomous execution against the user's cloud environment without first warning that it will inspect service metadata, logs, events, instances, and container details. This creates a consent and data-minimization problem: a casually phrased request can trigger broad read access to operational data that may contain secrets, internal topology, or tenant-sensitive information.
This instruction tells the agent not to ask the user for information it can discover itself, encouraging autonomous enumeration of services and related metadata. In a cloud environment, that increases the chance of over-collection and accessing resources beyond the user's intended target.
> **[MUST] This skill is designed for autonomous diagnosis. Follow these rules:**
>
> 1. **Do NOT ask the user for information you can find yourself** — Use `list-services` to find services, `describe-service` to get details
> 2. **If the user provides a region (e.g., "cn-hangzhou"), use it directly** — Do NOT ask for confirmation
> 3. **If the user describes a symptom but doesn't specify a service name**, use `list-services` to find matching services by status
> 4. **If a command times out or fails, retry once or try a different approach** — Do NOT ask the user to troubleshoot CLI issues
The directive to execute commands directly and avoid asking 'should I proceed?' removes a consent checkpoint before accessing live cloud resources. In combination with log and container inspection, this can result in unauthorized or unexpected collection of sensitive diagnostic data.
> 1. **Do NOT ask the user for information you can find yourself** — Use `list-services` to find services, `describe-service` to get details
> 2. **If the user provides a region (e.g., "cn-hangzhou"), use it directly** — Do NOT ask for confirmation
> 3. **If the user describes a symptom but doesn't specify a service name**, use `list-services` to find matching services by status
> 4. **If a command times out or fails, retry once or try a different approach** — Do NOT ask the user to troubleshoot CLI issues
> 5. **Execute commands directly** — Do NOT ask "should I proceed?" before each step
> 6. **Provide the diagnosis results proactively** — Do NOT wait for the user to confirm each step
Skill enables autonomous high-impact decisions without human-in-the-loop verification. Critical operations (destructive commands, financial transactions, data deletion) should require explicit user confirmation.
**If any command times out:**
1. Retry once with `--read-timeout 60` flag
2. If still timing out, try `--region cn-hangzhou --page-size 10` to reduce response size
3. Do NOT ask the user to troubleshoot network issues — handle it yourself
---
Skill enables autonomous high-impact decisions without human-in-the-loop verification. Critical operations (destructive commands, financial transactions, data deletion) should require explicit user confirmation.
> **[MUST] Execution Rules:**
> - You MUST execute each command directly — do NOT write scripts without executing them
> - You MUST wait for each command's output before proceeding to the next step
> - If a command fails or times out, retry once — do NOT ask the user to troubleshoot
> - If a command still fails after retry, skip to the next diagnostic step and report the error at the end
> - Do NOT ask the user "should I proceed?" or "please confirm" — just execute the diagnostic workflow
Telling the agent not to ask 'should I proceed?' or 'please confirm' explicitly suppresses user approval before executing diagnostic steps on a live environment. Given the workflow's mandatory access to events, logs, instances, and containers, this materially raises the risk of non-consensual data access.
- You MUST wait for each command's output before proceeding to the next step
- If a command fails or times out, retry once — do NOT ask the user to troubleshoot
- If a command still fails after retry, skip to the next diagnostic step and report the error at the end
- Do NOT ask the user "should I proceed?" or "please confirm" — just execute the diagnostic workflow
0. [MUST] CLI Environment Verification → Confirm EAS plugin AND DescribeServiceLog API are working
Reinforcing that the agent must execute commands directly and autonomously normalizes remote actions without consent checks. In this skill's context, the danger is elevated because the commands inspect potentially sensitive service health data and logs across the user's cloud account.
4. **[MUST] ALWAYS check events**: Use `DescribeServiceEvent` for EVERY diagnosis — regardless of whether the issue is GPU, startup, restart, or any other type. Events are critical for understanding the timeline
5. **[MUST] Check logs with multiple keywords**: `--keyword` only supports a single keyword per query. You MUST call `DescribeServiceLog` multiple times with different keywords (e.g., `--keyword "error"`, `--keyword "oom"`, `--keyword "killed"`, `--keyword "exit"`)
6. **[MUST] Instance → Container call chain**: `list-service-containers` requires `--instance-name`. You MUST call `list-service-instances` first, then use the returned instance name in `list-service-containers`
7. **[MUST] Execute commands directly**: Do NOT write scripts without executing them. Do NOT ask the user "should I proceed?" — just execute the diagnostic workflow autonomously
8. **[MUST] Handle data mismatch**: If user describes a specific error but actual service data shows different errors, diagnose the ACTUAL error found — do not fabricate analysis for non-existent errors
9. **[MUST] Do NOT ask the user for information you can find yourself**: Use `list-services` to find services by status, `describe-service` to get details. Do NOT ask for ServiceName, Cluster ID, or other information that can be obtained programmatically
The instruction not to ask for service name, cluster ID, or other information the agent can obtain programmatically encourages broad discovery against the environment. That can expand the scope from a specific troubleshooting request into account-wide enumeration of services and infrastructure metadata.
6. **[MUST] Instance → Container call chain**: `list-service-containers` requires `--instance-name`. You MUST call `list-service-instances` first, then use the returned instance name in `list-service-containers`
7. **[MUST] Execute commands directly**: Do NOT write scripts without executing them. Do NOT ask the user "should I proceed?" — just execute the diagnostic workflow autonomously
8. **[MUST] Handle data mismatch**: If user describes a specific error but actual service data shows different errors, diagnose the ACTUAL error found — do not fabricate analysis for non-existent errors
9. **[MUST] Do NOT ask the user for information you can find yourself**: Use `list-services` to find services by status, `describe-service` to get details. Do NOT ask for ServiceName, Cluster ID, or other information that can be obtained programmatically
---
Skill enables autonomous high-impact decisions without human-in-the-loop verification. Critical operations (destructive commands, financial transactions, data deletion) should require explicit user confirmation.
# Wrong: Using default region without asking the user
Skill enables autonomous high-impact decisions without human-in-the-loop verification. Critical operations (destructive commands, financial transactions, data deletion) should require explicit user confirmation.
# Wrong: Using default region without asking the user
aliyun eas describe-service --cluster-id cn-hangzhou --service-name my-service --user-agent AlibabaCloud-Agent-Skills/alibabacloud-pai-eas-service-diagnose
The reference documents that describe-service-endpoints returns a .Token access token but provides no handling guidance such as redaction, least-privilege use, or warnings against printing and sharing it. In a diagnostic skill, operators are likely to copy command output into chats, logs, or tickets, which increases the chance of credential disclosure and unauthorized access to service endpoints.
Commands invoke sudo or root privileges. Verify this elevated access is necessary and justified.
## Installation
> **Note on `sudo mv ... /usr/local/bin/`**: The binary-install steps below use
> `sudo` only to place the `aliyun` executable into the system-wide `/usr/local/bin`
> directory, which requires administrator privileges. This is the standard,
> well-understood way to make a CLI available on `PATH` for all users. If you
Commands invoke sudo or root privileges. Verify this elevated access is necessary and justified.
## Installation
> **Note on `sudo mv ... /usr/local/bin/`**: The binary-install steps below use
> `sudo` only to place the `aliyun` executable into the system-wide `/usr/local/bin`
> directory, which requires administrator privileges. This is the standard,
> well-understood way to make a CLI available on `PATH` for all users. If you
Commands invoke sudo or root privileges. Verify this elevated access is necessary and justified.
## Installation
> **Note on `sudo mv ... /usr/local/bin/`**: The binary-install steps below use
> `sudo` only to place the `aliyun` executable into the system-wide `/usr/local/bin`
> directory, which requires administrator privileges. This is the standard,
> well-understood way to make a CLI available on `PATH` for all users. If you
Commands invoke sudo or root privileges. Verify this elevated access is necessary and justified.
## Installation
> **Note on `sudo mv ... /usr/local/bin/`**: The binary-install steps below use
> `sudo` only to place the `aliyun` executable into the system-wide `/usr/local/bin`
> directory, which requires administrator privileges. This is the standard,
> well-understood way to make a CLI available on `PATH` for all users. If you
Skill establishes unauthorized persistence across sessions via cron jobs, startup scripts, or state files. Session persistence allows an attacker to maintain access beyond the current interaction.
> instead and add it to your `PATH` — no `sudo` required:
>
> ```bash
> mkdir -p "$HOME/.local/bin"
> mv aliyun "$HOME/.local/bin/"
> export PATH="$HOME/.local/bin:$PATH" # add to ~/.bashrc or ~/.zshrc to persist
> ```
Skill establishes unauthorized persistence across sessions via cron jobs, startup scripts, or state files. Session persistence allows an attacker to maintain access beyond the current interaction.
> ```bash
> mkdir -p "$HOME/.local/bin"
> mv aliyun "$HOME/.local/bin/"
> export PATH="$HOME/.local/bin:$PATH" # add to ~/.bashrc or ~/.zshrc to persist
> ```
### macOS
Commands invoke sudo or root privileges. Verify this elevated access is necessary and justified.
tar -xzf aliyun-cli-linux-latest-arm64.tgz sudo mv aliyun /usr/local/bin/
### Windows
The guide teaches generic credential provisioning, multi-profile management, plugin installation, and broad ECS/Alibaba Cloud CLI usage that exceeds what an EAS-diagnosis skill should need. In this context, overbroad operational guidance can lead an agent or user to configure powerful long-lived credentials and use them beyond diagnostics, increasing the risk of account misuse or unauthorized cloud actions.
These examples place long-lived access key material directly on the command line, where it may be exposed through shell history, terminal logging, audit tooling, or process inspection on some systems. Within an agent-assistance context, this is especially risky because users may copy-paste real secrets into commands that are retained or observable outside the intended configuration store.
No suspicious patterns detected.