Book a flight or Airbnb | Is your claw a nomad?
Security checks across static analysis, malware telemetry, and agentic risk
Overview
This looks like a disclosed CreditClaw payment-wallet skill, but it needs careful review because it can spend real money and may decrypt a real credit card inside an agent or sub-agent.
Install only if you intend to give an agent real spending authority. Keep the API key private, enforce strict CreditClaw spending limits and approval mode, confirm sub-agent isolation and logging behavior before using encrypted-card checkout, and avoid the main-agent fallback for real card data.
Static analysis
No static analysis findings were reported for this release.
VirusTotal
VirusTotal findings are pending for this skill version.
Risk analysis
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.
Anyone or any agent that obtains the API key could potentially act as the wallet and attempt purchases within configured guardrails.
The skill explicitly treats CREDITCLAW_API_KEY as delegated payment identity with spending authority.
Your API key is your identity. Leaking it means someone else can spend your owner's money.
Use a dedicated, least-privilege CreditClaw key, keep approval mode strict, rotate the key if exposed, and never send it outside creditclaw.com.
If approval settings are too permissive, the agent may place real orders or spend funds in ways the user did not intend.
The skill exposes real-world purchase capability, which is expected for a wallet/purchasing skill but high impact.
CreditClaw routes the order through Crossmint and places a real order with the merchant.
Keep human approval enabled for purchases, set low per-transaction and daily limits, and review merchant, amount, quantity, and shipping details before approval.
A real credit card number, CVV, expiry, name, and billing address could appear in an agent conversation or runtime context instead of being isolated to an ephemeral checkout process.
The documented fallback can put full payment-card details into the main agent context, where logging, transcript retention, or later context reuse may expose them.
If your environment doesn't support spawning sub-agents, you can execute the `checkout_steps` directly as the main agent... the main agent will see the decrypted card details in its context.
Do not use the main-agent fallback for real cards unless the runtime guarantees no logging or retention. Prefer isolated ephemeral sub-agents with verified deletion and no transcript persistence.
A user cannot verify at install time exactly what code will run when decrypting the card, even though the behavior is described as part of the intended checkout flow.
The workflow relies on running a Node decrypt script delivered later with the card file; that script is not included in the reviewed artifacts and handles payment-card data.
The sub-agent runs the deterministic decrypt script that was delivered with the card file: `node decrypt.js <key_hex> <iv_hex> <tag_hex> Card-ChaseD-9547.md`
Only run a reviewed or signed decrypt script, execute it in a tightly isolated environment, and avoid granting it access beyond the specific encrypted card file needed for checkout.
If checkout-step content is incorrect or compromised, the agent could follow instructions beyond the intended purchase flow.
The agent is instructed to treat remote checkout-step text as operational instructions for a sub-agent.
The sub-agent executes the `checkout_steps` in sequence.
Constrain sub-agents to the approved merchant, amount, checkout ID, and confirmation endpoint; ignore any checkout step that asks for unrelated actions or data sharing.
Future downloads could differ from the reviewed artifact text if the remote files change.
The optional local install instructions fetch live remote markdown files without version pinning or integrity hashes.
curl -s https://creditclaw.com/stripe/skill.md > ~/.creditclaw/skills/stripe/SKILL.md
Prefer registry-reviewed copies, pin versions or checksums where possible, and re-review remote files before relying on updated instructions.
Sensitive payment details may be handled by a secondary agent process, so weak isolation or logging could expose card data.
The intended design sends sensitive checkout work to a sub-agent; the artifact describes cleanup, but the user must rely on the runtime's sub-agent isolation.
spawn an ephemeral sub-agent to handle the checkout
Use this flow only in environments with clear sub-agent identity, limited permissions, short timeouts, and verified cleanup/no-retention behavior.