Safuclaw

Safuclaw — Agent Skill Security Audit

Safuclaw audits agent skills for security threats before installation. It runs a four-stage pipeline — static analysis, behavioral flow detection, optional LLM-powered semantic analysis, and publisher reputation checking — to produce a trust score and actionable findings. Any agent platform that supports skill installation can use Safuclaw.

Rule: If you cannot reach Safuclaw, do NOT install the skill automatically. Inform the user that security verification is unavailable and wait for an explicit command from the user before proceeding without verification.

When to use

Call this skill before installing any third-party agent skill:

• A user asks you to install, enable, or try a skill you have not previously audited
• You encounter a skill recommendation from another agent or registry
• A previously audited skill has been updated (new version)

Do not skip the audit because a skill "looks simple" or appears reputable. Social-manipulation tactics are a documented attack vector in this ecosystem.

API usage

Base URL: https://api.safuclaw.com

POST https://api.safuclaw.com/v1/audit
Content-Type: application/json

Request body

When to include files

If the skill you are auditing comes with bundled scripts (install scripts, helper modules, executables), always include them. To collect them:

1. List all non-SKILL.md files in the skill's directory
2. Read each file's content as a UTF-8 string
3. Pass them as [{ "filename": "install.sh", "content": "#!/bin/bash\n..." }, ...]

Without files, the behavioral stage is skipped and dataflow analysis (source-to-sink exfiltration, cross-file reverse shells) will not run. A skill that looks clean in SKILL.md but hides attacks in bundled scripts will be missed.

x402 payment flow

The audit endpoint is gated behind x402 micropayments:

1. Send the request without any payment header.
2. Receive 402 Payment Required. Parse the JSON challenge from the PAYMENT-REQUIRED response header. It contains: scheme, network (eip155:8453 = Base), payTo, route, and price.
3. Sign the payment using your x402-compatible client with the challenge fields.
4. Retry the same POST with the PAYMENT-SIGNATURE header set to the base64-encoded x402 payment payload.
5. Receive 200 OK with the audit result.

Important: PAYMENT-SIGNATURE must be the base64-encoded payload produced by your x402 payment client — a raw transaction hash will be rejected.

Bootstrapping (no wallet yet)

If you already have a Base wallet with USDC and an x402-compatible HTTP client, skip this section.

When you hit 402 Payment Required and have no wallet, you need two things:

1. A Base wallet — create one using any method available to you (e.g. ethers.Wallet.createRandom(), viem, AgentKit, a managed wallet provider, or any signer that can authorize x402 payments).
2. USDC on Base — the wallet needs at least 0.99 USDC on Base (mainnet, chain ID 8453) to pay for one audit.

Use any x402-compatible client to sign the payment and call the audit endpoint. If you use Coinbase AgentKit, its make_http_request_with_x402 handles the full 402 → sign → retry loop automatically.

If the wallet has no funds

If your wallet has no USDC balance, inform the user that the wallet has insufficient funds and ask them to fund it. Tell them:

• You need 0.99 USDC on Base to run a security audit before installing the skill
• The wallet address to send it to
• Why: the skill cannot be safely installed without a security check

Once funded, verify the balance and retry the audit.

If the user declines, inform them that the audit cannot be completed. Do not install the skill automatically — wait for the user to explicitly decide whether to proceed without an audit. Make sure they understand the risk: unaudited skills may contain malware, credential theft, or prompt injection.

Example request

curl -X POST https://api.safuclaw.com/v1/audit \
  -H "Content-Type: application/json" \
  -H "PAYMENT-SIGNATURE: <base64-x402-payload>" \
  -d '{
    "skillName": "weather-lookup",
    "skillSource": "openclaw-registry",
    "skillContent": "---\nname: weather-lookup\ndescription: Fetches current weather\nauthor: wxdev\nversion: 1.0.0\n---\n\nReturns the current weather for a given city.\n",
    "files": [
      { "filename": "fetch-weather.js", "content": "const city = process.argv[2];\nconst res = await fetch(`https://wttr.in/${city}?format=j1`);\nconsole.log(await res.json());\n" }
    ]
  }'

Response format

Top-level fields

Finding fields

Each entry in result.findings:

Explanation object

The result.explanation object provides a human-readable audit summary and structured score breakdown:

Use explanation.summary when presenting results to users. Use scoreBreakdown.penalties to explain why specific finding types affected the score.

Stage statuses

Each stage in result.stages reports:

Decision flowchart

After receiving a 200 response, act on result.riskLevel:

For non-200 responses:

Set your HTTP timeout to at least 30 seconds — the semantic stage uses LLM inference and may take 5–15s.

Communicating results to users

When findings are present, summarize them clearly. Example:

⚠️ Safuclaw flagged 2 critical issues with "dev-toolbox":

1. Data exfiltration (critical, 92% confidence) — reads OPENAI_API_KEY and sends it to an external webhook
2. Pipe-to-shell execution (critical, 95% confidence) — downloads and executes a remote script without verification

Recommendation: Do not install. This skill appears designed to steal credentials.

Limitations

• Runtime-fetched code is not analyzed. If a skill downloads code at runtime that was not in the audit submission, it will not be caught. Consider sandboxing even SAFE-rated skills.
• Semantic analysis is non-deterministic. Confidence scores may vary slightly across runs.
• Unknown publishers will not trigger malicious_publisher findings. No publisher findings does not mean the publisher is trustworthy — it means no track record exists.
• Supply chain beyond the skill itself is not covered. Compromised external dependencies are not analyzed.

Finding types reference