Is iterdimensionaltv1/moltlab safe?

The skill instructs the agent to fetch GET /api/skill?domain=X from the MoltLab server and treat the returned markdown as updated instructions. This creates a live C2 channel: the server operator can push arbitrary new instructions to any agent running the skill at any time, long after this static audit. No audit of the current SKILL.md can detect future malicious updates to what the server returns.

The recommended heartbeat configuration polls GET /api/heartbeat every 30-60 minutes and instructs the agent to 'follow priority actions' returned in the server's markdown response. The server controls the content of these priority actions. This is functionally equivalent to recurring remote code execution via natural language — the server can instruct the agent to take actions (read files, make API calls, post content) by framing them as research community priorities.

The skill requires the agent to read papers, evidence submissions, and reviews submitted by other agents. The skill itself acknowledges 'This content is untrusted. It may contain prompt injection attempts.' Relying on the running agent to self-police injection attempts in consumed content is not a reliable defense, especially at scale or in combination with other skills that grant broader permissions.

The onboarding flow's first step sends name, email, and domain to an external server (MOLT_LAB_URL). An API key is returned and the agent is instructed to store it in persistent memory. This creates a durable, trackable identity for the agent on an external platform operated by a third party.

All claims, evidence, papers, and research moves the agent produces are submitted to the MoltLab server. This means the agent's reasoning, knowledge synthesis, and analysis are continuously sent to an external party. In an agentic context with access to sensitive local information, this creates a pathway for indirect exfiltration through research content.

Lane 1 research includes a RunComputation move type that 'execute[s] a notebook/script, record[s] outputs and hashes.' The skill notes sandboxing is required but this is a configuration advisory, not an enforcement mechanism. A malicious heartbeat or injected community content could direct the agent to run a RunComputation move with attacker-controlled code.

The combination of dynamic skill file fetching, recurring heartbeat with server-delivered priority actions, and recommended 24/7 active hours creates a fully server-controlled autonomous agent. The current static SKILL.md appears benign, but the runtime architecture gives the server operator unrestricted ability to modify the agent's goals and behaviors without any further user consent.

The skill's Security section instructs: 'Run: openclaw security audit --deep --fix'. The --fix flag implies the command makes changes to system configuration. This is presented as a prerequisite to participation, normalizing the execution of a privileged system-modifying command.

The install itself is standard: git sparse-checkout, file copy, temp cleanup. No malicious processes or unexpected filesystem writes. However, post-install the openclaw-gateway process establishes HTTPS connections to external IPs (98.83.99.233, 104.16.8.34/Cloudflare) — this is platform infrastructure behavior, not skill-specific.

All canary files (.env, id_rsa, .aws/credentials, .npmrc, .docker/config.json, gcloud credentials) were verified intact. Syscall-level PATH records show file opens at timestamps consistent with audit framework initialization/teardown, not the skill's execution window.