T09 · Insecure Skill Coding Practices
Warning
- Location
- SKILL.md:66
- Finding
- Sensitive Credentials Encouraged in Externally Uploaded Identity Data## Vulnerability Details **File Location**: `SKILL.md:66, 93-99, 139-144, 327-333` **Vulnerability Type**: Sensitive credential exposure through externally stored identity content **Risk Level**: Medium ### Vulnerable Code Snippets ```markdown - **Access** — API keys that unlock capabilities ``` ```bash curl -X POST https://api.soul.mds.markets/v1/soul/register \ -H "Content-Type: application/json" \ -d '{ "name": "ResearchBot", "slug": "researchbot", "soul_md": "# ResearchBot\n\nI am a research analyst with expertise in...", "soul_price": 25.00 }' ``` ```bash curl -X PUT https://api.soul.mds.markets/v1/soul/me/soul \ -H "Authorization: Bearer soul_xxx..." \ -H "Content-Type: application/json" \ -d '{ "soul_md": "# ResearchBot v2\n\nUpdated capabilities...", "change_note": "Added financial analysis expertise" }' ``` ```markdown 1. Help them craft a compelling `soul.md`: - Define their expertise and judgment - Specify their approach and quality standards - Include relevant API keys/access (encrypted, never exposed) ``` ### Technical Analysis The skill defines API-key-backed access as part of the `soul.md` identity and later instructs agents to include relevant API keys or access information in that document. Registration and update examples transmit the complete `soul_md` field to the external `api.soul.mds.markets` service. Although the text says credentials should be “encrypted, never exposed,” it specifies no encryption scheme, trusted key recipient, key-management process, secret-reference mechanism, visibility control, or pre-upload secret scanning. Encryption without an independently protected key and a defined trust model does not ensure confidentiality. An agent following these instructions could therefore embed raw, reversibly encoded, or otherwise recoverable credentials in remotely stored marketplace content. ### Attack Path ...[truncated 1248 chars]
- Remediation
- ## Remediation Suggestions 1. Explicitly prohibit raw API keys, wallet private keys, bearer tokens, seed phrases, and other reusable credentials in `soul.md`. 2. Replace embedded credentials with opaque identifiers that reference secrets held in a dedicated secret manager. 3. Retrieve secrets only at execution time and restrict access to the specific service requiring them. 4. Apply least-privilege scopes, short expiration periods, usage limits, and service-specific credentials. 5. Add mandatory secret detection and redaction before every registration or identity-update request. 6. Document whether `soul.md` is public, private, logged, replicated, or available to marketplace operators. 7. If encrypted capability data is required, define authenticated encryption, recipient key validation, key rotation, revocation, and a threat model ensuring that decryption keys are never uploaded with ciphertext. 8. Provide credential rotation and incident-response guidance for accidentally uploaded secrets.