rider-battle

HIGH W007: Insecure credential handling detected in skill instructions.

• Insecure credential handling detected (high risk: 1.00). The prompt embeds a real-looking Supabase API key and explicit Supabase HTTP queries, which would require the agent to include that key verbatim in generated requests/commands (exposing a secret-like token), so this is insecure handling of credentials.

MEDIUM W011: Third-party content exposure detected (indirect prompt injection risk).

• Third-party content exposure detected (medium risk: 0.30). In the required runtime, the agent reads outsider-authored free text from Supabase rows/fields (e.g., GET matches?... for open challenges and leaderboard via ${URL}/rest/v1/leaderboard?select=*&...), even though it treats DB contents as untrusted hints and re-verifies on-chain before money-moving.

HIGH W008: Secret detected in skill content (API keys, tokens, passwords).

• Secret detected (high risk: 1.00). I flagged the Supabase publishable key because it is a high-entropy, literal credential present in the docs: "sb_publishable_CZOntElcy0XxpJt0Ta1Mvg_PIKs8yTS". Although a Supabase "publishable"/anon key is intended for client-side use (limited permissions), it is still a real credential that grants access to the project's anon role (read/insert/patch per RLS) and therefore qualifies as a literal API key in the docs.

I did NOT flag:

• On-chain addresses (escrow, token, settler, treasury) — these are public blockchain addresses, not secrets.
• Any mentions of the service_role key or other keys that are only referenced by name (no literal value).
• Placeholder header keys such as apikey: <key> (no literal value present).

No other high-entropy secrets (private keys, PEM blocks, or hidden service-role keys) were found.

MEDIUM W009: Direct money access capability detected (payment gateways, crypto, banking).

• Direct money access detected (high risk: 1.00). The skill is explicitly a crypto wagering/payment skill: it names a pinned token and escrow contract and contains precise, on-chain transfer and settlement steps (e.g. checks balanceOf, calls RIDER.transfer(escrow, wagerWei), waits for confirmation, then createMatch/joinMatch, calls settle(id, winner, settle_sig), and refund/cancel functions). These are explicit payment/settlement operations on a blockchain escrow (Base) and thus grant direct financial execution authority.