Security audit
Security checks for vulnerabilities and agentic risk
The skill is clear about using Ranla, but it repeatedly runs the latest remote CLI package for account login and approval actions, so users should review that mutable execution risk before installing.
Install only if you are comfortable letting the agent run the current published `ranla-cli` package from npm each time it is invoked and use it with your Ranla account. Prefer a pinned or globally installed reviewed CLI version where possible, keep workspace choices and approvals user-directed, and avoid exposing `RANLA_API_KEY` unless needed.
The skill instructs the agent to execute npx -y ranla-cli@latest, which fetches and runs the newest package version at runtime rather than a reviewed, fixed version. This creates a supply-chain risk: a compromised upstream package, malicious new release, or dependency hijack could cause arbitrary code execution in the agent environment.
Using npx -y ranla-cli@latest login causes the agent to download and execute whatever code is currently published as the latest package version. Because authentication-related commands run with local user context, a malicious package update could steal local tokens, alter login flow, or execute arbitrary system commands.
The repeated instruction to rerun npx -y ranla-cli@latest login means each authentication step may execute newly published code. This expands exposure to package-replacement and dependency-confusion attacks at the exact point where the tool is establishing account access.
Skill enables autonomous high-impact decisions without human-in-the-loop verification. Critical operations (destructive commands, financial transactions, data deletion) should require explicit user confirmation.
3. When they say they approved, run `login` again. It finishes with `status: "signed_in"` and the workspace. The key is saved for the CLI; you never see or handle it.
4. `npx -y ranla-cli@latest whoami` confirms the person and workspace.
Never ask the user for a password or an API key, and never print, log or commit one. If `RANLA_API_KEY` is already set, the CLI uses it.
Several workspaces: each sign-in is one workspace. `workspaces list` shows them; if none is picked the CLI says so — ask the user which, then `workspaces use "<name>"`. Never pick for them. `--workspace "<name>"` uses one for a single call.
The command reference npx -y ranla-cli@latest run help still directs agents to execute unpinned remote code. Even help and schema-discovery commands can execute package install scripts or malicious runtime code before producing output.
The skill recommends npx -y ranla-cli@latest run help <noun>, again trusting the latest package publication at execution time. An attacker controlling the package or its dependencies could weaponize seemingly harmless discovery commands to gain code execution.
The write-capable form npx -y ranla-cli@latest run <noun> <verb> --input ... is especially risky because it combines unpinned code execution with access to potentially sensitive workspace operations. A malicious release could alter commands, exfiltrate data, or perform unauthorized actions under the user's session.
Approval handling via npx -y ranla-cli@latest approvals approve <messageId> lets unreviewed freshly downloaded code participate in sensitive approval workflows. If the package is compromised, it could misrepresent approval targets, auto-approve other pending actions, or exfiltrate account data.
The brain-status command npx -y ranla-cli@latest brain is presented as informational, but it still executes unpinned downloaded code. Because this area concerns model-provider configuration, a malicious package could inspect environment variables or manipulate how provider status is reported.
The logout command also relies on npx -y ranla-cli@latest, so even revocation/removal steps execute mutable upstream code. A compromised release could fake logout success, preserve tokens locally, or perform other unwanted actions while the user believes access was revoked.
No suspicious patterns detected.