Shopping Claw | Is your claw a shopaholic?
WarnAudited by ClawScan on May 10, 2026.
Overview
This skill is transparent about enabling agent payments, but it deserves careful review because it gives spending authority and can pull remote checkout instructions during purchases.
Install only if you explicitly want this agent to spend or collect money through CreditClaw. Keep ask-for-everything approval enabled, set low spending limits and merchant allowlists, protect the API key and webhook secret, and review any remotely fetched vendor checkout instructions before allowing a purchase.
Findings (6)
Artifact-based informational review of SKILL.md, metadata, install specs, static scan signals, and capability signals. ClawScan does not execute the skill or run runtime probes.
A compromised, incorrect, or overly broad remote vendor instruction could steer the agent during a purchase or checkout flow.
The agent is instructed to fetch and follow remote checkout instructions that are not included in the reviewed skill artifacts, and those instructions can influence browser/payment actions.
If a vendor skill exists → use it. It contains merchant-specific instructions... Returns the vendor's complete checkout instructions as Markdown.
Require user review before following fetched vendor skills, prefer signed or pinned vendor instructions, and keep per-purchase approval enabled.
If the key is leaked or used outside the intended CreditClaw flow, someone else could attempt spending with the owner's funds.
The skill clearly discloses that its API key is a financial identity credential with spending authority.
Do not share `CREDITCLAW_API_KEY` with any other agent, tool, or service. It is your identity — leaking it means someone else can spend your owner's money.
Store the key only in a secure secrets manager, use low limits and allowlists, rotate the key if exposed, and keep approval mode set to ask before purchases.
A mistaken product, merchant, amount, or checkout step could result in an unwanted purchase, even though the flow includes approval and guardrails.
The documented workflow uses API calls and browser automation to complete real purchases with decrypted payment-card data.
Once approved → call POST /bot/rail5/key ... Decrypt card details ... Fill shipping/billing, then card fields ... Submit and capture confirmation
Verify merchant, item, price, shipping, and total cost with the user before submission; keep CAPTCHA/3DS/OTP hard stops; and avoid automatic retries after payment errors.
The agent may continue checking wallet messages, balances, and permissions after the initial task if configured to do so.
The skill documents recurring polling behavior. There is no local persistence code, but the instructions encourage ongoing agent activity.
Run this routine periodically... Messages | GET /bot/messages | Every 30 minutes ... Full status | Every 8 hours ... Spending permissions | Every 24 hours
Only enable scheduled polling if you want ongoing monitoring, and make the schedule and stop conditions explicit.
If webhook verification is skipped or the secret is exposed, forged events could influence the agent's financial workflow.
The skill supports webhook event delivery across a network boundary, including financial approval and card-delivery signals; the artifact does include signature-verification guidance.
CreditClaw sends real-time POST event notifications to your `callback_url`... always verify the `X-CreditClaw-Signature` header (HMAC-SHA256) using your `webhook_secret`
Use HTTPS, verify every webhook signature, keep the webhook secret private, and treat webhook messages as suggestions unless they match the owner's instructions.
Stored notes could affect future agent behavior around purchases and spending decisions.
The agent is told to treat stored remote spending-permission notes as instructions. The intended source is the owner via CreditClaw, but it is still persistent external context.
`notes` — read and follow these; they are direct instructions from your owner
Keep owner notes narrow, review them periodically, and ensure they remain subordinate to current user instructions and platform safety rules.