Security audit
Security checks for vulnerabilities and agentic risk
The skill is mainly a diagnostic helper, but it makes contradictory claims about having no network or write behavior while its script can fetch online docs and write a local cache.
Install only if you are comfortable with the skill contacting help.aliyun.com for some questions and writing a documentation cache under your home directory. Do not paste AccessKeys, secrets, or STS tokens into chat, and review any generated RAM policy carefully before applying it, especially PutObject/DeleteObject permissions.
This is a true scope/behavior mismatch: the manifest promises a read-only diagnosis assistant that makes no API calls, yet the skill text requires outbound documentation fetches, local caching, and broader topic handling. Such mismatches are dangerous because operators and routing logic may trust the safer description while the implementation performs additional side effects and reaches beyond the approved use case.
The document simultaneously states there is no network activity and requires online official-doc verification, creating a materially false assurance about execution behavior. In a security-sensitive agent environment, false assurances about side effects are dangerous because they undermine policy enforcement, auditing, and user consent.
The skill explicitly claims it is 'answers only' and performs zero cloud/API calls, but later mandates runtime online verification against the OSS help center. That contradiction can mislead users and security controls into permitting execution under a no-network assumption when the skill actually performs outbound requests.
The skill declares itself read-only and tightly scoped, but the content indicates capabilities that can write locally and make network requests without declaring an explicit tool scope. That weakens reviewability and can let an agent invoke side effects the manifest does not transparently authorize, increasing the chance of unintended exfiltration or persistence.
The network-based documentation lookup expands the skill from local diagnosis into external retrieval without a clear necessity tied to the stated function. Even if the target is official docs, this adds exfiltration surface, dependency on external content, and non-deterministic behavior that is inconsistent with a supposedly self-contained diagnostic skill.
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.
## Credential handling
Never ask the user for, read, print, or forward any AccessKey, secret, or
STS token. The diagnosis input is limited to: tool name, error text, EC
code, symptom, endpoint, and version — all non-sensitive strings. The
embedded config template contains placeholders only.
The module performs outbound HTTP requests to a public documentation site and writes a persistent cache under the user's home directory, which conflicts with the skill's declared 'answers only' and no-external-action behavior. This creates a trust-boundary violation: operators may enable the skill expecting no network or filesystem side effects, while it actually exfiltrates user question text indirectly via doc lookups and mutates local state.
The embedded topic table and consultation signals broaden the skill beyond OSS client-tool diagnosis into SDK, pricing, and general configuration guidance, undermining the documented scope restrictions. Scope expansion is dangerous because it can cause the agent to answer out-of-scope questions with fetched external material, bypassing policy expectations and increasing the chance of unsafe or incorrect assistance.
The embedded least-privilege policy template grants oss:PutObject and oss:DeleteObject even though the skill is described as read-only diagnosis. In an agent setting, templates are often copied verbatim into customer guidance, so this can cause privilege escalation by encouraging users to grant write/delete access that is unnecessary for troubleshooting.
The catalog includes endpoint/region mismatch guidance even though the skill metadata explicitly says not to use this skill for endpoint selection. That mismatch weakens safety boundaries and can cause the agent to answer out-of-scope networking/addressing questions, potentially giving incorrect guidance in cases that should be handed off to a different diagnostic flow.
The manifest describes this skill as answering OSS client tool troubleshooting questions using embedded knowledge and explicitly frames it as diagnosis/checklist guidance. The code introduces a second capability that verifies the customer's wording against official OSS docs via _doc_lookup.lookup_config_topic, which is a distinct behavior not reflected in the manifest description and goes beyond the stated diagnosis-only matching flow.
Skill's behavior or capabilities extend beyond its stated purpose. Scope creep allows an agent to perform actions unrelated to its documented functionality, increasing the attack surface.
| EC code | Meaning | Action |
| --- | --- | --- |
| `0003-00000001` | Two official causes: (a) the identity behind the credential lacks permission on this Bucket/Object; (b) the AccessKey ID or the signature is incorrect, so authentication failed. It is NOT limited to a platform-side security policy | Check the AK/SK first (typo, deleted, rotated, wrong account, wrong signature version), then review the RAM/Bucket Policy authorization for the accessed resource |
| `0003-00000101` | Denied by a customer-defined Bucket Policy | Review policy rules (Principal/Action/Resource/Condition) vs the accessed ARN |
| `0003-00000301` | STS session-policy intersection: effective permission = role permissions ∩ AssumeRole session Policy (ticket case: AliyunOSSFullAccess role still denied because the session Policy lacked oss:ListObjectsV2) | Add the missing action to the session Policy as well |
Skill's behavior or capabilities extend beyond its stated purpose. Scope creep allows an agent to perform actions unrelated to its documented functionality, increasing the attack surface.
| EC code | Meaning | Action |
| --- | --- | --- |
| `0003-00000001` | Two official causes: (a) the identity behind the credential lacks permission on this Bucket/Object; (b) the AccessKey ID or the signature is incorrect, so authentication failed. It is NOT limited to a platform-side security policy | Check the AK/SK first (typo, deleted, rotated, wrong account, wrong signature version), then review the RAM/Bucket Policy authorization for the accessed resource |
| `0003-00000101` | Denied by a customer-defined Bucket Policy | Review policy rules (Principal/Action/Resource/Condition) vs the accessed ARN |
| `0003-00000301` | STS session-policy intersection: effective permission = role permissions ∩ AssumeRole session Policy (ticket case: AliyunOSSFullAccess role still denied because the session Policy lacked oss:ListObjectsV2) | Add the missing action to the session Policy as well |
The module docstring frames the file as runtime official-doc verification for the client-tools diagnosis skill, implying alignment with that limited tool-failure purpose. However, the actual matching logic includes SDK and broad consultation/billing signals, which contradicts the documented client-tool-focused intent rather than merely omitting detail.
SQP-3 applies to all file types and covers language/locale policy violations in natural-language content. Here, the file points only to zh-language documentation and gives no indication that users may choose another language or that the scope is intentionally limited to Chinese-language support, which can amount to an implicit forced locale.
The comment says a failed assertion means the script must not emit a diagnosis, implying a deliberate safety gate. In practice this is enforced only through Python assert statements, which are stripped when optimization is enabled, so the documented intent about guaranteed blocking behavior is stronger than what the code actually ensures.
No suspicious patterns detected.