starknet-agentic-skills

BENIGN. The skill’s capabilities, credentials, and network endpoints are internally consistent with a Starknet wallet skill, and installs come from official npm/documented services. The main risk is not hidden malware but the legitimate high-impact nature of autonomous on-chain transactions and raw private key handling.

No explicit malicious payload is demonstrated in the provided fragment. However, the architecture presents substantial security risk centered on (a) untrusted remote skill manifest ingestion that directly influences agent behavior/tool permissions, and (b) subprocess execution of an MCP server via npx with high-impact credentials (STARKNET_PRIVATE_KEY) available to the child process. Combined with LLM-driven autonomous tool calling (capable of transfer/invoke/swap/deploy), a compromised upstream dependency or tampered SKILL.md could plausibly lead to unauthorized on-chain actions or credential misuse. Mitigations should focus on strict version pinning/integrity verification for executed dependencies, integrity/signature pinning for fetched skill manifests, and hard runtime enforcement of tool/argument allowlists at the MCP call boundary (plus careful environment isolation and safer default CORS).

This module itself shows no direct indicators of embedded malware (no obfuscation, secrets, or exfiltration logic). However, it is security-relevant because it clones third-party repositories and then invokes external tooling (scarb and optionally scarb build via asdf exec) inside those repositories. The environment “sandbox” only redirects HOME/XDG paths and does not provide strong containment, so using this script with untrusted repositories—especially with --allow-build—creates a meaningful supply-chain execution risk via build/metadata hooks or toolchain behaviors.

No overt malware/backdoor logic is present in this snippet (no eval/Function/dynamic payload execution, no obvious exfiltration to arbitrary domains). However, the script is security-sensitive: it generates and writes private keys to state.json, injects secrets into env, and spawns external processes ('npm run dev' and MCP 'node .../dist/index.js') using a configurable directory. If SISNA_DIR/repo contents or MCP/server code are compromised, this could become a supply-chain execution vector. Treat this as a high-impact secrets-handling and subprocess-execution script rather than a clearly malicious package.

SUSPICIOUS. The skill is purpose-aligned for Starknet payments and its installs/data flows mostly match that purpose, with no clear credential exfiltration or deceptive installer behavior. However, it enables autonomous real-world financial transactions, uses a raw private key via environment variables, and exposes payment actions through a Telegram bot, making it high-impact and risky even without confirmed malware.

The code is primarily a setup verifier (no clear eval/dynamic code execution, no obvious malware/backdoor logic, and RPC calls are standard JSON-RPC). The main security concern is supply-chain and secret-handling: it runs npx with a floating @latest package at runtime and passes the entire process.env (which may contain STARKNET_PRIVATE_KEY and other secrets) to the spawned process. Additionally, it can contact arbitrary RPC endpoints if STARKNET_RPC_URL is set, which could be SSRF-like in some environments. No definitive malicious behavior is observed, but the risk is non-trivial.

SUSPICIOUS. The suite is broadly coherent for Starknet workflows, and most network/API usage matches the stated purpose, but risk is elevated by multiple raw GitHub curl|bash installers, especially third-party cross-org installer trust in controller-cli and huginn-onboard. The wallet/DeFi/privacy modules also require high-value credentials and can trigger real on-chain actions, which is in-scope but high-impact.

BENIGN for purpose alignment: the capabilities, credentials, and data flows match a privacy-preserving Starknet payment skill. Security risk is still medium-high because it enables autonomous crypto transactions and needs live private keys, but there is no clear evidence of credential harvesting, stealth, or malicious data routing.

SUSPICIOUS. The install path is ordinary, but the skill enables anonymous wallet creation, private-key-backed contract writes, swaps, and conditional automated execution with real financial consequences. That footprint matches the stated purpose, so this is not confirmed malware, but it is a high-risk skill for agent use because it can autonomously move value onchain.

No malware or obfuscation indicators are present in the provided content because it is a scan-result artifact rather than code. However, it reports repeated high-severity contract governance/upgrade-safety patterns (immediate upgrades without timelock, irreversible/over-permissive admin characteristics, and critical-address initialization/guarding issues). Treat this as elevated smart-contract security risk requiring direct code review of the referenced Cairo modules to confirm whether the control-plane is intentionally designed or dangerously implemented.

