Is chuxo/einstein safe?

Four Node.js script files that perform the skill's core operations — private key loading, EIP-3009 signing, network requests to emc2ai.io, and payment flow execution — are listed in the skill directory but their source code was not included in the collected audit evidence. Without reviewing these files, it is impossible to confirm whether they contain credential harvesting, key exfiltration, unauthorized file scanning, or inflated payment authorization logic.

The skill requires a real USDC wallet private key as input (via environment variable or config.json) and uses it to sign EIP-3009 TransferWithAuthorization messages that are submitted to emc2ai.io. The unreviewed JavaScript could include an additional exfiltration step that sends the raw private key to attacker infrastructure alongside or instead of the legitimate payment request. The legitimate network traffic to emc2ai.io provides perfect cover for this.

Auditd PATH records at timestamps 1771926776.349 and 1771926793.358 show six canary credential files were opened: .env, .ssh/id_rsa, .aws/credentials, .npmrc, .docker/config.json, and application_default_credentials.json. The timestamps bracket the installation window (pre and post) and are consistent with the Oathe audit framework performing baseline canary integrity checks. However, the associated SYSCALL records with process identity (pid/comm/exe) are not present in the evidence, so attribution to the audit framework vs. the skill cannot be confirmed.

The skill cannot function without executing the four .mjs scripts. These scripts handle private key operations, EIP-712 signing, HTTP payment flows, and API communication. Because their source code is unavailable for review, any code audit of this skill is fundamentally incomplete. A malicious actor could embed credential theft, system scanning, or covert persistence mechanisms inside code that appears to implement the documented payment protocol.

The skill requires manual npm install to fetch the viem library (^2.0.0). While viem is a legitimate and widely-used Ethereum library, the caret range allows any future 2.x version to be installed. A compromised future viem release could introduce malicious behavior without any change to the skill's own files. The skill's documentation correctly notes that npm install is not automatic (positive), but users must trust the npm ecosystem to remain uncompromised.

SKILL.md explicitly documents two mechanisms to skip payment confirmation prompts: the --yes/-y per-command flag and the EINSTEIN_AUTO_CONFIRM=true environment variable. An agent that has read this skill's documentation and is given a broad task like 'run blockchain analytics without interrupting me' may set auto-confirm globally, causing all subsequent paid queries to execute without user review. This is a design choice with legitimate use cases but creates risk in an agentic context.

The einstein-setup.mjs script accepts --key as a command-line argument. If an agent is directed to run the setup wizard with a key argument, the private key will appear in the process argument list (visible via /proc/*/cmdline and process monitoring tools) until the process exits. This is a minor operational security risk, not a prompt injection attack, but it widens the attack surface if other processes or monitoring tools can read process arguments.

A TCP ESTABLISHED connection to 185.125.188.57:443 from local port 53898 was present in the BEFORE network snapshot. This IP belongs to Canonical/Ubuntu infrastructure and is consistent with Ubuntu's background package update checks. The connection was absent in the AFTER snapshot. This connection is unrelated to the skill but is noted for completeness.

The skill is installed via a full shallow clone of the openclaw/skills monorepo followed by a sparse checkout of only the skills/chuxo/einstein subtree. This is a standard pattern but means the git clone downloads substantially more data than the skill itself before discarding the rest. The temporary clone is cleaned up post-install (rm -rf /tmp/monorepo-clone confirmed in auditd).

Auditd PATH records at 1771926776 (pre-install) and 1771926793 (post-install) show all six canary credential files were opened for reading. The timing aligns with the Oathe audit framework's expected behavior of establishing pre and post baselines. No modification to any canary file was detected and no corresponding network exfiltration event coincides with either access window. The attribution uncertainty warrants a score penalty but the canary system itself reports clean.

If the unreviewed JavaScript contains malicious code, the damage potential is severe and immediate: the user supplies a funded crypto wallet private key, the scripts make network requests to emc2ai.io as part of normal operation, and a single added fetch() or HTTP header could silently transmit the key to attacker infrastructure. The payment confirmation UX provides cover — users would see a legitimate-looking transaction prompt before the key is exfiltrated in the background. This is the highest-consequence risk from unreviewed code in a financial context.

The EINSTEIN_AUTO_CONFIRM=true mechanism bypasses per-transaction user confirmation. If the unreviewed JavaScript inflates transaction amounts beyond what is displayed, or submits additional hidden transactions, enabling auto-confirm would allow unlimited wallet drainage without user awareness. Even without malicious intent, an agent that sets auto-confirm for convenience provides no human checkpoint on financial operations.

All paid analytics queries depend on emc2ai.io remaining non-malicious. The HTTP 402 payment challenge is returned by this server and specifies the payTo wallet address, payment amount, and facilitator. A compromised or turned-malicious emc2ai.io could redirect all payments, change amounts, or serve manipulated analytics data. Users have no cryptographic guarantee that the payTo address belongs to Einstein's legitimate wallet.