T09 · Insecure Skill Coding Practices
- Location
config/faq-template.json:106- Finding
Service-account credential stored within the project configuration directory
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
This dental WhatsApp assistant is mostly purpose-aligned, but it needs review because it handles patient data and calendar-write access while giving conflicting emergency medication guidance and weak privacy/credential instructions.
Review before installing. Remove or clinically approve the emergency medication and first-aid guidance, fix emergency numbers by clinic jurisdiction, disclose what patient data is collected and where it is stored, minimize calendar event descriptions, restrict calendar sharing and service-account permissions, store credentials outside the project or in a secret manager, and define retention, consent, and staff-access controls.
config/faq-template.json:106Service-account credential stored within the project configuration directory
config/messages-template.json:38Emergency response provides unscreened medication advice despite an explicit prohibition
The skill explicitly states it must never diagnose or suggest medications, but the emergency triage section later gives specific first-aid and OTC medication guidance such as ibuprofen use. In a dental WhatsApp assistant context, that contradiction is dangerous because users may rely on the bot for medical advice during emergencies, creating safety and liability risk if the guidance is inappropriate for the patient.
The Portuguese emergency note directs users of a US clinic configuration to call 192 (SAMU), which is a Brazil-specific service and inconsistent with the clinic's US location. In an emergency-assistance context, presenting the wrong emergency number can delay urgent care and create real patient safety risk, especially for bilingual users relying on the bot during distress.
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
"note_pt": "Para emergencias com risco de vida, ligue 192 (SAMU)"
},
"google_calendar": {
"credentials_path": "./config/google-calendar-credentials.json",
"calendar_id": "YOUR_CALENDAR_ID@group.calendar.google.com"
},
"staff_alert": {
The documentation describes collecting patient identifiers, appointment details, and syncing with Google Calendar via service-account credentials, but it does not clearly warn operators about the sensitivity of that data or the security implications of credential handling. This can lead to insecure deployment practices, overbroad calendar permissions, accidental credential exposure, and inadequate consent/privacy disclosures for patient data.
The README asserts the bot never gives medical advice, but the emergency flow explicitly provides first-aid and medication guidance such as bleeding control and ibuprofen use. In a dental triage context, that contradiction can cause unsafe reliance on automated advice, create regulatory/compliance exposure, and increase patient harm risk if the guidance is incomplete, inappropriate, or delayed.
The skill claims it should never store sensitive health data in chat, yet it later instructs collection of patient intake information and states that the information is saved. Even if the collected items are not detailed medical history, the contradiction encourages collection and retention of personal patient data in a health-related channel without clear data handling boundaries, which increases privacy and compliance risk.
The Google Calendar integration stores patient phone and email in event descriptions without any user-facing notice or consent step. In a healthcare-adjacent workflow, this can expose personal data to calendar viewers, delegates, sync tools, backups, and third-party integrations beyond what the patient expects from a chat conversation.
The handoff workflow instructs the bot to send patient name, phone, conversation summary, and urgency to staff without telling the patient that their conversation details will be shared internally. In a clinic setting, this can result in unexpected dissemination of sensitive or potentially health-related information, creating privacy and trust issues.
The manifest-style JSON sets default_language to en, which can enforce an English-first behavior across the skill without any documented user language selection. Under the policy rule, locale or language constraints should either be user-selectable or clearly justified.
The emergency template embeds locale-specific instructions ('911' in English and '192 (SAMU)' in Portuguese) as if language alone determines the user's emergency jurisdiction. In a WhatsApp dental assistant, users may speak either language from any country, so incorrect emergency guidance could delay access to urgent care during a life-threatening situation.
The README presents a fixed language scope and later labels all plans as including 'bilingual support (EN/PT)'. This can be a natural-language locale policy issue because it constrains interaction languages without explicit user opt-in or justification that the skill is intentionally limited to English and Portuguese users.
The instruction says to detect language automatically and default to the language configured in a file when the user's language is mixed or unclear. This can force a specific language choice without confirming the user's preference, which is a natural-language locale policy concern.
The manifest describes a patient-facing WhatsApp assistant for scheduling, reminders, triage, FAQs, intake, and review requests. The separate requirement to track operational metrics and post-interaction satisfaction expands the skill into analytics/monitoring behavior that is not mentioned in the stated purpose.
No suspicious patterns detected.