Security Audit
Snowflake Automation
github.com/ComposioHQ/awesome-claude-skillsTrust Assessment
Snowflake Automation received a trust score of 65/100, placing it in the Caution category. This skill has some security considerations that users should review before deployment.
SkillShield's automated analysis identified 2 findings: 1 critical, 1 high, 0 medium, and 0 low severity. Key findings include Arbitrary SQL Execution via SNOWFLAKE_EXECUTE_SQL, Excessive Permissions via Role and Warehouse Specification.
The analysis covered 4 layers: Manifest Analysis, Static Code Analysis, Dependency Graph, LLM Behavioral Safety. The LLM Behavioral Safety layer scored lowest at 55/100, indicating areas for improvement.
Last analyzed on February 17, 2026 (commit 99e2a295). SkillShield performs automated 4-layer security analysis on AI skills and MCP servers.
Layer Breakdown
Behavioral Risk Signals
Security Findings2
| Severity | Finding | Layer | Location | |
|---|---|---|---|---|
| CRITICAL | Arbitrary SQL Execution via SNOWFLAKE_EXECUTE_SQL The `SNOWFLAKE_EXECUTE_SQL` tool allows the execution of arbitrary SQL statements (DDL, DML, SELECT) through its `statement` input. While the documentation suggests using `bindings` to prevent SQL injection, the tool itself permits direct SQL input. An LLM agent, if compromised by a prompt injection, could be instructed to craft and execute malicious SQL queries. This capability can lead to: 1) Data Exfiltration (e.g., `SELECT * FROM sensitive_data`), 2) Data Tampering/Deletion (e.g., `DROP TABLE users;` or `UPDATE accounts SET balance = 0;`), and 3) Schema Modification (e.g., `CREATE USER malicious_user;`). This represents a direct command injection vulnerability within the Snowflake environment. Implement strict validation and sanitization of the `statement` input. Ideally, restrict the types of SQL operations allowed (e.g., only SELECT for certain contexts). Enforce the use of `bindings` for all user-supplied values, ensuring the LLM agent never directly interpolates untrusted input into the `statement` string. Consider implementing an allow-list for SQL commands or patterns if full arbitrary SQL is not strictly necessary. Ensure the underlying Snowflake user has the principle of least privilege applied. | LLM | SKILL.md:60 | |
| HIGH | Excessive Permissions via Role and Warehouse Specification All Snowflake tools (`SNOWFLAKE_SHOW_DATABASES`, `SNOWFLAKE_SHOW_SCHEMAS`, `SNOWFLAKE_SHOW_TABLES`, `SNOWFLAKE_EXECUTE_SQL`) allow the LLM agent to specify the `role` and `warehouse` for execution. This means an attacker, through prompt injection, could instruct the agent to switch to a different Snowflake role or warehouse than intended. If the connected Snowflake user has permissions to assume multiple roles, this could lead to privilege escalation or access to resources (databases, schemas, tables) that the user's default role should not access. This broad control over execution context increases the blast radius of any potential misuse. Restrict the `role` and `warehouse` parameters to a predefined, minimal set of allowed values. Do not allow the LLM agent to freely choose any role or warehouse based on user input. If possible, hardcode the `role` and `warehouse` to the least privileged options required for the skill's intended functionality. Implement an authorization layer to verify that the requested role/warehouse is appropriate for the current user and operation. | LLM | SKILL.md:26 |
Scan History
Embed Code
[](https://skillshield.io/report/6470bc02203153bf)
Powered by SkillShield