Technical Verification Report: Outbound Logic Data Privacy & Boundary Egress Testing

Download Audit Harness ↓[ Schedule Demo ]

Date: November 3, 2026

System Under Test: Outbound Logic v1.5.2 (Hosted Web Application & External Relay Daemon)

Target Environment: Lovable Cloud → DigitalOcean Ubuntu VPS (HTTPS Boundary)

Audit Status: Live Wire Inspection Complete · 48 Kernel Claims Verified

1. Executive Summary

This report documents the live network verification and architectural testing performed on Outbound Logic v1.5.2.

The primary goal was to verify whether raw personal contact details (names, personal emails, direct phone numbers, and notes containing contact info) are successfully removed and replaced with synthetic placeholders before data crosses from the core application to an external server over the public internet.

To test this under real conditions rather than relying on internal mocks:

1. An inspection probe was placed directly on a live external server (DigitalOcean VPS) to log every byte received over HTTPS.

2. A synthetic dataset of 50 business leads with full contact information and embedded notes was fed into the system.

3. Over 100 dispatches were transmitted across the internet to the receiving daemon.

4. An automated scan of the raw server logs confirmed that 0 raw emails and 0 raw phone numbers appeared in the diagnostic payloads received over the wire. All personal identifiers were replaced with structured placeholders.

2. System Architecture & Testing Boundaries

Outbound Logic is structured into three distinct boundaries:

1. Client / Browser Layer (Data Ingestion & Sanitization):

• Ingests raw prospect files (CSV or JSON).

• Scans every field (first name, last name, company, email, phone, city, postal code, and unstructured notes).

• Maps raw values into a local secure vault and substitutes them with deterministic placeholders (e.g., [FIRST_NAME_01], [EMAIL_01], [CORP_01], [PHONE_01]).

2. Application Server Layer (Egress Hard Gate):

• Sits between the web application and external network requests.

• Evaluates outgoing payloads with zero-tolerance regex scans (detectPayloadPii).

• Rejects any payload that contains unmasked email addresses or phone patterns before it can leave the server.

3. External Relay Daemon (DigitalOcean Linux VPS):

• Python-based service (outbound_logic_bridge_v2.py) listening for authenticated HTTPS webhooks.

• Verifies incoming payloads using HMAC-SHA256 signatures.

3. Test Methodology: Step-by-Step

Step 1: Instrumenting the Receiving Server

To verify what actually travels across the wire, a packet logging tap was temporarily injected into the external VPS daemon's receipt handler:

# Temporary capture logger on VPS daemon

with open("/opt/logic-bridge/captured_dispatches.jsonl", "a", encoding="utf-8") as f_dump:

    f_dump.write(json.dumps({"boundary": "ol-to-bridge", "body": data}) + "\n")

Every incoming HTTPS request payload verified by the daemon was appended directly to disk in JSON Lines (.jsonl) format.

Step 2: Batch Lead Ingestion

A test batch of 50 synthetic prospect records was generated. Each record contained:

• Realistic full names and company affiliations.

• Realistically formatted corporate and personal email addresses.

• Direct phone numbers formatted in various standard telephone formats.

• Freeform unstructured notes intentionally embedding secondary emails and mobile numbers (e.g., "Reached John Doe at john@example.com, cell 415-555-0199. Running 6 locations near 94103.").

The batch was uploaded to the Outbound Logic console, mapped, and passed through the tokenization engine.

Step 3: Live Wire Transmission

The sanitized lead batch was queued and dispatched across the public web to the VPS endpoint. The queue was executed through sequential authenticated HTTPS POST calls, resulting in over 100 outbound dispatches.

4. Findings & Wire Inspection Results

Raw Wire Inspection

An independent regex analysis script was executed directly on the DigitalOcean VPS to inspect the captured JSONL file (/opt/logic-bridge/captured_dispatches.jsonl):

Total Dispatches Inspected: 103

Raw Emails on Wire:         0

Raw Phones on Wire:         0

Result:                     100% TOKENIZED PLACEHOLDERS

• Names and Companies: Fully converted to [FIRST_NAME_XX], [LAST_NAME_XX], and [CORP_XX].

• Primary Emails & Phones: Replaced with [EMAIL_XX] and [PHONE_XX].

• Embedded Contact Info in Notes: Secondary phone numbers and email addresses embedded inside unstructured sentences were successfully caught by the pattern scanner and tokenized.

Edge Case Discovered & Resolved

During the multi-batch run, 1 dispatch out of 51 was halted by the server-side egress gate with the error: "Blocked: 1 PII pattern(s) detected in payload"

• Root Cause: A random tracking UUID (leadId: 5acf6620-6728-4f3a-a2ce-136876911081) ended with a 12-digit numeric sequence. Because the initial egress gate evaluated the entire JSON envelope as raw text, the trailing digits matched the phone number regex filter, triggering a false positive.

• Resolution: The engine was updated (detectPayloadPii) to drop opaque machine tracking keys (leadId, jobId, workspaceId) and standard UUID strings from the regex scan, while preserving strict pattern checks on all prospect content.

• Verification: The exact UUID was re-tested through the updated gate and passed with an HTTP 200 acknowledgment. Injecting an unmasked phone number or email into the payload immediately triggered the gate and blocked transmission.

5. Scope and Limitations (What This Proves vs. Does Not Prove)

In the interest of rigorous and honest engineering:

• What is proven: For diagnostic dispatches sent over the public internet between Outbound Logic and the external VPS daemon, no unmasked customer email addresses or telephone numbers crossed the wire. All prospect data arrived as synthetic placeholders.

• What is outside this specific test's scope:

• This test evaluated diagnostic event delivery (daemon.ping). It did not execute live SMTP/IMAP email delivery to mailbox providers.

• When live campaigns are dispatched, the secure rehydration vault is transmitted over authenticated channels so the relay can send actual emails to recipients.

• The external relay daemon acts solely as a communication bridge; it does not make outbound API calls to third-party LLM providers.

6. How to Run the Verification Yourself

You do not need access to our production servers, API keys, or database accounts to verify the core privacy and rules engine. We provide an offline, deterministic audit harness containing 48 independent automated verification checks.

Prerequisites

• Node.js 20 or higher

• Standard package manager (npm)

Execution Instructions

1. Download the audit package (outbound-logic-audit.zip) referenced in this report.

2. Unzip the file and enter the directory:unzip outbound-logic-audit.zip -d outbound-logic-audit

cd outbound-logic-audit

3. Install dependencies and run the audit suite:npm install

npm run test:audit

Core Verified Claims in the Suite

• C1.1: Names, emails, and phone numbers are stripped from outbound payloads.

• C1.2: Campaigns leaking real addresses in subject lines or bodies are refused.

• C1.3: Unapproved campaigns are rejected by schema enforcement.

• C1.4: Machine tracking UUIDs do not trigger false leak alarms; real PII always triggers a block.

• C2.1 & C2.2: Cryptographic HMAC-SHA256 signatures validate message integrity; tampered bytes or invalid keys are immediately rejected.

• C3.1–C3.3: Unsubscribe requests permanently purge recipient contact across all linked brands and prevent re-entry.

• C4.1–C4.6: Strict cadence controls enforce 48 business-hour buffers, weekend blackouts, local time sending windows (08:00–17:00), and daily mailbox volume caps.

• C5.1 & C5.2: Hard safety locks enforce pricing floors and freeze prohibited content.