hive-credentials
Audited by Socket on Mar 18, 2026
1 alert found:
Anomaly[Skill Scanner] System prompt extraction attempt All findings: [HIGH] skill_discovery_abuse: System prompt extraction attempt (SD002) [AITech 4.3] [HIGH] skill_discovery_abuse: System prompt extraction attempt (SD002) [AITech 4.3] The skill is functionally consistent with its stated purpose (interactive credential setup, validation, and secure local storage). I found no code-level indicators of obfuscation or direct exfiltration to unknown hosts; the main risk is an architectural/trust decision: the Aden sync flow centralizes credential management via a third-party (adenhq.com). If users trust Aden, the flows are reasonable and the secure-store guidance is good. If Aden or the ADEN_API_KEY is compromised, many provider credentials could be accessed. Additional operational cautions: avoid logging generated HIVE_CREDENTIAL_KEY, minimize writing long-lived keys to shell startup files, and warn users about exporting tokens into live shells. Overall this appears benign in intent but carries a moderate trust/operational risk due to the centralized Aden sync and persistence of encryption keys in shell profiles. LLM verification: This skill's stated purpose (discovering missing credentials and storing them in a local encrypted store) is coherent with most described capabilities. However, there are noteworthy security concerns: it encourages persisting sensitive keys (ADEN_API_KEY, HIVE_CREDENTIAL_KEY) into shell startup files (plain text), and it promotes using a third-party platform (Aden) as a central credential store/sync point without providing verification or warning about trusting that service. These behaviors incr