Pluginv1.0.0

ClawScan security

SayDeploy · ClawHub's context-aware review of the artifact, metadata, and declared behavior.

Scanner verdict

SuspiciousMar 31, 2026, 2:02 AM

Verdict: suspicious
Confidence: medium
Model: gpt-5-mini
Summary: The skill's purpose (deploy/manage many cloud services) is plausible, but the instructions rely on running unpinned remote npm code (npx saydeploy@latest), there are metadata inconsistencies about required environment/binaries, and the skill will obtain and manage credentials for many third‑party services — so proceed only after verifying the external package and OAuth scopes.
Guidance: What to check before installing SayDeploy: - Understand the external code: 'npx saydeploy@latest' will download and execute code from npm at runtime. Inspect the npm package and its repository (https://github.com/lunarwerxs/saydeploy and https://saydeploy.com) before running, and prefer a pinned version if possible. - Verify metadata mismatches: the skill manifest requires node/npx and a primaryEnv (SAYDEPLOY_WORKSPACE_ID) but the registry metadata shows none — ask the publisher to correct this and explain the workspace env usage. - Review OAuth scopes and storage: during pairing the service will request access to many services. Ask what scopes are requested, where tokens are stored, and whether tokens are sent to saydeploy.com's servers or only kept locally. - Limit blast radius: only connect the accounts/services you are comfortable giving an automated agent control over; use least-privilege service accounts/tokens when possible (separate test accounts for critical infrastructure). - Prefer pinned releases and audits: if you will rely on this skill in production, request that the author publish a pinned MCP version or provide checksums and maintain a changelog. Consider reviewing the package source before granting access. Given the unpinned remote execution and metadata inconsistencies, treat this skill as potentially risky until you can verify the package and the connector's handling of credentials.

Review Dimensions

Purpose & Capability: noteThe SKILL.md and README describe deployment and management across Cloudflare, Netlify, Stripe, Supabase, GitHub, etc., which coherently explains why the connector would need to obtain credentials and run code. However, the registry summary at the top of the evaluation says 'required env vars: none' and 'required binaries: none', while the skill manifest (skills/saydeploy/SKILL.md) declares required bins (node, npx) and a primaryEnv (SAYDEPLOY_WORKSPACE_ID). That mismatch between declared registry metadata and the skill's own runtime instructions is an incoherence that should be clarified.
Instruction Scope: concernThe runtime instructions tell the agent/operator to run 'npx saydeploy --pair' and the .mcp.json config runs 'npx -y saydeploy@latest' as the MCP server. That means the agent will execute third‑party npm package code (fetched at runtime) which will open an OAuth pairing URL for connecting many services. While connecting services is expected for this functionality, the instructions do not specify where credentials/tokens are stored, what network endpoints the helper talks to, or the exact scopes requested — creating a real risk that credentials could be stored or transmitted to the external service beyond the user's expectations.
Install Mechanism: concernThere is no static install spec; instead the skill relies on npx to fetch and run saydeploy@latest from the npm registry (see .mcp.json and the pairing step). Fetching and executing the latest unpinned package at runtime is higher risk than a pinned release or vendor-supplied binary because it allows arbitrary remote code execution and unpredictable updates. The package origin appears to be npm/GitHub (repository listed), but the skill does not pin a specific version or provide checksums.
Credentials: concernThe SKILL.md declares a primaryEnv of SAYDEPLOY_WORKSPACE_ID and requires node/npx, but the registry metadata provided earlier omitted those requirements — an inconsistency. More importantly, although the skill needs to manage many services, it doesn't list the specific environment variables or explain how third‑party service credentials (OAuth tokens, API keys) are handled, stored, or isolated. Requesting or obtaining credentials for many unrelated services is proportional for a connector, but only if storage, transmission, and scope are transparent — which they are not here.
Persistence & Privilege: noteThe skill is not set to always:true (good) and uses normal autonomous invocation. However, by design it grants the agent the ability to perform actions across multiple external services once paired — a powerful privilege. The skill's MCP process (npx-run package) will run locally and likely maintain long‑lived connections/tokens for the workspace; this is expected but raises the usual risk profile for multi‑service connectors and should be considered before granting access.