Back to skill

Security audit

alibabacloud-agentloop-management

Security checks for vulnerabilities and agentic risk

Overview

The skill is mostly coherent for Alibaba Cloud AgentLoop operations, but it needs review because it can modify cloud/application resources and some install and AI-data handling paths are under-scoped or under-disclosed.

Review this before installing if it will run with real Alibaba Cloud credentials. Use a least-privilege Aliyun profile, avoid the curl-to-bash fallback, approve plugin or CLI installs separately, and do not run AI pipeline nodes on secrets, PII, prompts, tool arguments, or sensitive logs unless that processing is allowed. Treat global dedup as persistent Dataset state, and require explicit previews before cloud mutations or K8s/application changes.

Vulnerability Patterns
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
  • MCP Least PrivilegeUnderdeclared Capability, Wildcard Permission, Missing Permission Declaration
  • MCP Tool PoisoningHidden Instructions, Unicode Deception, Parameter Description Injection
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
  • Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access
Findings (36)

Lp3

Medium
Category
MCP Least Privilege
Confidence
95% confidence
Finding
The skill routes users into operational playbooks that explicitly rely on shell execution, environment variables, and file read/write behavior, yet the skill metadata declares no permissions. This creates a capability-transparency gap: reviewers and runtime policy systems may under-scope the skill while it still instructs actions that can access credentials, modify local files, and invoke cloud APIs against Alibaba Cloud resources.

Intent-Code Divergence

Medium
Confidence
95% confidence
Finding
The documentation is internally inconsistent: it states the transformation is 1:1 with unchanged row count, but also says rows with NULL in the input field are dropped. In a data pipeline and observability context, this can cause operators to make unsafe assumptions about data completeness, leading to silent omission of records in downstream analytics, evaluation, or indexing.

Intent-Code Divergence

Medium
Confidence
92% confidence
Finding
The effect preview shows all rows receiving embeddings and claims unchanged row count, which conflicts with the documented NULL-drop behavior. Misleading examples are dangerous because users often copy them into production assumptions, potentially masking data loss and causing incomplete embeddings, skewed retrieval, or inaccurate evaluation results.

Intent-Code Divergence

Medium
Confidence
96% confidence
Finding
The documentation states the operator is a 1:1 row-preserving transformation, but later notes and the SQL template show rows with NULL input are filtered out. This mismatch can cause silent data loss in pipelines, leading users to make incorrect assumptions about dataset cardinality, downstream joins, evaluation metrics, or audit completeness.

Intent-Code Divergence

Low
Confidence
90% confidence
Finding
The effect preview claims the row count is unchanged for every row, which contradicts the documented and implemented NULL-row filtering behavior. This can mislead users during pipeline design and validation, especially when sample data shown in docs lacks NULLs and hides the edge case.

Intent-Code Divergence

Medium
Confidence
95% confidence
Finding
The SQL template selects `m2.*` from `_cl_base`, which includes the synthetic internal identifier `__cl_rid`, even though the documentation states that this field is only an internal byproduct and may be stripped. This creates an unintended metadata exposure and breaks the documented output contract; while not typically enabling direct code execution or privilege escalation, it can leak internal implementation details and cause downstream consumers to rely on or misuse an internal identifier.

Intent-Code Divergence

Medium
Confidence
94% confidence
Finding
The public documentation promises a 1:1 transformation that preserves upstream columns and adds only `__cluster_id`, but the implementation template would also emit `__cl_rid`. This mismatch is a real schema-integrity issue because internal identifiers can leak into user-visible results, creating confusion, accidental dependency on unstable fields, and potential disclosure of processing internals in an observability/data-pipeline context.

Missing User Warnings

Medium
Confidence
91% confidence
Finding
The AI-processing examples show `llm-call` and `agentic-call` usage without any warning that prompt templates and selected row fields may be transmitted to external model or agent services. In an observability and dataset-management context, users may include logs, questions, inputs, or outputs containing sensitive data, so omission of disclosure and guidance can lead to accidental data exfiltration to third-party or cross-boundary processing systems.

Missing User Warnings

Medium
Confidence
94% confidence
Finding
The documentation explicitly states that per-row field values are extracted, rendered into prompts, and sent to a digital employee, but it does not clearly warn users that row data may leave the immediate pipeline context and be transmitted to an external agent/service. In an observability/onboarding platform, those fields can include sensitive operational data, customer identifiers, secrets, or incident details, so lack of disclosure and guidance increases the risk of unintended data exposure.

Missing User Warnings

Low
Confidence
86% confidence
Finding
The documentation describes `global = true` as comparing records against Dataset history and keeping only genuinely new records, but it does not clearly warn users that this mode reads prior dataset contents and can silently filter out records based on historical state. In an observability/data-pipeline context, that omission can cause unintended cross-batch data suppression, privacy/governance surprises, or operator confusion about why records disappear.

Missing User Warnings

Medium
Confidence
85% confidence
Finding
The documentation promotes `global` cross-batch deduplication against historical dataset contents without clearly warning that new rows may be silently discarded based on prior ingested data. In an observability/data-pipeline context, this can cause unintended data loss, audit gaps, or biased downstream evaluation because operators may not realize that records are being removed due to historical matches rather than only current-batch duplicates.

Missing User Warnings

