Volcengine Skills

The script's help text says it normalizes only 'safe metadata', but the implementation also creates and persists a stable per-install client identifier and includes it in exported telemetry. Even if the ID is pseudonymous, it enables long-term correlation of events across runs and machines and is privacy-sensitive, so the description is materially misleading and reduces informed consent.

The skill explicitly tells the agent to never read ~/.volcengine/config.json because it contains long-lived credentials and session tokens, yet nearby documented helper behavior states that extension helpers may use that same file for credential fallback. This creates a contradictory policy boundary that can lead an agent or helper script to ingest sensitive local secrets indirectly, defeating the stated credential-safety guarantee and potentially exposing cloud credentials to tool output, logs, or unintended API calls.

The module advertises itself as a helper for selected extension APIs, but the registry includes clearly state-changing actions such as CreateVirtualNode, RegisterDomain, Start/Stop/RebootCloudServer, and other write/destructive operations. In an agent-skill context, misleading documentation lowers operator caution and increases the chance that automation invokes mutation-capable cloud actions under the assumption that the tool is informational only.

The playbook provides copy-pastable RLS policies that grant SELECT, INSERT, UPDATE, and DELETE to both anon and authenticated roles with USING (true) / WITH CHECK (true), which effectively makes the table world-writable through the API. Although the text includes a warning for private data, the example is still dangerous because it normalizes an insecure default and can be applied without any access scoping, leading to unauthorized data disclosure, tampering, or deletion.

The list-migrations action is documented and named as a read-only listing operation, but it actually executes CREATE SCHEMA IF NOT EXISTS and CREATE TABLE IF NOT EXISTS before selecting rows. In an automation or agent context, a caller expecting a harmless read can unintentionally modify the database, violating least surprise and bypassing read-only expectations.

The configuration enables a public container registry endpoint and then applies a 0.0.0.0/0 ACL, making the registry reachable from anywhere on the internet. Although the comment calls this temporary, Terraform does not enforce any expiry or cleanup, so the exposure can persist indefinitely and increase risk of unauthorized image discovery, pull attempts, or abuse if credentials are later leaked.

The variable description downplays the effect as only helping create a kubeconfig, but the code grants the specified IAM user the full vke:admin cluster role. This can cause operators to assign far broader privileges than intended, resulting in full cluster administrative access for the grantee.

The variable descriptions state the CR credentials are used only for pushing, but the same credentials are later embedded into a Kubernetes dockerconfigjson pull secret for runtime use. This misrepresents the credential scope and can cause operators to provide higher-privilege credentials than intended or mishandle secret lifecycle and rotation.

The endpoint service allows permit_account_ids = ["*"], which means any account can discover and request connectivity to the exposed PrivateLink service. Combined with auto_accept_enabled = true, this creates effectively unrestricted attachment to the service and can expose internal applications to unintended tenants or abuse.

The documentation shows setSchema('http') and setVerifySsl(false) as ordinary SDK configuration under a generic SSL/HTTP client section, without any warning that these settings disable transport security. Users may copy this example into production, enabling man-in-the-middle attacks, credential exposure, and tampering of API traffic.

The matrix classifies BatchGetSecretValue and GetSecretValue as read-only/diagnostic evidence, but these APIs can disclose plaintext secret material rather than mere metadata. In a troubleshooting skill, that framing can cause an agent to retrieve sensitive secrets automatically or unnecessarily, increasing the chance of credential exposure in outputs, logs, or intermediate context.

The KMS section explicitly lists BatchGetSecretValue and related secret-value retrieval operations as acceptable troubleshooting evidence, which normalizes access to sensitive secret contents. Because this skill is about security/KMS troubleshooting, the context makes the issue more dangerous: operators may trust the guidance and expose production secrets while investigating incidents.

The rule auto-directs the agent to load and follow Volcengine skills for broad categories like operating cloud resources, deploying apps, managing infrastructure, or generating SDK code. In an agent system, such wide matching can cause unintended skill activation on loosely related tasks, pulling in additional instructions or capabilities that were not specifically requested and increasing the chance of mis-scoped actions.

The trigger list includes very broad keywords such as generic mentions of Volcengine/火山 or any ve commands, plus environment variable names. This can overmatch benign text or unrelated command usage, causing the agent to invoke a cloud-operation skill unnecessarily and potentially exposing the workflow to unintended operational guidance or tool usage.

The trigger guidance says the repository should be prioritized when user messages contain broad keywords like “火山” or “volcengine”. This can cause the skill to activate in contexts where the user did not intend cloud-resource operations, increasing the chance of unnecessary credential access, irrelevant tool invocation, or unsafe cross-context behavior by an agent.

The trigger condition is broad enough to activate on generic references to Volcengine keywords, CLI commands, or environment variable names, which can cause this cloud-management skill set to engage in contexts where the user did not explicitly request operational actions. In an agent setting, unintended activation increases the chance of the model following deployment or infrastructure-management instructions and handling sensitive cloud context when a narrower informational response would be safer.

This file advertises multiple capabilities that can operate cloud resources, deploy applications, manage infrastructure, and access storage or databases, but it provides no safety framing about confirmation requirements, destructive actions, cost implications, or handling of secrets. In practice, that omission can normalize high-impact operations and make downstream skills easier to invoke without adequate user awareness or explicit consent.

The README explicitly recommends installation with --yes, which suppresses confirmation prompts for adding agent skills globally. In the context of agent/plugin installation, bypassing prompts reduces user awareness and increases the chance of unintentionally installing unreviewed or over-privileged content, especially since these skills can affect agent behavior across environments.

The hook uses a very broad matcher value of "Read" for a beforeReadFile trigger, which can cause the command to run on a wide range of file-read operations rather than a narrowly scoped subset. In this skill, that means an external shell script is invoked repeatedly during ordinary read activity, increasing the attack surface, causing unintended data exposure to the reporter script, and making the hook easier to abuse for surveillance or disruptive execution.

The PostToolUse matcher "Skill|Read" is broad enough to trigger on common read operations, not just the narrowly intended telemetry event of loading a Volcengine skill file. In this skill's context, that means telemetry can be sent for a wider set of user or agent file-access activity than described, increasing unintended data collection and privacy exposure.

This code silently spawns a detached subprocess and sends it a JSON payload containing the loaded skill path, along with the full parent environment, without any user-facing notice or consent check in this file. Even though the transmitted data is 'only' a file path, it can reveal repository layout, project names, usernames, or sensitive filesystem locations, and the inherited environment may also expose credentials or tokens to the child process.

The script reads the entire stdin payload, writes it to a temp file, and asynchronously exports it via a detached reporter without any user-facing notice or consent gate. In a hook context, stdin may contain prompts, command content, file paths, or other sensitive workspace data, so silent background telemetry materially increases data-exfiltration risk.

The code exports hook-derived metadata over the network to a remote telemetry endpoint without any interactive warning or explicit consent in the execution path. In a skill/hook context, hook payloads can reflect user actions, tool names, file paths, and skill identifiers, so silent outbound reporting creates a meaningful privacy and data-governance risk even if the payload is curated.

The reporter creates a persistent identifier under the user's home directory and reuses it across executions without user-facing disclosure. This enables cross-session tracking and linkage of activity over time, which is particularly sensitive in a developer tool or hook where users may not expect local tracking state to be created implicitly.

The script can directly execute write and destructive cloud API actions based only on --api and --params, with no confirmation gate, dry-run default, allowlist restriction, or user-facing risk warning. In an agent environment that automatically resolves credentials from env/CLI login state, this materially increases the chance of accidental or induced cloud state changes, service disruption, or unwanted resource creation using the operator's privileges.