PHASE 1 — Workflow Reconstruction Logical workflow: Customer ↓ Support Form ↓ Webhook ↓ CRM API ↓ Merge Customer + Support Data ↓ Data Filtering ↓ AI Summarization ↓ Zendesk Ticket ↓ Urgency Check ↓ If Urgent → Slack If Not Urgent → End Confirmed paths: Path A: Form → Webhook → CRM → AI → Zendesk Path B: Form → Webhook → CRM → AI → Zendesk → Slack Potential persistence: n8n execution history Error/retry paths: Not provided in the input. Therefore, error and retry lineage is Unknown, not assumed safe. --- PHASE 2 — Data Source Inventory Source Data Sensitivity Purpose Support Form Name, email, message, order ID Customer-sensitive Create support request CRM Customer ID, name, email Personal/customer data Enrich support request Classification confidence: Confirmed: customer name, email, ID and support content are customer-related. Exact regulatory classification: Unknown because no compliance framework was provided. --- PHASE 3 — Data Element Reconstruction Data Element Classification Initial Source Customer name Personal data Form/CRM Email Personal data Form/CRM Customer ID Customer-sensitive CRM Support message Customer-sensitive Form Order ID Business/customer-sensitive Form Important observation: The AI summarization step does not necessarily require: Customer email Customer ID Full CRM profile Therefore, these fields should be removed before the AI boundary unless the workflow explicitly requires them. --- PHASE 4 — Source-to-Destination Lineage Customer Name Support Form → Webhook → CRM Merge → AI [if entire payload is passed] → Zendesk → Slack [potentially if entire ticket/payload is forwarded] Status: Partially confirmed. The workflow says CRM data is merged and AI summarizes the issue, but the exact AI payload and Slack payload are not provided. --- Customer Email Support Form → Webhook → CRM → Workflow Payload → Zendesk Slack should receive: NO EMAIL Expected minimized path: Support Form → Webhook → CRM → Zendesk Finding: Sending email to Slack would violate the stated minimization constraint. --- Support Message Support Form → Webhook → AI → Summary → Zendesk → Slack if urgent The transformation from original message → AI summary can reduce the amount of customer content propagated downstream. --- PHASE 5 — Transformation & Propagation Analysis Merge Form Data + CRM Data ↓ Combined Workflow Object Risk: The combined object may contain more information than downstream steps require. AI Summarization Full Support Message ↓ AI ↓ Short Summary Positive effect: Can reduce downstream data volume. Risk: Sensitive information may remain inside the generated summary. AI input scope must be explicitly controlled. --- PHASE 6 — Tool/API Transfer Audit Destination Required Data Risk CRM API Customer identifier Low AI API Support content only Medium Zendesk API Ticket + necessary customer details Low Slack API Summary + operational information Medium Potential issue If the workflow sends: { name, email, customer_id, order_id, support_message, crm_profile, ... } to the AI model, that is a data-minimization failure. Preferred: { support_message } --- PHASE 7 — Database & Storage Lineage n8n Execution History Potential lineage: Webhook → Combined Payload → CRM Response → AI Input → AI Output → Zendesk Request → Slack Request Risk: Execution history may become an unintended secondary storage destination. Status: Potential/Unknown because retention configuration was not supplied. Recommended control Configure execution-data retention and avoid storing sensitive payloads where operationally unnecessary. --- PHASE 8 — AI Agent Data-Flow Audit Current suspected AI input Merged Form + CRM Payload Required AI input Support Message + Minimal context required for summarization Finding 🟠 High — Excessive AI Data Exposure Affected data: Email Customer ID Potential CRM fields Root cause: Passing the merged object instead of an explicit AI input schema. Recommended architecture: CRM/Form Data ↓ Allowlist Filter ↓ support_message ↓ AI ↓ summary --- PHASE 9 — Validation & Minimization Audit Webhook Check: Schema validation Required fields Data types Authentication CRM API Check: Customer ID validation Authorization Returned-field allowlist AI Check: Explicit input schema Sensitive-field removal Output validation Zendesk Check: Allowed ticket fields API authorization No unnecessary CRM data Slack Check: Allowed: - Ticket ID - Urgency - AI summary Blocked: - Customer email - Unnecessary CRM profile - Credentials/secrets --- PHASE 10 — Hidden Exposure Analysis Finding 1: Broad Payload Forwarding Severity: 🟠 High If the workflow forwards the complete merged object to multiple nodes, one source record can propagate into: CRM → AI → Zendesk → Slack → n8n Execution History Blast radius: Multiple systems. Verification: Use a synthetic record containing unique markers: EMAIL = synthetic@example.test CUSTOMER_ID = TEST-001 MESSAGE = "LINEAGE-TEST-ABC" Then inspect only authorized workflow outputs and execution metadata. --- Finding 2: Slack Data Leakage Severity: 🟠 High The stated requirement explicitly prohibits customer email from reaching Slack. Verification: Use: EMAIL = synthetic@example.test Trigger an urgent ticket and inspect the Slack message. Pass: Email absent. Fail: Email appears anywhere in the Slack notification. --- PHASE 11 — Trust-Boundary Map Customer | | Customer Data ↓ Support Form | ↓ Automation Platform | | Customer Data ↓ CRM | | Minimized Support Content ↓ AI Provider | | Summary ↓ Zendesk | | Operational Summary ↓ Slack Critical boundaries 1. Automation platform → CRM 2. Automation platform → AI provider 3. Automation platform → Zendesk 4. Automation platform → Slack The AI provider and Slack represent external trust boundaries and require explicit authorization and data-minimization controls. --- PHASE 12 — Data-Lineage Verification Test Plan Test 1 — Field Propagation Test input: Name: Test Customer Email: synthetic@example.test Customer ID: TEST-001 Order ID: ORDER-001 Message: LINEAGE-TEST-ABC Urgency: Normal Expected path: Form → Webhook → CRM → AI → Zendesk Expected AI input: Message: LINEAGE-TEST-ABC Unexpected behavior: Email sent to AI Customer ID sent unnecessarily Full CRM object sent to AI Evidence: Workflow node input/output API request logs AI request payload Zendesk ticket Pass condition: AI receives only the allowlisted fields. --- Test 2 — Urgent Branch Propagation Input: Urgency: Urgent Message: LINEAGE-TEST-URGENT Email: synthetic@example.test Expected path: Form → Webhook → CRM → AI → Zendesk → Slack Expected Slack data: Ticket ID Urgency Summary Unexpected: Email Full customer profile Raw support message when not required Pass condition: Slack contains only approved fields. --- Test 3 — Non-Urgent Branch Input: Urgency: Normal Message: LINEAGE-TEST-NORMAL Expected: Form → CRM → AI → Zendesk → END Pass condition: No Slack request occurs. --- Test 4 — Execution History Input: Message: LINEAGE-TEST-LOG-001 Check: n8n execution history Node input Node output Error data Pass condition: Sensitive fields are not unnecessarily retained beyond the approved retention policy. --- PHASE 13 — Risk Matrix Finding Severity Data Blast Radius Full payload sent to AI 🟠 High Customer + CRM data AI provider Customer email sent to Slack 🟠 High Email Support users/Slack Execution history retains payload 🟡 Medium Workflow data Automation platform Error-path behavior unknown 🟡 Medium Potential workflow payload Unknown Non-urgent branch bypasses Slack 🟢 Low Operational data Limited --- PHASE 14 — Remediation Design High: AI Overexposure Root cause: Full merged payload. Fix: Merged Data → AI Allowlist Filter → Support Message Only → AI Validation: Reject unexpected fields from the AI input object. Monitoring: Alert if prohibited fields appear in AI requests. Regression protection: Automated test asserting: AI payload DOES NOT contain email AI payload DOES NOT contain customer_id --- High: Slack Email Exposure Root cause: Insufficient output filtering. Fix: AI Output → Slack Allowlist → Ticket ID + Urgency + Summary Verification: Synthetic email marker must never appear in Slack. --- PHASE 15 — Target Data-Lineage Architecture Current State Form ↓ Webhook ↓ CRM ↓ Merge Everything ↓ AI ↓ Zendesk ↓ Slack Target State Form ↓ Schema Validation ↓ CRM ↓ Field Allowlist ├──────────────→ Zendesk Customer Fields │ ↓ AI-Minimization Boundary ↓ Support Message Only ↓ AI Summary ↓ Zendesk ↓ Urgency Check ↓ Slack Allowlist ↓ Ticket ID + Urgency + Summary Target controls Field allowlisting Schema validation AI input minimization Slack output filtering API authorization Execution-data retention controls Synthetic lineage testing Branch-level regression tests --- PHASE 16 — FINAL AUDIT REPORT 1. 🎯 Executive Summary The workflow has a legitimate business purpose, but the primary risk is excessive data propagation across trust boundaries. The most important control is to prevent the merged customer/CRM payload from being automatically forwarded to the AI and Slack steps. 2. 🧬 Data Sources Support form CRM 3. 🗺️ Data-Flow Map Form → Webhook → CRM → Field Filter → AI → Zendesk → Urgency Branch → Slack 4. 📋 Key Data Lineage Field AI Zendesk Slack Name No Yes, if required No Email No Yes, if required No Customer ID No Yes No Order ID Only if needed Yes No Support Message Yes As required Prefer summary AI Summary N/A Yes Yes 5. 🚨 Highest-Priority Risks 1. 🟠 High: Excessive payload sent to AI. 2. 🟠 High: Customer email could propagate to Slack. 3. 🟡 Medium: Execution-history retention is undefined. 4. 🟡 Medium: Error/retry lineage is not supplied. 6. 🛠️ Priority Remediation ALLOWLIST ↓ MINIMIZE ↓ VALIDATE ↓ AUTHORIZE ↓ TRANSFER ↓ LOG/MONITOR 7. 🧪 Final Verification The workflow should not be considered fully verified until synthetic records demonstrate that: AI receives only required fields. Slack receives only approved fields. Non-urgent records never reach Slack. Sensitive fields do not appear unnecessarily in execution history. Error and retry paths do not create additional uncontrolled destinations. Every external transfer has an explicit business purpose and authorized destination. Evidence limitation: The sample input does not provide actual node configurations, API payloads, execution logs, retention settings, or error/retry definitions. Therefore, those areas are marked Unknown/Suspected, rather than being treated as confirmed findings.