Security Architecture

Last updated: October 7, 2026

Security by architecture, not by promise. Parselex is built on a Zero-Trust mesh network designed for the ethical and compliance requirements of legal practice. This page describes the concrete mechanisms that protect attorney-client privileged data — what our architecture does, and what it deliberately leaves to the user.

1. Network Isolation (LexConnect)

Parselex workspaces do not exist on the public internet. Access is brokered exclusively through LexConnect, our Zero-Trust network client, which establishes an encrypted mesh tunnel between an authenticated device and the workspace. Our inference nodes carry no public IP addresses, which renders them invisible to internet-wide scanning and DDoS activity. There are no exposed ports and no shared entry points: every connection is a point-to-point encrypted tunnel, and access rights follow the least-privilege principle.

2. Edge-Side PII Redaction (the Ethics Firewall)

Before a document leaves your device, the LexConnect client can strip personally identifiable information and replace it with deterministic tokens: a client name becomes [PERSON_1], a counterparty becomes [ENTITY_A], and identifiers such as a social-security or bank account number become [REDACTED_SSN] or [REDACTED_ACCOUNT]. Only the sanitized text enters the encrypted tunnel, so our inference engines reason over the structure and logic of a matter without ever seeing the confidential identities behind it. On the return path, the client re-assembles the original identities locally, and the finished document is displayed complete.

Because identities are redacted at the edge, servers process sanitized tokens rather than personal data. This design supports the “reasonable efforts” standard that professional conduct rules expect when confidential client information is handled, and it reduces the data-protection exposure of the firm when working under regimes such as the GDPR or the CCPA. A customized dictionary of entity tags (for example, marking one party as [CLIENT] and another as [OPPOSING_COUNSEL]) preserves the distinctions the AI needs to produce correct work product.

3. Data Sovereignty and Ephemeral Processing

Your case files never train a public model — period. Prompts and documents are processed in ephemeral sessions: the working context exists in memory for the duration of the session and is discarded when the session closes. We do not log the content of prompts, and we do not retain documents after processing. Your firm’s intellectual property remains your firm’s intellectual property.

4. Device Posture and Identity

Access requires more than a password. The LexConnect client verifies device health, enforces single sign-on with multi-factor authentication (including Microsoft Entra ID and Okta), and severs the tunnel automatically if a device fails a posture check, connects from an untrusted network, or appears from an unauthorized jurisdiction. Sessions are ephemeral by design: closing the client tears the tunnel down.

5. Access Auditing Without Content Logging

For security monitoring and billing we record who connected, from what class of device, and when. We do not record the payload. Connection metadata and session content are cryptographically separated, so an access log can never be replayed into a transcript of privileged work.

6. Our Threat Model

We publish what our architecture protects against — and what remains the user’s responsibility — because transparency is worth more than a badge.

Protected against:

• Man-in-the-middle interception of traffic between the client and the workspace;
• Passive network or ISP observation of document content;
• Internet-wide scanning and DDoS against inference infrastructure (no public endpoints);
• Public-cloud data scraping, because workspace content is not hosted on shared public cloud services;
• Unauthorized outbound calls from the AI client to third-party services, blocked at the DNS layer.

Outside our control (user responsibility):

• A device left unlocked and unattended;
• A compromised operating system or malware on the lawyer’s endpoint;
• Phishing of a lawyer’s firm credentials (mitigated, not eliminated, by multi-factor authentication);
• Authorized insiders acting within their permissions;
• Screen capture or photography of the display by a person with lawful access.

7. The LexConnect Client

LexConnect signs in against a firm workspace, verifies the device, and maintains the encrypted tunnel while Parselex is in use. It applies DNS-layer filtering to prevent accidental exfiltration to unauthorized third-party APIs, and it tears the session down the moment a policy is violated. For solo practitioners and small firms, Parselex is being extended to support bring-your-own-infrastructure deployment: the workspace runs in the firm’s own cloud account and LexConnect provides the secure overlay, so data sovereignty does not depend on our hosting at all.

8. Security Questions

To report a vulnerability, request our security documentation, or raise a question about this page, write to contact@parselex.app. We treat responsible disclosure reports with priority and acknowledge every report.