T09 · Insecure Skill Coding Practices
Warning
- Location
- prompts/prompt_2_patient_retention.md:14
- Finding
- Marketing Communications Generated Without Verified Patient Consent<![CDATA[ ## Vulnerability Details **File Location**: `prompts/prompt_2_patient_retention.md`, line 14 **Vulnerability Type**: Consent validation failure in healthcare marketing workflows **Risk Level**: Medium ### Vulnerable Code Snippet ```text **Practice name:** [PRACTICE NAME] **Provider name(s) and credentials:** [e.g., Dr. James Okafor DC, CCSP] **Specialties:** [e.g., auto injury, sports, family wellness] **Average visit frequency:** [e.g., 2x/week acute, 1x/week maintenance] **Maintenance/wellness care offered:** [yes/no + brief description] **Payment options:** [e.g., insurance + cash, cash-pay only, PI liens, payment plans] Patient consent for marketing is assumed — all sequences include unsubscribe/STOP options. ``` ### Technical Analysis The prompt instructs the agent to assume that every recipient has consented to marketing. It then generates patient reactivation messages, referral solicitations, maintenance-care promotions, and other marketing communications. An unsubscribe link or `STOP` instruction provides a mechanism for revoking consent but does not establish that valid consent existed before the first message. Consent requirements may also differ by channel: permission to receive transactional appointment notifications does not necessarily authorize promotional email or SMS messages. This instruction conflicts with the safer requirement in `prompts/prompt_1_new_patient_acquisition.md`, which states that SMS marketing requires prior written consent. Because Prompt 2 removes consent verification at the workflow level, an operator could deploy its outputs to an unqualified patient list without being warned to confirm each recipient's authorization. ### Attack Path 1. A practice exports a list of current or lapsed patients from its scheduling, CRM, or clinical system. 2. The operator invokes Prompt 2 to generate reactivation, referral, or maintenance-care marketing messages. 3. The Skill assumes consent instead of requiring the operato ...[truncated 1143 chars]
- Remediation
- <![CDATA[ ## Remediation Suggestions 1. Replace the consent assumption with an explicit prerequisite: ```text Before generating or scheduling marketing communications, confirm that each recipient has documented, channel-specific consent. Do not treat consent to appointment reminders or clinical communications as consent to marketing. ``` 2. Require the operator to identify the communication type as transactional or promotional before generating a message. 3. Require documented consent metadata for promotional outreach, including: - Recipient identity - Authorized channel - Consent source - Consent date and time - Applicable campaign or purpose - Current opt-out status 4. Suppress recipients who have opted out, lack suitable consent, or cannot be matched reliably to a consent record. 5. Keep appointment confirmations and reminders operationally separate from reactivation offers, referral requests, discounts, and maintenance-care promotions. 6. Make unsubscribe and `STOP` handling mandatory in addition to—not instead of—prior consent validation. 7. Add a pre-deployment checklist requiring review by the practice's privacy or legal adviser for the relevant jurisdiction. 8. Align Prompt 2 with Prompt 1's requirement for prior written consent for SMS marketing and remove any conflicting language across the Skill. ]]>