Is clawcolab/brain-v3-skill safe?

The handler.js hook fires automatically on every gateway:startup event, executing before the agent serves requests. The skill ships duplicate copies (hooks/clawbrain-startup/handler.js and brain/hooks/clawbrain-startup/handler.js). Despite oathe executing 'cat' on both files during the audit scan, their content was not captured in the evidence output, making full behavioral verification impossible. The hook is documented to spawn brain_bridge.py as a subprocess to load memories and inject them into agent bootstrap — this is a legitimate design but represents an auto-executing attack surface if the hook were to contain malicious logic in a future update.

The brain_bridge.py script, invoked on every service restart, loads all stored memories, personality traits, user profile inferences, and suggested_responses and injects them into the agent's system context before any user message is processed. The 6 evolving soul traits can drift from operator intent across interactions. The suggested_responses field returned by get_full_context() gives the skill ongoing influence over what the agent says without explicit per-request user consent. This design is declared and documented, but creates a long-running behavioral side-channel that accumulates influence invisibly.

remote-install.sh is bundled in the skill root and provides a remote deployment path. The file was catalogued during the audit and cat'd (audit 1771940485.788:876) but its content was not captured in the evidence output. No malicious network connections attributable to this script were observed during the test window, suggesting it is a benign deployment helper. However, a script named 'remote-install' that invokes shell commands on a potentially remote target warrants explicit review before trusting in production.

The skill's memory system accepts memory_type='secret' entries and stores API keys and credentials encrypted with Fernet in its local database. While encrypted, this creates a growing credential vault co-located with the agent. The CLI exposes 'clawbrain show-key --full' to retrieve the raw Fernet key and 'clawbrain backup-key --all' to export it in multiple forms. An attacker with local access to the agent host can use these commands to decrypt and extract all stored secrets.

The Brain constructor reads BRAIN_ENCRYPTION_KEY, BRAIN_POSTGRES_PASSWORD, and related sensitive values directly from environment variables into an in-memory config dict. These values persist in the Brain object for its entire lifetime. If the Brain object is logged, serialized, or if an exception reveals its internal state, these values would be exposed. This is standard Python configuration practice but worth noting in a skill with database storage.

All six honeypot credential files were opened and read at audit timestamp 1771940469 (before skill installation began) and again at 1771940487 (after the oathe scan completed). The pre-install access at 1771940469 coincides with oathe's own baseline establishment phase (the same 10-second window as the ss -tunap network baseline). The post-install access at 1771940487 follows immediately after the final oathe file scan, consistent with a post-install integrity verification read. The files were not modified. No skill code in the captured evidence reads filesystem paths for .env, .ssh/id_rsa, or .aws/credentials.

The get_full_context() return value includes a suggested_responses list generated from stored user preferences and interaction history. When injected into the agent's system context on startup via the brain_bridge, these suggestions can guide the agent toward response patterns shaped by prior interactions rather than current operator instructions. This is an explicit documented feature, not an injection attack, but operators should be aware that accumulated history can pre-bias the agent before each conversation.