CreditClaw Wallet
WarnAudited by ClawScan on May 10, 2026.
Overview
This is openly a payment wallet for agents, but it grants high-impact authority over purchases, logged-in shopping accounts, public payment pages, invoices, and webhooks that should be reviewed carefully.
Install only if you intentionally want an agent to spend or collect money. Keep per-purchase approval enabled, set low transaction and daily limits, avoid using personal logged-in shopping sessions, review public payment/invoice actions before sending, and verify webhook destinations and fetched merchant instructions.
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.
If configured and approved by the wallet service, the agent can complete purchases using the owner's funds.
The guide directs the agent through decrypting payment-card details and submitting a real merchant checkout. This is purpose-aligned, but it is high-impact spending authority.
1. Call POST /bot/rail5/checkout ... 4. Decrypt card details using AES-256-GCM ... 7. Fill shipping/billing, then card fields 8. Submit and capture confirmation
Use strict spending limits, keep approval_mode set to ask_for_everything, and require a separate human review before the final merchant payment submission.
The agent could place orders through a logged-in shopping account, affecting the user's account history, shipping addresses, saved payments, and funds.
The skill can operate in an authenticated Amazon session and use saved account addresses/payment methods, which is broader account authority than just calling the CreditClaw API.
Amazon requires account authentication — no guest checkout. Uses saved payment methods and addresses ... If already logged in, "Proceed to checkout" goes directly to checkout ... The agent selects it at checkout by last 4 digits ... clicks "Place your order".
Do not give the agent access to logged-in merchant sessions unless explicitly intended; use dedicated accounts, saved cards with low limits, and manual confirmation for account-based checkouts.
The agent could create public-facing payment artifacts or send invoices that affect customers, recipients, or the user's business reputation.
The documented APIs let the agent publish payment pages and send invoices/emails to third parties, and the provided endpoint documentation does not show a required owner confirmation step for those mutations.
Create public checkout pages where anyone can pay you ... Share `checkout_url` with anyone ... Sends the invoice to the recipient via email with a formatted PDF attachment.
Require explicit user approval before creating public payment pages, payment links, shops, or invoices, and review recipient emails and amounts before sending.
Wallet, sales, or payment events could be routed to an unintended endpoint if the callback URL is set incorrectly or maliciously.
The agent can change where wallet webhooks are delivered and receive a webhook secret, creating a persistent external data-flow boundary that is not tightly scoped in the artifact.
Update your name, description, or webhook URL: ... "callback_url": "https://new-endpoint.com/hooks/creditclaw" ... the response includes a one-time `webhook_secret`
Only set webhook URLs to endpoints you control, verify the destination before saving it, and store the webhook secret in a secure secrets manager.
A changed or unsafe remote vendor instruction could influence how the agent navigates a checkout or spends money.
The agent is told to fetch and use remote Markdown checkout instructions during financial workflows, but the artifact does not describe signature checks, pinning, or how the fetched instructions are constrained.
If a vendor skill exists → use it ... Returns the vendor's complete checkout instructions as Markdown.
Treat fetched vendor instructions as untrusted until reviewed; constrain them to the requested merchant, item, and amount, and ignore any instructions that ask for unrelated credentials or actions.
Checkout work may be delegated to another agent instance, which can affect where sensitive card-handling instructions run.
The checkout response can include a task payload for an ephemeral sub-agent. The documented cleanup and timeout are mitigating, but users should still notice the delegated-agent behavior.
"spawn_payload": { "task": "...", "cleanup": "delete", "runTimeoutSeconds": 300 }Verify that sub-agents are truly time-limited, deleted after checkout, and cannot retain card data or continue operating after the transaction.