The fragment is legitimate setup and usage documentation, not malware. It describes sensitive private-key handling and powerful autonomous blockchain operations that require strict isolation, least privilege, spending limits, dependency review, and secure secret management. The primary concerns are operational security and potential financial loss if the MCP server or agent is compromised; no malicious behavior is demonstrated in the supplied text.

The provided artifact does not contain actual package code, so supply-chain malware behavior (exfiltration, backdoors, credential theft) cannot be confirmed or refuted at the code level. The scan findings are predominantly smart-contract governance/control weaknesses (notably upgrade/timelock/authorization and guard checks on critical initialization), which are security-relevant and warrant thorough manual review of the referenced Cairo files—especially the upgrade authorization and timelock enforcement logic. Based on available evidence, the probability of overt malicious payloads is low, but the probability of serious security risk from contract-control flaws is moderate.

BENIGN for purpose/data-flow coherence: the skill’s packages, credentials, and endpoints match Starknet DeFi execution via AVNU. Risk is still high from a security perspective because it empowers an agent to perform on-chain financial actions using a raw private key, but there is no clear sign of credential harvesting, hidden routing, or malicious install behavior.

SUSPICIOUS: the skill’s stated blockchain onboarding purpose is coherent, and its API/on-chain actions broadly match that goal, but the advertised single-command install relies on unpinned remote script execution from a poorly verifiable GitHub path. The main concern is supply-chain/install trust, not confirmed malware or overt credential exfiltration.

No clear indicators of supply-chain malware, backdoor behavior, or overt data exfiltration are present in this module. The code is a high-privilege DeFi trading bot: it loads a private key from .env, fetches quotes from external endpoints, and can automatically sign and submit swap and (likely) approval transactions when profit thresholds are met. The dominant security concern is operational/economic risk (unexpected execution/approval side effects and reliance on external quote/RPC inputs), not evidence of malicious code in this snippet.

No clear evidence of intentional malware/backdoor behavior in this module (no obfuscation or covert execution). However, the code is security-sensitive: it performs authenticated, high-impact trading operations and can transmit an API key via an HTTP header to a destination constructed from untrusted stdin fields (baseUrl/apiPrefix) with no allowlisting/validation. If an attacker can control the payload while environment secrets are present, the module could be abused for credential disclosure and unauthorized/undesired trading control actions. This warrants hardening (destination allowlists, strict validation, and safer error handling) rather than assuming benign usage.

No direct malware or backdoor behavior can be confirmed from the provided artifact because it contains only static scan metadata rather than the underlying Cairo code. However, the scan indicates multiple high-impact upgrade/admin governance weaknesses (immediate upgrades without timelocks and missing/non-strict guard checks, plus irrevocable/strong admin patterns) across several production files. These are security-relevant design risks that could enable privileged control abuses or operational failures if not mitigated by robust authorization and monitoring; the specific code should be reviewed to verify that upgrade permissions, invariants, and governance processes are implemented safely.

This module is best characterized as a sensitive secrets-handling onboarding/deployment CLI rather than overtly malicious code: it has no visible obfuscation or direct exfiltration mechanisms in the fragment. However, it creates and persists a private key in plaintext (onboarding_secrets.json) and can optionally disclose it to stdout (--print-private-key). Additionally, chmod failure is ignored, potentially weakening file protection. Treat this as a high operational security risk utility and ensure the secrets file and logs are tightly controlled. Malicious behavior could still exist in the referenced step modules, which are not included in this fragment.

No executable malicious logic is evident because the fragment is JSON-only test/demo data. However, it contains hardcoded plaintext private keys and full cryptographic authorization material intended for authenticated blockchain operations. This creates a high supply-chain/security risk: if the payload is logged, committed, redistributed, or reused by tooling, it could enable unauthorized transaction signing and on-chain actions. IPFS references add potential content-trust risk depending on consumer validation, but malware/exfiltration behavior cannot be concluded from this fragment alone.

