T09 · Insecure Skill Coding Practices
Warning
- Location
- prompts/prompt4-delivery-fulfillment-playbook.md:118
- Finding
- Insecure Transfer of Client Administrative Credentials## Vulnerability Details **File Location**: `prompts/prompt4-delivery-fulfillment-playbook.md`, lines 118–121 **Vulnerability Type**: Plaintext sensitive-data handling and insecure credential transfer **Risk Level**: Medium ### Vulnerable Code Snippet ```text a) Project close email (send day of final delivery): - Celebrate the win (specific results from the results report) - Provide everything: links, credentials, documentation folder - Set expectation for 30-day check-in ``` Related instructions reinforce handling and transfer of administrative credentials: ```text Min 40-55: access and logistics (accounts, credentials, shared drive) ``` ```text "Before moving to Launch, client approves: (1) all workflows run in test mode with no errors, (2) dashboard shows correct data for past 7 days, (3) client admin credentials are transferred and tested." ``` ### Technical Analysis The prompt instructs the generated project-close email to provide client credentials alongside links and documentation. It does not require a password manager, an expiring secret-sharing mechanism, encryption, a separate communication channel, credential rotation, multifactor authentication, or least-privilege service accounts. Email messages and project documentation are frequently retained, forwarded, synchronized to multiple devices, backed up, and accessible to mailbox administrators. Including administrative credentials in such communications can therefore create a long-lived plaintext secret. The related instructions also normalize transferring and testing client administrator credentials rather than provisioning narrowly scoped, individual accounts. ### Attack Path 1. The agency requests or receives administrative credentials during project onboarding. 2. The Skill generates a project-close email that includes those credentials with links and documentation. 3. The email is stored in the sender's and recipient's mailboxes and may be forwarded, archived, or synchronize ...[truncated 1070 chars]
- Remediation
- ## Remediation Suggestions - Remove the instruction to place credentials in project-close emails or ordinary documentation. - Require secrets to be transferred through an approved password manager or an encrypted, access-controlled, expiring secret-sharing service. - Provision named, least-privilege accounts for agency personnel instead of sharing client administrator accounts. - Require multifactor authentication for all administrative and integration accounts. - Use separate communication channels when transmitting access instructions and secret-sharing links. - Rotate any credential that was previously shared through email, chat, or project documentation. - Revoke agency access promptly when delivery or the support period ends. - Maintain access logs and periodically review active users, API tokens, connected applications, and account permissions. - Store integration secrets in platform-native secret stores rather than spreadsheets, email, or shared folders. - Replace the affected prompt text with guidance such as: “Provide documentation and access-transfer instructions, but never include passwords, API keys, recovery codes, or other secrets in email. Transfer secrets through an approved encrypted secret-sharing mechanism and require rotation after handoff.”