T05 · Unauthorized Access and Privilege Escalation
- Location
workflows/01-inbound-call-handler.json:6- Finding
Unauthenticated Webhooks Permit Privileged Workflow Execution
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
This is a coherent dental receptionist automation, but it exposes powerful patient-data and scheduling workflows through unauthenticated webhooks and broad third-party sharing that require careful review before use.
Install only after adding authentication/signature validation to every public webhook, limiting webhook sources, reviewing all third-party data flows for healthcare compliance, minimizing patient information in calendars/SMS/email/CRM, adding consent and opt-out handling, and requiring staff approval for destructive or high-impact actions such as cancellations, no-show classification, waitlist outreach, and CRM/PMS writes.
workflows/01-inbound-call-handler.json:6Unauthenticated Webhooks Permit Privileged Workflow Execution
workflows/05-cancellation-waitlist.json:23Unauthenticated Cancellation Endpoint Deletes Calendar Events
workflows/08-faq-handler.json:40Caller-Controlled Content Is Embedded in System-Role LLM Prompts
workflows/06-after-hours-capture.json:140Unescaped Webhook Data Enables HTML and Malicious-Link Injection in Staff Emails
A patient called after hours with what appears to be an urgent matter.
| Caller | {{ $json.caller_name }} |
| Phone | {{ $json.caller_phone }} |
| Time | {{ $json.call_time }} |
| Summary | {{ $json.summary || $json.transcript }} |
| Recording | Listen |
Please follow up as soon as possible.
", "options": { "appendAttribution": false }, "emailType": "html" }, "name": "Notify Staff" } ``` A similar unsafe link is constructed in the escalation workflow: ```javascript $json.recording_url ? "Recording< ...[truncated 1928 chars]The workflow distributes patient name, phone, email, appointment details, and notes to multiple external services including Google Calendar, Google Sheets, Twilio, SMTP email, and a PMS API, but there is no evidence in this file of consent handling, minimum-necessary data reduction, or privacy/compliance safeguards. In a dental receptionist workflow, this materially increases privacy and regulatory risk because sensitive patient data is propagated across several third-party systems and messages could expose protected health information if misconfigured or intercepted.
This workflow automatically sends SMS messages, initiates AI phone calls, updates appointment records to no_show, emails staff, and triggers waitlist actions without any human review, consent check, suppression list check, or verification that the patient was truly absent. In a dental context, that can expose sensitive appointment information to third parties via misdirected contact data, create unauthorized record changes, and cause harmful downstream actions based on false no-show classification.
The workflow forwards patient-identifying and health-related call data, including phone number, email, summary/transcript, urgency, and recording URL, to Google Sheets, Twilio, and email/SMS channels without any visible consent, minimization, or access-control safeguards in this file. In a dental receptionist context this is especially sensitive because the content can include medical symptoms and emergency details, creating substantial privacy, compliance, and data-leak risk if third-party systems or recipients are misconfigured or unauthorized.
The workflow sends patient identifiers and contact/insurance data to HubSpot and a PMS API via HTTP requests, which is a safety- and privacy-relevant operation. In this file there is no visible confirmation, warning, comment, or descriptive disclosure informing users that patient data will be transmitted to third-party services.
This skill handles healthcare scheduling and patient communications while explicitly integrating multiple third-party services including Vapi, Twilio, Google Sheets, Google Calendar, OpenAI, HubSpot, and a PMS API, but the description does not warn users that patient data may be transmitted, stored, and processed across those systems. In a dental/healthcare context, omission of those warnings increases the risk of unsafe deployment, privacy noncompliance, and inadvertent exposure of sensitive patient information.
The workflow set includes automated reminders, no-show follow-up, waitlist outreach, recall campaigns, and SMS reply handling, but the description does not warn about the compliance, consent, and misdelivery risks of automated outbound patient communications. In healthcare operations, missing warnings can lead to unauthorized or mistargeted reminders and recall messages that disclose appointment status or treatment relationships to unintended recipients.
The workflow logs caller and patient-related data such as phone number, name, intent, duration, and summary into Google Sheets, an external SaaS store, without any visible consent, minimization, retention, or access-control safeguards in this file. In a dental receptionist context, this can expose regulated health-adjacent information and increase privacy/compliance risk if the sheet is broadly shared or retained indefinitely.
The workflow forwards the full normalized call object, including raw payload, transcript/summary, caller identity fields, and extracted appointment details, to downstream webhooks over HTTP requests. In this skill context, those downstream services may process patient communications and scheduling data, so broad forwarding without minimization or visible disclosure materially increases the attack surface and likelihood of unauthorized exposure.
The workflow exposes a booking webhook at a predictable path and shows no authentication, signature verification, IP allowlisting, secret token, or other invocation constraint before processing patient-supplied data. In this context, an unauthenticated public endpoint can be abused to create fraudulent appointments, spam downstream systems, and inject PHI/PII into calendars, sheets, SMS, email, and PMS integrations.
This JSON manifest defines an automatic hourly schedule trigger, but provides no accompanying description of constraints, exclusions, or narrower invocation scope beyond the generic node name and type. For manifest files, missing specificity on when the skill should activate versus not activate can cause unintended executions.
The generated SMS and voice messages explicitly format appointment dates and times using the 'en-US' locale in user-facing content. This imposes a specific language/locale choice without any evidence of user selection, opt-in, or documented region-specific justification.
This manifest-style JSON defines activation as a daily scheduled run 'After Clinic Hours' without any narrowing conditions in the trigger itself beyond time. For SQP-1, manifest files should avoid ambiguous activation scope; here the workflow description does not state exclusions, safeguards, or negative cases for when the follow-up should not run.
The webhook accepts unauthenticated input and the parser defaults missing or malformed requests to action='cancel', which can drive cancellation-side effects without explicit authorization or validation. In this dental context, an attacker could submit forged requests to cancel appointments, delete calendar events, trigger patient/staff notifications, and initiate waitlist outreach, causing operational disruption and privacy issues.
This JSON workflow identifies the skill by name but does not describe when it should be invoked or what exact requests are in scope. For manifest files, missing specificity about activation conditions can lead to overly broad or unintended invocation behavior.
The workflow sends automated recall SMS and voice messages to patients without any language preference handling and appears to rely only on a recall-specific opt-out flag, not explicit communication consent. In a healthcare context, this can lead to unauthorized or misunderstood outreach containing sensitive treatment-context information, creating privacy, compliance, and patient-safety risk.
The workflow exposes a publicly reachable POST webhook for handling patient FAQ requests, but the file shows no authentication, signature verification, shared secret, IP allowlisting, or other trigger constraints. Because the endpoint can trigger SMS sending, AI processing, escalation requests, and logging of caller-supplied data, an attacker could abuse it for spam, cost amplification, bogus PHI injection, or workflow disruption.
The natural-language instruction says "Answer patient questions accurately and helpfully" and specifies response style, but all clinic and answer content is implicitly fixed in English with no opt-in or multilingual handling despite serving patient communications. That creates a language/locale policy concern because the workflow sends patient-facing SMS answers in a single language without offering the user a choice or documenting a justified locale restriction.
This JSON workflow file is a manifest-type file, so vague-trigger checks apply. The workflow exposes a webhook endpoint for escalation, but the file provides no natural-language constraints, allowed invocation conditions, or exclusion cases clarifying when escalation should or should not be triggered, which can lead to overly broad activation by upstream systems.
The system prompt instructs the model to generate a call summary in a specific language style ('Generate a concise, professional call summary for the front desk staff') and all surrounding output content is fixed in English, with no user opt-in or locale-selection mechanism. This is a language/locale policy concern because callers and staff may operate in other languages, yet the workflow hardcodes one locale implicitly.
The workflow exposes a POST webhook endpoint for CRM sync without any visible authentication, signature verification, IP allowlisting, or other trigger constraints. Because the webhook directly normalizes attacker-controlled input and propagates it into Google Sheets, HubSpot, and the PMS, an unauthorized caller could inject or overwrite patient/contact records and trigger downstream data syncs.
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.
{
"parameters": {
"method": "POST",
"url": "https://api.hubapi.com/crm/v3/objects/contacts",
"sendHeaders": true,
"headerParameters": {
"parameters": [
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.
{
"parameters": {
"method": "POST",
"url": "https://api.hubapi.com/crm/v3/objects/contacts",
"sendHeaders": true,
"headerParameters": {
"parameters": [
The workflow accesses HUBSPOT_API_KEY and PMS_API_KEY from environment variables and uses them to authorize outbound requests. Although secret usage itself is expected, this file does not include any warning or description that credential-backed external synchronization is occurring.
The email steps send a generated report derived from call logs, appointments, and escalations to recipient addresses from environment variables, which is a network transmission of potentially sensitive operational data. In this file there is no accompanying warning, confirmation, or user-facing disclosure that report contents will be emailed externally via SMTP.
The workflow performs an HTTP POST to a cancellation webhook containing patient phone numbers and cancellation metadata. In this JSON file there is no visible warning, comment, or other disclosure that inbound SMS replies will trigger backend transmission of patient data to another system.
No suspicious patterns detected.