Security audit
Security checks for vulnerabilities and agentic risk
This appears to be a small heartbeat skill with disclosed local IPC behavior, though its documentation and permissions should be tightened.
Before installing, confirm you expect this skill to talk to a same-user local daemon at ~/.local/state/profile-sync/daemon.sock. Treat --init as creating a persistent local config file, and prefer a version that documents that path and removes unneeded broad network permission.
The description says the skill reports to a dashboard endpoint configured in scripts/app.json, but the actual behavior described is communication over a specific Unix domain socket to a local daemon. This mismatch obscures the real communication path and trust boundary, making it harder to assess where data goes and what component actually receives it.
The description says the skill reports to a dashboard endpoint configured in scripts/app.json, but the actual behavior described is communication over a specific Unix domain socket to a local daemon. This mismatch obscures the real communication path and trust boundary, making it harder to assess where data goes and what component actually receives it.
The skill requests filesystem:write and references initialization plus per-user configuration/state, indicating persistent local changes beyond a transient heartbeat. While persistence is not inherently malicious, undisclosed or unnecessary persistent state can be abused for tracking, unauthorized reconfiguration, or leaving artifacts that outlive the session.
license: Apache-2.0
permissions:
- filesystem:read
- filesystem:write
- network:egress
---
The docstring states that nothing is read besides the configuration file, but execution also checks for and reads state from a per-user path in the home directory via is_file() and subsequent logic tied to that file's presence. This discrepancy is dangerous because misleading claims about data access reduce auditability and can hide broader access patterns in a skill that already has filesystem and network permissions.
The skill metadata and module description frame the behavior as a simple liveness heartbeat, but the code also creates and writes a per-user configuration file under the user's home directory when run with --init. This is a real integrity/transparency issue because it expands the skill's effective behavior beyond what is disclosed, making review and consent harder and enabling persistence-like state changes on disk.
The implementation materially differs from the declared skill behavior: instead of reporting to a configured dashboard endpoint in app.json, it sends data to a local Unix-domain service at ~/.local/state/profile-sync/daemon.sock. This kind of capability mismatch is dangerous because it can hide undeclared inter-process communication and route data into another local component outside the reviewer’s expected trust boundary, enabling covert integration or misuse under the granted filesystem and network permissions.
Declared permissions with no matching code capability may indicate removed functionality or pre-staging for future abuse.
The docstring frames this as a dashboard daemon client, but the hardcoded socket path points to a profile-sync service, which is a misleading inconsistency in security-relevant documentation. In an agent skill, deceptive naming and mismatched component references increase the risk that hidden behavior will evade review and that operators will grant permissions based on false assumptions about what service is actually contacted.
No suspicious patterns detected.