xenodia
WarnAudited by ClawScan on May 10, 2026.
Overview
The Xenodia integration is mostly coherent, but it asks for powerful wallet/CDP secrets, encourages persistent storage of them, and includes an under-documented API-key creation command.
Only use this skill with a dedicated Xenodia/CDP wallet and least-privileged credentials. Do not paste a valuable wallet private key, avoid saving secrets to ~/.zshrc unless you understand the exposure, and review or disable the get-api-key command unless you explicitly need a static token.
Findings (5)
Artifact-based informational review of SKILL.md, metadata, install specs, static scan signals, and capability signals. ClawScan does not execute the skill or run runtime probes.
If these credentials are mishandled or over-permissioned, the agent or another process could act as the CDP wallet/account identity, not just query Xenodia models.
The skill asks the owner to provide Coinbase CDP API private-key material and a server-wallet secret. Those are privileged account/wallet credentials, and the artifacts do not show least-privilege scoping or a narrow credential contract.
You need 3 values ... CDP_API_KEY_ID and CDP_API_KEY_SECRET ... the "privateKey" field ... CDP_WALLET_SECRET ... "Generate Wallet Secret"
Use a dedicated, least-privileged CDP key and wallet only for Xenodia; avoid sharing broad production credentials, and declare the required credentials and scopes clearly.
The credentials may remain active and exposed long after the initial setup, increasing the chance of accidental disclosure or unauthorized reuse.
The instructions encourage persistent storage of high-value secrets in a global shell startup file, making them available to future sessions and other shell-launched tools.
ask the agent to save the credentials to `~/.zshrc` ... The agent will append: export CDP_API_KEY_ID="..." ... export CDP_API_KEY_SECRET="..." ... export CDP_WALLET_SECRET="..."
Prefer a secret manager or per-session environment variables; if persistence is necessary, document cleanup, file permissions, and the risks before writing to shell profiles.
Anyone or any tool that can read the skill directory could recover the wallet private key and impersonate that wallet identity.
Local-wallet mode writes an EVM private key in plaintext under the skill directory, with no visible permission hardening or warning to avoid funded/main wallets.
KEY_FILE = os.path.join(os.path.dirname(os.path.abspath(__file__)), ".xenodia_agent_key") ... with open(KEY_FILE, "w") as f: f.write(acc.key.hex())
Use a dedicated empty wallet for this skill, set restrictive permissions such as 0600 on the key file, and avoid storing valuable wallet private keys in plaintext.
A long-lived token could be created or exposed in terminal history/logs without the user realizing this is part of the helper's capabilities.
The helper exposes a command that can create and print a Xenodia API token. This mutates account credential state and is not shown in the file's top-level usage list.
elif cmd == "get-api-key": ... requests.post(f"{XENODIA_BASE_URL}/v1/me/api-keys" ... ) ... print(resp.json()["data"]["token"])Document this command clearly, require explicit user approval before creating an API key, and explain token scope, lifetime, storage, and revocation.
Users will install whatever package versions are current at setup time, which can change behavior or introduce dependency risk.
The dependency installation is purpose-aligned for Coinbase CDP and HTTP access, but versions are unpinned and there is no lockfile or install spec in the supplied artifacts.
pip install cdp-sdk requests
Install in a virtual environment and prefer pinned dependency versions or a reviewed lockfile.
