Security audit
Security checks for vulnerabilities and agentic risk
The skill is a disclosed payment-policy integration, but it gives agents high-impact payment and policy-admin powers with some weak control boundaries.
Install only if you want this agent to participate in payment enforcement and possibly payment execution. Prefer a Standard SDK key unless policy administration is required, restrict wallet spend limits, review file permissions on ~/.openclaw/openclaw.json, and require explicit confirmation before deleting policies or sending funds.
The description frames the skill as a payment-policy enforcement helper, but the content also covers browser-based setup, credential provisioning and persistence, policy administration, and human approval decisions. This mismatch can mislead operators into granting the skill more trust and capability than its description implies, which is dangerous for a component that can affect wallet operations and approvals.
Tool parameters are crafted to achieve unintended or unsafe behavior. Parameter abuse can bypass intended safety checks (e.g. shell=True, --force, dangerous glob patterns).
delete-policy)
policy_id="${2:?policy_id required}"
_conto_request DELETE "/api/policies/$policy_id"
;;
get-rules)
Tool parameters are crafted to achieve unintended or unsafe behavior. Parameter abuse can bypass intended safety checks (e.g. shell=True, --force, dangerous glob patterns).
delete-rule)
policy_id="${2:?policy_id required}"
rule_id="${3:?rule_id required}"
_conto_request DELETE "/api/policies/$policy_id/rules/$rule_id"
;;
setup)
Skill establishes unauthorized persistence across sessions via cron jobs, startup scripts, or state files. Session persistence allows an attacker to maintain access beyond the current interaction.
### 1. Sign up and install
Create an account at [conto.finance](https://conto.finance).
Then install the skill:
The README instructs users to run npx clawhub install conto without pinning a specific version or integrity source. That can expose users to supply-chain risk if the upstream package, dependency tree, or latest published release is compromised, causing unreviewed code to execute during installation.
The skill says it can activate automatically from broad natural-language mentions of policies or payments, which increases the chance that unrelated conversation text, quoted content, or prompt-injected third-party instructions trigger sensitive financial operations. In a payment-control skill, unintended activation is especially dangerous because it can lead to policy changes, approval flows, or payment checks based on untrusted context.
The README documents /conto delete the blocklist policy without an explicit warning that deletion is destructive and may remove spending protections. In this context, deleting a policy can directly weaken or eliminate financial controls, increasing the chance of unauthorized or noncompliant payments.
The skill clearly relies on shell execution, network access, and writing credentials to local configuration, yet it declares no explicit tool scope or permission boundaries. That makes the operational authority of the skill opaque and increases the risk of overbroad execution in hosts that infer or grant capabilities implicitly.
Using npx clawhub install conto without a pinned version creates a supply-chain risk: the package resolved at install time may change, be compromised, or differ from what was reviewed. Because this skill is security-sensitive and can influence payments and credential setup, an unpinned install path is especially risky.
The documented Mode A behavior includes automatic execution by a managed wallet service after a single API call. In a financial context, auto-execution materially increases risk because any upstream prompt manipulation, incorrect payment extraction, or policy misconfiguration can lead directly to funds movement without an additional local confirmation step.
| Question | Mode A | Mode B |
| ------------------------------- | ------------------------------------------------------ | ------------------------------------------------- |
| Who holds the wallet keys? | Conto's managed wallet service | You (via your wallet tools) |
| How many API calls per payment? | 1 (single call, auto-executes) | 3 (approve → transfer → confirm) |
| When to use? | Wallet `custodyMode` is MANAGED in the Conto dashboard | Wallet `custodyMode` is EXTERNAL in the dashboard |
**Most OpenClaw setups use Mode B** — your agent controls the wallet through its existing wallet tools, and Conto acts as the policy gate before each transaction.
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.
For wallets managed by Conto, use a single API call. Conto evaluates policies and executes the transfer.
curl -sS -X POST "${CONTO_API_URL:-https://conto.finance}/api/sdk/payments/request" \
-H "Authorization: Bearer $CONTO_SDK_KEY" \
-H "Content-Type: application/json" \
--connect-timeout 10 --max-time 30 \
Setting "autoExecute": true means a single request can both approve and trigger payment execution by the managed wallet path. For a skill that may be invoked from natural-language workflows, this is dangerous because mistakes or adversarial inputs can result in immediate irreversible fund movement.
"recipientName": "<OPTIONAL_NAME>", "purpose": "<WHY_THIS_PAYMENT>", "category": "", "autoExecute": true }'
The instruction to execute the payment directly using the wallet after policy approval promotes autonomous value transfer by the agent. Even with Conto checks, this collapses separation between recommendation and execution and increases the blast radius of prompt injection, mis-parsed transaction details, compromised policy configuration, or user misunderstanding.
### Step 2a: Execute the Transfer
**Now execute the payment using your wallet.** Conto approved the policy — now YOU must send the actual onchain transaction. Do NOT ask the user to execute it.
Use your configured wallet integration for the approved chain and currency. Verify the amount and
recipient against the approval response before signing.
The critical rules normalize use of auto-executing managed-wallet flows as a standard operating mode. In the context of a wallet-integrated agent skill, that guidance increases the likelihood that deployers enable autonomous payments without appreciating the need for an independent signing boundary.
## Critical Rules
1. **Use the right mode for the wallet type.** Mode A (`/request` + `autoExecute`) for `MANAGED` wallets. Mode B (`/approve` + transfer + `/confirm`) for `EXTERNAL` wallets.
2. **NEVER skip the policy check.** Every payment must go through Conto first.
3. **NEVER execute a denied payment.** If `approved` is `false` or `status` is `DENIED`, stop.
4. **For Mode B: ALWAYS confirm after execution.** Call `/confirm` with the tx hash to keep spend tracking accurate. Mode A handles this automatically.
The manifest describes a guardrail-oriented skill for checking whether payments, transfers, swaps, or bridges are approved before funds leave the wallet, with '/conto' used to manage policies or check payments. In code, the helper exposes broad administrative endpoints that can create, modify, replace, and delete policies and rules, which goes beyond merely enforcing checks before payments and materially changes policy state.
The setup flow persists a bearer SDK key to a predictable file in the user's home directory without setting restrictive file permissions or warning the user. If the file is readable by other local users, backup systems, logs, or malware, the token could be stolen and used to approve payments or administer policies depending on its privileges.
The manifest centers on checking Conto for approval before money leaves the wallet. The 'confirm' and 'x402-record' flows report transaction hashes and settled payment records after payment execution, which is adjacent to payment governance but not the same as pre-execution enforcement.
No suspicious patterns detected.