Security audit
Security checks for vulnerabilities and agentic risk
The Exa workflow is coherent, but fallback setup immediately runs downloaded installer code without a separate approval step.
Preinstall a trusted, verified CLI version and require approval before allowing fallback installation. Review its automatic skill-sync settings and understand that OOMOL mediates Exa requests and credentials. The concern is uncontrolled setup behavior; the inspected skill does not establish malicious intent or exfiltration.
The supplied command performs remote code execution for an apparent Oomol CLI installation, not an Exa data operation. Nothing in the supplied chunk establishes that this is a supporting implementation step for Exa. The downloaded script's contents are not provided, so its further behavior cannot be determined.
The supplied chunk performs only a CLI login; it neither targets Exa nor implements the declared data operations. Authentication could be a supporting implementation detail if oo were established as the Exa access mechanism, but the supplied content provides no such connection.
Piping a live HTTPS download directly into bash executes mutable remote code without a pinned version or independent integrity verification. If the installer host or distribution pipeline is compromised, the script could access local data or modify the system with the executing account's privileges; the legitimate CLI dependency does not eliminate this supply-chain risk.
oo: command not found — install the oo CLI (other platforms: https://cli.oomol.com/install-guide.md):
curl -fsSL https://cli.oomol.com/install.sh | bash # macOS / Linux
The fallback setup directs execution of downloaded shell or PowerShell code without requiring user approval or explaining that it can modify the local system with the agent's privileges. Triggering setup only when the CLI is absent reduces exposure, but installation remains a significant trust boundary beyond an ordinary Exa request.
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.
- **`OOMOL_INSUFFICIENT_CREDIT`** — OOMOL billing stop. Recharge at `https://console.oomol.com/billing/token-recharge` before retrying.
- **HTTP 402 without `OOMOL_INSUFFICIENT_CREDIT`** — the third-party account itself has no active plan or credit. Report the provider error message as is; do not ask the user to recharge OOMOL.
## Resources