T08 · Insecure Dependencies
- Location
README.md:78- Finding
Unpinned Third-Party Dependency Installation
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
The skill is a coherent TOS Vectors helper, but it enables cloud data deletion, IAM policy changes, credential-backed network use, and unpinned package installation without enough scoping or warnings.
Install only in an isolated environment, pin and verify the `tos` SDK version, use least-privileged TOS credentials, and require explicit confirmation before deletes or policy changes. Treat retrieved vector metadata as untrusted before sending it to any LLM, especially if the index may contain private or third-party content.
README.md:78Unpinned Third-Party Dependency Installation
WORKFLOWS.md:181Indirect Prompt Injection Through Untrusted Retrieved Vector Metadata
The markdown explicitly advertises deletion capabilities for vector buckets and vectors, including batch delete, but does not include any caution about irreversible data removal or the need to confirm targets before use. Under the markdown-file criteria, descriptions that omit warnings about behaviors affecting user data should be flagged.
This markdown file documents bucket deletion through delete_vector_bucket but only states the technical prerequisite that the bucket be empty. It does not warn users that the operation is destructive and may permanently remove storage resources and associated configuration, which is the kind of system-impacting behavior that should be disclosed in markdown skill documentation.
The delete_index section instructs users how to delete a vector index but does not disclose the destructive impact of removing the index and its contents. For markdown documentation, destructive operations affecting user data should include a clear warning so users understand the risk before invoking them.
The delete_vectors section explains how to delete vectors by key but provides no user-facing warning about permanent data removal. Because this behavior directly affects stored user data, the markdown should explicitly disclose the destructive nature of the operation.
The skill reads sensitive credentials from environment variables and demonstrates network-capable client initialization, but it does not declare any explicit tool scope or permissions boundary. In an agent setting, this can cause the skill to be invoked with access to secrets or execution capabilities that are broader than intended, reducing auditability and increasing the chance of unauthorized external actions.
The description says to use the skill for broad categories like embeddings, semantic search, RAG systems, recommendation engines, or whenever the user mentions vector databases or similarity search. This wide trigger surface can cause the agent to select the skill for many generic AI/ML tasks, unnecessarily exposing credentials and enabling write/delete operations in contexts where the user may only want conceptual guidance.
The bucket deletion example shows a destructive operation with no warning, confirmation step, or emphasis that the bucket must be empty and that deletion is irreversible. In an agent-assisted workflow, examples often become copied actions, so this increases the risk of accidental data loss or service disruption.
The skill includes code to delete vectors by key without any accompanying warning about irreversibility, verification of the target set, or recovery guidance. Because this skill manages production-like data stores, normalizing deletion in examples can lead to unintended removal of indexed content and degraded downstream search or RAG behavior.
The RAG example sends both the user's question and retrieved document context to an external LLM service, which can expose sensitive or proprietary data if the indexed content contains private information. In a vector-search/RAG skill this is contextually plausible and common, but the lack of any warning, data-classification guidance, or redaction step increases the risk of inadvertent data disclosure.
The update workflow deletes existing vectors before inserting replacements, creating a destructive window where data may be permanently lost if the subsequent insert fails or is incomplete. In a data-maintenance skill this behavior is functionally relevant, but without warnings, backup guidance, or safer upsert/transactional patterns it can cause integrity and availability issues.
The module documentation presents this as a TOS Vectors search script, which implies searching with a meaningful embedding derived from the query. However, the implementation uses generate_dummy_embedding based on an MD5 hash repeated across all dimensions, which is only a demonstration placeholder and does not perform real semantic embedding generation.
No suspicious patterns detected.