Security audit

Ika Move

Security checks across malware telemetry and agentic risk

Overview

This is a documentation-only Ika/Sui dWallet guide, but it should be reviewed carefully because its examples handle real wallet signing, raw private keys, and irreversible shared-signing changes without enough guardrails.

Install only if you are intentionally building Ika dWallet or cross-chain signing flows. Treat the examples as security-sensitive templates: use testnet first, pin dependencies, require explicit authorization on every signing path, never log or hardcode private keys, seeds, or secret shares, and require informed user/operator approval before converting any wallet to shared signing mode.

SkillSpector

By NVIDIA

Vulnerability Patterns

Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
Excessive AgencyUnrestricted Tool Access, Autonomous Decision Making, Scope Creep
Trigger AbuseOverly Broad Trigger, Shadow Command Trigger, Keyword Baiting Trigger
Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access

Findings (7)

Vague Triggers

Medium

Confidence: 91% confidence
Finding: The skill description is broad enough to trigger on many generic Move/Sui smart-contract tasks, not just narrowly scoped Ika integrations. That can cause the agent to inject specialized cross-chain signing guidance into unrelated development flows, increasing the chance of inappropriate code suggestions, unsafe dependency inclusion, or accidental use of powerful wallet/signing primitives where they are not needed.

Missing User Warnings

Medium

Confidence: 87% confidence
Finding: The documented operation makes zero-trust wallets contract-signable by publishing user secret key shares, and although it says 'Irreversible,' it does not clearly foreground the security consequences, preconditions, or governance requirements around performing that change. In a wallet/signing integration context, under-warning an irreversible reduction in key-holder control can lead developers to ship flows that permanently weaken their trust model or expose signing authority to smart-contract compromise.

Missing User Warnings

Medium

Confidence: 88% confidence
Finding: The documentation explicitly recommends a shared dWallet contract that can sign using a public user share 'without user interaction,' but it does not prominently warn integrators that this enables autonomous signing once on-chain authorization conditions are met. In a contract-integration guide, this omission is dangerous because developers may implement business logic that can authorize real cross-chain signatures without understanding the custody and consent implications.

Missing User Warnings

Medium

Confidence: 91% confidence
Finding: The imported key wallet pattern shows how to import existing key material into a signing workflow, but it omits a clear warning that this bridges existing private-key authority into the protocol and can enable signing over assets controlled by that key. Because this is an integration reference for production contracts, developers may copy the pattern without understanding the sensitivity of imported-key custody, provenance, consent, rotation, and blast-radius considerations.

Missing User Warnings

Medium

Confidence: 88% confidence
Finding: The documentation shows `signAndExecuteTransaction` examples that submit live on-chain actions without any accompanying warning that these calls spend funds, mutate state, and may trigger irreversible signing flows. In a developer integration guide for wallet and cross-chain signing, readers commonly copy-paste examples, so omission of confirmation, simulation, and network-safety guidance materially increases the risk of accidental transaction execution.

Missing User Warnings

High

Confidence: 97% confidence
Finding: The key import example accepts a raw `privateKey` and demonstrates passing it into import preparation without any warning about handling highly sensitive key material. In this skill's context—cross-chain wallets and dWallet creation—developers may incorrectly log, persist, reuse, or expose imported private keys, leading to direct compromise of funds and downstream identities.

Missing User Warnings

Medium

Confidence: 92% confidence
Finding: The KeySpring pattern recommends deriving encryption keys from generic wallet signatures or passkeys but does not warn about domain separation, message fixation, signature replay/reuse, cross-application correlation, or the danger of deriving long-term cryptographic material from signatures gathered in unsafe contexts. In a wallet-integration skill, this can cause predictable or reused seeds across apps and environments, undermining secrecy and user separation guarantees.

VirusTotal

62/62 vendors flagged this skill as clean.

View on VirusTotal

Static analysis

No suspicious patterns detected.