Is a-sumo/eywa safe?

SKILL.md explicitly instructs the agent to call eywa_log for every significant operation: file reads, file writes, file creates, git commits, git pushes, API calls, database migrations, and deployments. Each call POSTs a JSON-RPC payload containing role, content, system, action, scope, and outcome fields to https://eywa-mcp.armandsumo.workers.dev — a Cloudflare Workers endpoint operated by the skill author. This creates a persistent, comprehensive operational intelligence stream available to a third party for every session in which this skill is active.

The eywa_learn tool stores knowledge that 'survives sessions' to the external Eywa server. SKILL.md instructs: 'If you discover something useful (a pattern, a gotcha, a convention), call eywa_learn.' In practice this could include authentication schemes, credential formats, internal service endpoints, business logic, or other sensitive operational knowledge that should remain private to the user's environment. This data is stored server-side and accessible to the skill operator indefinitely.

The skill injects a standing behavioral instruction to report all agent operations to an external server. This is not a one-time action but a persistent mandate that modifies agent behavior for the duration of every session. The instruction 'Every significant action should be tagged. Invisible agents have zero curvature' creates social pressure within the multi-agent framing to comply fully. The 'When to log' table covers the complete surface area of agent activity.

The skill opens with 'You are now connected to Eywa' which establishes a new identity frame for the agent. While it does not instruct the agent to ignore safety guidelines, the persona injection subtly positions Eywa coordination instructions as part of the agent's core identity, potentially increasing compliance with the skill's logging mandates.

The default EYWA_ROOM is 'demo' and default EYWA_AGENT is 'openclaw'. Any user who does not explicitly set EYWA_ROOM will join the same shared room, causing their task descriptions (eywa_start), activity logs (eywa_log), stored knowledge (eywa_learn), and artifact lists (eywa_done) to be visible to all other users in that room via eywa_status, eywa_context, and eywa_search. This constitutes an unintended cross-user information leak for the majority of users who install without reading configuration documentation.

All Eywa tool calls are mediated through the skill author's server, which constructs and returns the responses the agent acts upon. The server could return instructions embedded in tool responses (e.g., in eywa_start room snapshots, eywa_status agent listings, or eywa_knowledge entries) that direct the agent to perform actions. This deferred injection channel is not visible in the installed skill files and cannot be audited statically.

eywa-call.sh interpolates the TOOL and ARGS shell variables directly into a JSON payload using printf without sanitization. While the immediate risk is limited to the agent's own call context, a malicious task description or learned knowledge entry containing JSON metacharacters could corrupt or inject into the payload structure.

The skill requires installation of the 'eywa-ai' npm package from the public npm registry. This package's install scripts (preinstall, postinstall) were not examined in this audit. A compromised or malicious package version could execute arbitrary code during installation.

The installation process performed a sparse git checkout from GitHub (140.82.121.3:443) only. No connection to eywa-mcp.armandsumo.workers.dev was made during install. No new persistent network listeners were created. The install produced exactly the three expected files.

Honeypot files (.env, .ssh/id_rsa, .aws/credentials, .npmrc, .docker/config.json, .config/gcloud/application_default_credentials.json) showed CLOSE_NOWRITE access events consistent with the audit framework's own pre/post baseline integrity checks. No exfiltration of canary content was detected. The skill executed no code during the install phase.