No direct evidence of malicious logic is present in this JavaScript module (no eval/Function, no network exfiltration, no filesystem/persistence, no obfuscation). However, the module is security-sensitive because it spawns a configurable external adapter and injects high-value credentials (including a private key) into the spawned process’s environment. If pythonBin/scriptPath or the adapter itself can be influenced by an attacker, the impact is substantial (arbitrary code/process execution with secrets available). Additionally, adapter stdout/stderr are used in JSON parsing and in error messages, which can lead to information disclosure or log injection depending on adapter behavior. Overall: medium security risk driven by supply-chain/execution-boundary and secret-handling concerns rather than in-module malware indicators.

Based on the provided static-scan summary alone, the main finding is elevated governance/control risk across multiple Cairo repositories—especially unsafe upgradeability (immediate upgrades without timelock), potentially irreversible admin control, and critical address initialization lacking nonzero guards. However, because no actual code is provided, there is no concrete evidence of classic supply-chain malware behaviors (e.g., backdoors, exfiltration, credential theft). Treat the package/library set as high-impact but not confirmed malicious; further review of the referenced Cairo implementations of upgrade/admin paths and initializer guards is needed to determine whether these patterns are intentional design or exploitable weaknesses.

This module appears to be a wallet/account automation CLI for Starknet using TyphoonSDK: it parses user-provided deposit note JSON, generates a keypair/address, stores the generated private key and artifact locally, and then performs an anonymous withdrawal/deployment action via the TyphoonSDK using the provided txHash. While there is no direct evidence of stealthy malware, the code has meaningful security risk because it handles and persists sensitive secrets/private keys and forwards note secrets/nullifiers to a third-party SDK. If TyphoonSDK (or _rpc.js) is malicious/compromised, secrets could be exfiltrated or unintended on-chain actions could occur; additional input validation and secret-handling hardening would reduce risk.

No executable malware behavior is present in this fragment because it is only a workflow/test trace dataset. However, the artifact contains hardcoded private keys for two accounts, which is a critical secret-management risk in a supply-chain context. Additionally, it references untrusted off-chain content via ipfs:// URIs, which can become dangerous depending on how a consuming system fetches/parses and verifies those contents against the provided hashes. Overall, treat this artifact as high-risk primarily due to credential exposure rather than confirmed malicious logic.

No direct evidence of stealthy malware behavior (e.g., network exfiltration, persistence, credential theft, reverse shells) is visible in this snippet. However, this module is a high-impact process launcher: it spawns `node` using a caller-provided `mcpEntry` and forwards a merged environment (including caller-provided `env`), which can enable arbitrary local code execution or secret leakage to the sidecar if those inputs are not tightly controlled. Tool outputs and errors are also propagated upward, potentially leaking sidecar-provided text into logs or callers. Overall risk is driven by the trust boundary around `mcpEntry`, `env`, and tool invocation inputs.

This module primarily acts as an MCP sidecar launcher/adapter. The main security concern is that it provides a process-execution primitive: it spawns a Node subprocess using a constructor-provided entry argument (mcpEntry) with no validation/allowlisting, and it merges caller/environment-derived variables into the child’s environment. If mcpEntry or env can be influenced by an attacker, this can enable unintended code execution and/or increased data exposure. Aside from untrusted JSON parsing from the sidecar response, there is no direct evidence of malicious payloads in the shown code.

The analyzed pattern represents a high-security risk for upgradeable contracts due to the absence of a timelock and a pending-state workflow. Implementing a robust timelock mechanism via schedule_upgrade and execute_upgrade, with a clearly persisted pending_upgrade, scheduled_at, and upgrade_delay, plus cancellation capabilities, is essential to restore auditable, time-delayed governance over upgrades. Until such controls are in place, the pattern constitutes a significant supply-chain threat with elevated risk of unauthorized or harmful upgrades.

This module functions as a dispatcher that forwards caller-controlled call descriptors directly into an external contract-call syscall and returns the resulting data. The snippet shows no self-call denylist or privileged-selector checks (explicitly noted by the inline comment), creating a strong authorization/control-flow risk consistent with session-key/self-call bypass patterns. While there are no clear indicators of covert malware in this snippet, the missing validation/guardrails make the security risk high for systems that assume restricted session-key behavior.