Is daveo280/aisp safe?

_meta.json declares the latest published version as 2.0.2 (with history entries at 2.0.0 and 2.0.2), but the installed SKILL.md frontmatter declares version 1.0.2. The CHANGELOG.md documents only through v1.0.2 with zero 2.x entries. This two-major-version gap means users are installing skill code that may be significantly behind the publisher's current version, with no visibility into what security fixes, behavioral changes, or breaking changes were introduced in the 2.x series. The discrepancy could also indicate a build/packaging failure where the meta was updated but the skill files were not.

The provider workflow explicitly instructs agents to POST Venice API keys to the external backend at diem-marketplace-backend.fly.dev. The agent workflow requires posting EIP-191 signed authentication messages to retrieve rented keys. Both workflows route sensitive credentials through third-party infrastructure outside user control. A compromised or malicious backend operator has full visibility into all stored API keys and all authentication signatures, enabling credential harvesting across all skill users without triggering any observable client-side anomaly.

The skill instructs agents to execute USDC approvals and on-chain fund transfers against a deployed Base mainnet escrow contract. The Security section recommends requiring explicit user confirmation before fund transfers, but this appears as advisory prose rather than a mandatory workflow gate between listing discovery and funding. An agent processing a user query about inference capacity could proceed to USDC approval and contract.fund() execution without a structured confirmation step, resulting in real financial loss from the user's wallet.

The v1.0.2 changelog entry explicitly states the whitelist requirement was removed. Previously, providers required whitelisting before listing API keys; now any actor can create listings and deposit API keys into the backend. Agents renting inference capacity receive no signal distinguishing legitimate providers from malicious actors deliberately listing invalid, rate-limited, honeypot, or phishing API keys designed to exploit agents that consume them.

All agent-to-backend and provider-to-backend interactions are routed through a single hardcoded fly.dev deployment with no documented key verification, no alternative endpoint, and no mechanism for users to audit backend operations. The backend operator has full access to every stored API key and every signed authentication message. If the backend is shut down, hijacked, or operated maliciously, agents will fail to retrieve rented keys while providers may have already deposited their credentials.

inotifywait and auditd monitoring detected read-only access to .env, .ssh/id_rsa, .aws/credentials, .npmrc, .docker/config.json, and .gcloud/application_default_credentials.json during the install session. The first access cluster occurred at session start (08:21:09) before the git clone began, and a second cluster occurred post-install. Since the installed skill contains only markdown and JSON files with no executable code, these reads cannot originate from the skill itself and are attributable to the oathe monitoring framework's baseline hash comparison operations. Canary integrity check confirmed all files remain intact and unmodified.

Installation made outbound HTTPS connections only to GitHub (140.82.121.4:443) for the monorepo git sparse-checkout clone. Pre-existing connections to Canonical Ubuntu update servers (185.125.188.57:443) were already established before the install and are unrelated. No connections were observed to the skill's own backend (diem-marketplace-backend.fly.dev) during install. The connection diff confirms no new persistent outbound connections were established by the install process.

The skill directory contains exclusively four files: SKILL.md, CHANGELOG.md, PUBLISHING.md, and _meta.json. There is no package.json with scripts, no git hooks directory, no .gitmodules, no .gitattributes with filter drivers, and no symlinks. The install process consisted solely of a git sparse-checkout and file copy with zero code execution attributable to the skill.