Medium
Confidence
88% confidence
Finding
The documentation instructs users to perform semantic dedup by generating embeddings from text and optionally comparing against historical dataset vectors, but it omits any warning that submitted text may be processed by an AI model and could expose sensitive content. In an observability/data-pipeline context, users may run logs, tickets, prompts, or multilingual text that can contain secrets or personal data, so missing privacy guidance can lead to unintended disclosure or non-compliant processing.

Missing User Warnings

Medium
Confidence
93% confidence
Finding
The node description says it calls an AI model for embedding generation but does not clearly warn that text contents are transmitted to a remote inference service. In an observability and dataset-management skill, text fields may contain logs, prompts, application data, or other sensitive content, so omission of a disclosure can lead to unintended data exposure, compliance issues, and privacy violations.

Missing User Warnings

Medium
Confidence
94% confidence
Finding
The documentation notes that NULL rows are dropped but does not present this as a prominent data-loss warning. In pipelines used for onboarding applications, dataset preparation, and evaluation, silent row removal can corrupt metrics, break alignment between datasets, and create hard-to-detect integrity issues in downstream processing.

Missing User Warnings

Medium
Confidence
95% confidence
Finding
The documentation explicitly describes sending per-row column values into an LLM prompt, but it does not warn that row data may be transmitted to an external model provider or otherwise leave the user's trust boundary. In an observability and dataset-management context, those columns may contain sensitive operational, customer, or proprietary data, so omission of this warning can lead users to unintentionally exfiltrate data through normal product use.

Missing User Warnings

Medium
Confidence
87% confidence
Finding
The examples normalize and aggregate user questions, model outputs, and tool arguments, then pass them to downstream llm-call evaluation without any warning about secrets, personal data, or tenant-sensitive content. In an observability/onboarding context, logs and tool arguments commonly contain API keys, tokens, internal queries, or user data, so this documentation could lead operators to unintentionally exfiltrate sensitive material to an LLM-based processor.

Missing User Warnings

Medium
Confidence
92% confidence
Finding
The documentation instructs users to send row data to a remote digital employee for per-row conversations, but it does not clearly warn that input fields may be transmitted to an external service and processed outside the immediate pipeline context. In an observability/onboarding workflow, rows can contain sensitive operational data, hostnames, metrics, incident details, or customer-linked content, so omission of a privacy/transmission warning can lead to unintentional data disclosure.

Missing User Warnings

Medium
Confidence
93% confidence
Finding
The documentation states in user-facing examples and design notes that global mode compares against dataset history and writes surviving fingerprints into the Dataset, but it does not clearly foreground this as a persistent state-changing side effect. In a pipeline/operator context, users may reasonably expect deduplication to be read-only; silent writes can cause unexpected data retention, cross-run state contamination, and privacy/compliance issues if fingerprints derived from user text are stored without explicit notice or consent.

Missing User Warnings

Medium
Confidence
90% confidence
Finding
The documented global mode performs a persistent cross-batch write via `simhash_dataset_upsert`, storing deduplication fingerprints in a Dataset, but the user-facing documentation does not clearly foreground that enabling `-global` causes stateful retention beyond the current batch. This can lead users to unintentionally persist derived data across runs, creating privacy, data-governance, and surprise side-effect risks, especially in observability or evaluation pipelines handling sensitive text.

Missing User Warnings

Medium
Confidence
91% confidence
Finding
The documentation describes global deduplication as comparing against a Dataset, but the implementation spec states that it also writes new embedding vectors into that Dataset automatically. If users enable global mode without realizing it mutates persistent state, they may unintentionally store derived representations of potentially sensitive text, affecting privacy, retention, compliance, and reproducibility.

Missing User Warnings

Low
Confidence
78% confidence
Finding
The operator outputs `__dedup_emb`, an embedding vector derived from user text, without any warning about downstream exposure or handling expectations. Although embeddings are not raw text, they can still be sensitive derived data and may be logged, exported, or reused in later pipeline stages beyond what users expect.

Missing User Warnings

Medium
Confidence
92% confidence
Finding
The documentation describes global deduplication as incrementally operating against a Dataset, but the examples and nearby prose do not prominently warn that enabling `-global` also persists new data into that Dataset. In an observability/data-pipeline context, silent persistence can cause unintended retention of sensitive text, cross-batch data mixing, and compliance issues when users assume the operator is read-only.

Missing User Warnings

Medium
Confidence
94% confidence
Finding
The semantic dedup operator sends field contents to `embedding({{field}}, '{{model}}')` with remote functions enabled, but the documentation does not clearly warn that text may be processed by a model service outside the immediate query engine. In this skill's observability/dataset-management context, users may run the operator on logs, prompts, or application data containing secrets or personal data, creating privacy, data-transfer, and regulatory exposure.

Missing User Warnings

Medium
Confidence
94% confidence
Finding
The design notes disclose that embedding generation is a remote function call involving network I/O and GPU inference, but the user-facing sections do not warn that input text may be transmitted to a remote service. In an observability/data-platform context, users may embed logs, prompts, outputs, or other potentially sensitive text, creating confidentiality and compliance risks if remote processing is not clearly disclosed.

Missing User Warnings

Medium
Confidence
92% confidence
Finding
The operator documentation explicitly describes sending selected row fields to an LLM for inference, but it does not provide a clear user-facing warning about privacy, data handling, or external transfer implications. In an observability/data-pipeline context, those fields may contain logs, prompts, outputs, or other sensitive tenant data, so silent remote transmission creates real confidentiality and compliance risk.

Static analysis

No suspicious patterns detected.