Security audit
Security checks for vulnerabilities and agentic risk
The skill is mostly a coherent OSS error-diagnosis tool, but it contradicts its offline/no-write promises by performing online documentation lookups and writing a persistent cache.
Review this skill before installing in restricted or privacy-sensitive environments. It appears not to collect credentials, mutate OSS resources, or execute remote code, but users should know that some question-based runs can contact help.aliyun.com and write a local documentation cache despite multiple offline-only claims.
scripts/_doc_lookup.py:48Undisclosed Outbound Network Access and Persistent Cache Writes Contradict the Declared Offline Security Posture
The skill claims narrow scope around OSS transfer error-code diagnosis, but it also performs external doc lookup, handles sibling-skill routing, and supports broader consultation-style questions. Scope expansion increases the chance that unrelated user input is sent externally or that the skill is invoked for cases outside its reviewed threat model.
The skill claims narrow scope around OSS transfer error-code diagnosis, but it also performs external doc lookup, handles sibling-skill routing, and supports broader consultation-style questions. Scope expansion increases the chance that unrelated user input is sent externally or that the skill is invoked for cases outside its reviewed threat model.
The skill says it needs no credentials and cannot access resources remotely, but elsewhere claims it can list visible buckets and offer only resources the credential can see. This contradiction suggests either undocumented credential use or inaccurate documentation; in either case, it creates a serious risk of surprise data access and privilege misuse.
The file header and module documentation explicitly assert that the script performs no network calls, yet later code introduces a remote lookup workflow. Misrepresenting execution behavior is security-relevant because operators, orchestrators, or policy engines may permit this skill in restricted environments based on those statements, leading to unintended egress and trust-boundary bypass.
The skill declares no explicit tool scope even though its behavior implies shell, filesystem, and network capabilities. Missing scope boundaries can cause the agent runtime to grant broader privileges than users expect, increasing the blast radius if the skill is misused or the backing script is compromised.
The manifest advertises zero-cloud-API routing, but the body expands execution to online documentation verification. Even if this is not a cloud API call in the strict sense, it is still materially different runtime behavior that can affect privacy, reproducibility, and approval requirements.
The documentation asserts zero network/API use, yet later requires online official-document verification through a runtime lookup module. Contradictory safety claims undermine operator trust and can lead users to provide sensitive incident details believing they remain local, when they may be transmitted over the network.
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: error code, HTTP status,
RequestId, bucket name, and operation type - all non-sensitive strings.
The manifest describes a diagnosis skill centered on routing OSS transfer error codes to root causes, which suggests local classification logic rather than runtime documentation retrieval. This file fetches remote content from help.aliyun.com and persists it under ~/.cache, adding operational behavior beyond straightforward error-code diagnosis.
The skill's stated purpose is to diagnose OSS upload/download error codes and explicitly exclude other domains, but this implementation downloads an external index and later document bodies at runtime. That capability is broader than a narrow diagnostic router unless the manifest explicitly states that official-doc verification over the network is part of the skill.
The script’s advertised trust boundary is 'zero cloud API / no network calls', but the doc-verification path can invoke _doc_lookup.lookup_config_topic, which is explicitly designed to fetch remote documentation and only degrades on failure. This creates a hidden outbound network capability that may leak user-supplied question text, violate sandbox or compliance expectations, and break consumers that relied on the no-network guarantee.
The natural-language trigger set for configuration consultation is defined entirely with Chinese phrases, which means Step B document-verification behavior is biased toward one language. The file does not indicate that the skill is intentionally Chinese-only or offer an explicit language/locale opt-in, so this creates a language-policy concern.
The instructions require running a Python script but do not clearly warn that official-document verification may perform live network access. Users and orchestrators may treat the skill as local-only and approve execution in contexts where outbound traffic is restricted or sensitive.
This section requires passing --question "<customer original wording>" into the verification flow and does not mention any user choice around language or locale handling. While subtle, this can amount to a locale/language policy issue because the skill fixes processing to the user's original wording with no opt-in or alternative when multilingual handling may matter.
This code embeds natural-language documentation and references that are predominantly fixed to Chinese-language official docs, and later comments explicitly privilege Chinese natural-language forms. That can amount to a locale/language policy issue because the skill content is biased toward a specific language without offering an explicit user choice or documenting a justified locale restriction.
No suspicious patterns detected.