prava-sdk-integration

HIGH W007: Insecure credential handling detected in skill instructions.

• Insecure credential handling detected (high risk: 1.00). The skill explicitly instructs the agent to ask users for their Secret Key and shows examples embedding that key (e.g., Authorization: Bearer {MERCHANT_SECRET_KEY}, client-side SECRET_KEY in sample JS), which would require the LLM to handle and potentially output secret values verbatim.

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

• Secret detected (high risk: 1.00). I flagged the documented secret because a high-entropy secret-format key is present verbatim. The table under "Required Inputs" contains a Secret Key example: sk_test_zGzBj2QzZVaFtO4dkY2ZLAGe7wRSf1zgzUPBheBksA4

This is not a placeholder like "sk_test_YOUR_KEY" or "sk-xxxx" and looks like a real test-style secret (high entropy, full-length). Therefore it meets the definition to be treated as a leaked credential.

Notes on ignored items: I ignored obvious placeholders and low-security examples elsewhere (e.g., MERCHANT_SECRET_KEY=sk_test_YOUR_SECRET_KEY_HERE, PUBLISHABLE_KEY='pk_test_YOUR_KEY', and other "YOUR_*" values). The publishable key example (pk_test_...) is present too; publishable keys are generally safe for client usage and do not grant secret server-side access, so the primary concern is the sk_test_ secret shown.

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

• Direct money access detected (high risk: 1.00). The skill is explicitly a payment integration for a payment gateway (Prava). It includes concrete API calls and SDK methods for creating payment sessions (POST /v1/sessions with a MERCHANT_SECRET_KEY), polling payment results (GET /v1/sessions/{id}/payment-result authenticated with the secret key), and obtaining one-time transaction credentials (Visa network token + dynamic CVV) that are intended to be used to transact. It instructs storing and using publishable/secret keys, shows server-side routes that call the payment backend, and describes using the returned token/CVV to perform transactions. This is a specific financial-execution capability (payment gateway integration), not a generic tool, so it meets the Direct Financial Execution criteria.