Security audit
Security checks for vulnerabilities and agentic risk
This skill is a disclosed Philips Hue light indicator; it has some setup and credential-handling cautions but no artifact-backed malicious behavior.
Install only if you intend to let the assistant control a chosen Hue light. Protect the Hue config file because the username can control lights on your local network, prefer a user-owned PATH install over sudo where possible, and review any shell hook or automatic invocation before adding it to your profile.
The description frames the skill as a simple light-status indicator, but the documented behavior also includes bridge setup, network discovery/connection, and creation of a Hue API user. That is a meaningful expansion of capability into authentication and local-network interaction, which can mislead users and agents about the true security-sensitive actions the skill performs.
Skill enables autonomous high-impact decisions without human-in-the-loop verification. Critical operations (destructive commands, financial transactions, data deletion) should require explicit user confirmation.
## Why Use This?
- **Ambient awareness** — Know when your AI is working without checking screens
- **Flow state protection** — Visual indicator prevents interruptions during deep work
- **Satisfying completion** — Green light signals "ready for next task"
- **Conversation starter** — "My AI has a physical presence in my house"
Skill enables autonomous high-impact decisions without human-in-the-loop verification. Critical operations (destructive commands, financial transactions, data deletion) should require explicit user confirmation.
## Why Use This?
- **Ambient awareness** — Know when your AI is working without checking screens
- **Flow state protection** — Visual indicator prevents interruptions during deep work
- **Satisfying completion** — Green light signals "ready for next task"
- **Conversation starter** — "My AI has a physical presence in my house"
Commands invoke sudo or root privileges. Verify this elevated access is necessary and justified.
cd philips-hue-thinking
# Add to PATH
sudo cp hue /usr/local/bin/
sudo chmod +x /usr/local/bin/hue
# Or add to your shell profile
Commands invoke sudo or root privileges. Verify this elevated access is necessary and justified.
cd philips-hue-thinking
# Add to PATH
sudo cp hue /usr/local/bin/
sudo chmod +x /usr/local/bin/hue
# Or add to your shell profile
The README says the assistant will 'automatically' use the skill during long tasks but does not define explicit user-consent, trigger conditions, or scope limits. That can lead to unreviewed command execution in agent contexts, increasing the chance of unintended device actions or abuse if an attacker can influence prompts or workflows.
The skill clearly instructs the agent/user to execute shell commands (git clone, cp, chmod, source, and hue ...) yet the manifest does not declare any tool scope or allowed-tools boundary. That omission weakens reviewability and policy enforcement, making it easier for an agent to invoke shell actions without explicit consent or least-privilege constraints.
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.
#!/bin/bash
# Quick Hue setup - run this AFTER pressing the bridge button
curl -X POST http://192.168.1.151/api -d '{"devicetype":"clawdbot#hue"}'
The README shows that bridge IP and API username are stored in a local config file, but it does not clearly warn users that these are sensitive connection details. While not a secret on the level of a password in all contexts, exposing or mishandling the API username can allow unauthorized control of Hue devices on the local network.
The README documents storing a Hue API username in ~/.config/philips-hue/config.json but does not warn that this value is a credential for controlling smart-home devices. Users may treat it as harmless metadata, leading to insecure file permissions, accidental sharing, or inclusion in backups/repos that expose control of the Hue bridge.
The script appends a user-specific directory to PATH in a shell startup context, which changes command resolution for the entire shell session without warning or validation. This can cause unintended execution of binaries from that directory, and if that location is writable or later compromised, common commands or the hue command could be hijacked persistently.
No suspicious patterns detected.