Privacy & Compliance

Privacy Policy

How Exit Protocol collects, processes, retains, discloses, and handles deletion requests for financial, communication, and case data.

Exit Protocol ("we," "our," or "us") is committed to protecting the privacy and confidentiality of your data when you use the Exit Protocol forensic intelligence platform.

Effective: July 17, 2026 Model-training boundary No data sales
Application-Layer Encryption Scope Evidence files and selected financial fields use application-layer encryption. Generated report files, logs, metadata, backups, and other records depend on deployment controls and are not covered by that field-level statement.
AI Boundaries Core forensic calculations are deterministic and separate from AI-assisted tools.
Deletion Path Deletion requests use the privacy/legal contact process; retention and backup handling depend on the verified production deployment.
Jump to a section

1. Information We Collect

1.1 Account Information

When you create an account, we collect your email address and a hashed password. We do not store passwords in plaintext.

1.2 Financial Data

Through direct file upload (PDF bank statements, financial discovery documents), the user-authorized Clio integration, or manual entry, we receive financial transaction records, account balances, and related data necessary to execute forensic tracing protocols. This includes dates, descriptions, debit/credit amounts, and running balances extracted through structured parsing, native PDF text extraction where available, and OCR review.

1.3 Communications Data

If you use the communication analysis features (Response Shield, Claim Risk Analytics, case messages), we process message text you provide for sentiment analysis and tone rewriting. Submitted messages and generated analyses may be stored within the active case or communication workflow according to the applicable retention and deletion controls. Configured AI providers may receive selected text when the user invokes an AI-assisted feature.

1.4 Uploaded Evidence & Document Metadata

Documents uploaded to the Evidence Vault are encrypted at rest and assigned a SHA-256 integrity reference. A later comparison can detect byte changes; the hash does not authenticate origin or establish legal chain of custody by itself. When the Shadow Report module is used, we also extract and analyze document metadata including:

  • XMP Metadata: Author, producer software, creation/modification timestamps embedded in the PDF structure.
  • EXIF Data: GPS coordinates, camera models, and image creation dates from embedded images (extracted via Pillow).
  • Ghost Text Layers: Hidden, unsearchable text beneath redaction blocks in improperly flattened PDFs.

This metadata is processed solely for the purpose of providing the Shadow Report analysis and is stored within your case context.

1.5 Automatically Collected Data

We collect standard server logs including IP address, browser type, device information, and access timestamps for security monitoring and platform performance.

1.6 Demo Sandbox Data

Seeded case and ledger records are synthetic. The service still receives ordinary request and session data, including IP address, browser details, and access timestamps, plus anything a user enters or uploads. Do not submit personal information or real financial records in the sandbox.

2. How We Use Your Data

Purpose Data Used Processing Type
LIBR forensic tracing Financial transactions, account balances Deterministic
Document extraction candidates Selected PDF or image bytes and candidate transaction rows Native parsing; configured local or external OCR; human review required
Recorded relationship and flow mapping Imported account, transaction, description, date, and amount fields Local grouping and heuristic review signals
Recorded case alert display Stored alert rows created by an authorized batch process, administrator, or synthetic demo seed Local display; not a live bank-monitoring feed
Optional contradiction review Selected transaction date, amount, description, and nearby communication text and sender metadata Configured external model when the user starts the review; preliminary signal only
Tone Review & BIFF analysis Communication text Configured external model when invoked; generated draft may be stored
Optional case-summary drafting where separately enabled Selected grounded case fields, source references, and timeline records Local record assembly; external model only after feature-specific acknowledgement
Shadow Report Document structure, XMP metadata, EXIF data Deterministic
Evidence integrity verification SHA-256 references for eligible received or generated file bytes Deterministic exact-byte comparison
Account authentication Email, hashed password Standard
Security monitoring IP addresses, access logs Standard
Exit Protocol does not currently monetize personal information or case data through sale to data brokers or targeted-advertising platforms. Disclosures to configured service providers and legally required recipients are described below.

3. Data Processing Methods

3.1 Deterministic and Local Processing

The core LIBR calculation applies fixed decimal rules to reviewed ledger rows and explicit source records. SHA-256 comparisons, recorded-relationship grouping, and configured rule checks can also run locally without a generative model. Relationship and alert heuristics do not establish a person's identity, account ownership, concealment, wrongdoing, or a legal conclusion.

Optional contradiction review, communication scoring or rewriting, and separately enabled narrative drafting are outside the deterministic LIBR core. Depending on the feature and deployment, selected communication text, transaction fields, or grounded case-summary fields may be transmitted to a configured external model provider. These outputs are probabilistic review aids and require professional review.

3.2 Asynchronous Processing

Processing may occur in the web process or in configured background workers depending on the feature and deployment. The interface must report completion or failure; a queued task should not be treated as a completed extraction, calculation, or export.

3.3 Document Extraction Pipeline

When you upload PDF bank statements, the platform first attempts native PDF text extraction where the file structure allows it. Extracted rows are presented for human review before import. For scanned or degraded pages, a local OCR runtime may be used only when configured in your deployment; it is not required for pilot operation on text-based PDFs. Optional cloud OCR via Azure Document Intelligence is available only when explicitly enabled by your deployment or account configuration, with acknowledgement that selected pages may be transmitted for processing. Upon upload, the parsing core records a SHA-256 integrity reference for the received source bytes so later comparisons can detect changes.

4. Optional AI and OCR Data Boundaries

Provider use depends on the enabled feature and deployment configuration. Current components support these bounded processing paths:

  • Configured external language-model provider — Optional tone rewriting, stored-message scoring, and transaction/message contradiction review. Depending on the invoked feature, the request can include selected communication text, sender and time metadata, transaction date, description, and amount. The exact provider and model are deployment-dependent. These paths are not used in LIBR balance calculations.
  • Separately enabled case-summary drafting — Grounded case fields and source references may be sent to a configured provider only after the applicable feature acknowledgement. The current automated legal-strategy, narrative, and judicial-simulation web routes are retired and fail closed.
  • Local OCR runtime — Optional on-prem OCR for scanned or degraded PDF bank statements when native text extraction is insufficient and the deployment has a local OCR runtime configured.
  • Azure Document Intelligence — Optional cloud OCR sub-processor, used only when explicitly enabled, for structured extraction of tabular data from PDF bank statements.
Exit Protocol does not intentionally use submitted case data to train its own models. Retention and model-training treatment by an optional third-party AI or OCR provider depends on the configured provider account, contract, and settings. Review those terms before enabling an external provider. The core LIBR tracing algorithm is deterministic and does not use AI.

Model-Training Boundary

Legal Process Requests

5. Third-Party Data Sharing

5.1 Clio Manage

When you authenticate via Clio, we receive access and refresh tokens for the permissions configured in the Clio developer application. Connection and staging list accessible matters, read one user-selected matter document, and create a local extraction review job. Those steps do not write to Clio.

Clio Integration Data

Clio access is user-authorized through standard OAuth 2.0 consent. Exit Protocol requests configured matter and document permissions. The current staging path uses matter and document read access. We process only user-selected matters and documents in the integration cockpit. There is no silent workspace sweep or automatic access to other Clio data.

Extraction candidates remain local and non-authoritative until explicit approval. After the user approves the source and finalizes the selected workflow, Exit Protocol generates and saves the local workpaper, then attempts to upload a new PDF workpaper to that selected matter. It does not modify, overwrite, or delete the selected source document. If Clio upload fails, the local report remains and a retry verifies its stored SHA-256 reference before attempting upload to the same staged matter.

Clio OAuth access and refresh tokens are encrypted at rest using industry-standard encryption before storage and are automatically refreshed as needed. Users can disconnect at any time via Exit Protocol or directly in Clio (which revokes token access). Exit Protocol does not currently use client data for targeted advertising or monetize it through data-broker sale.

For Clio-related privacy, data access, revocation, or support requests, contact privacy@exitprotocols.com, legal@exitprotocols.com, or support@exitprotocols.com and reference “Clio integration”.

5.2 Financial Record Imports

The current pilot workflow uses user-selected document and CSV imports. A live Plaid bank-monitoring connection is not part of the current production claim or privacy scope.

5.3 Browser-Loaded and Scheduling Providers

Public and authenticated pages may request libraries or fonts from Google Fonts, jsDelivr, cdnjs, and unpkg. Some public pages use Cal.com for scheduling. Your browser connects directly to those providers, which may receive ordinary request metadata such as IP address, user agent, referring or page URL, and request timing. Information entered in a Cal.com booking is provided to Cal.com. Avoid matter facts and sensitive client details in scheduling fields. Provider processing is governed by their terms, configuration, and applicable privacy notices.

5.4 Current Data-Sale Practice

Exit Protocol does not sell customer case content or use it for targeted advertising. Exit Protocol does not currently monetize personal information or case data by renting, trading, or selling it to data brokers or targeted-advertising platforms. Data may be disclosed to configured processors, security and operations providers, recipients of legally required process, or parties to a business transaction subject to applicable law and notice obligations.

6. Data Retention & Deletion

The application does not currently expose a complete self-service case or account deletion workflow. Deletion requests are reviewed manually against account ownership, legal holds, preservation duties, deployment storage, and security requirements.

Active-record deletion, stored file cleanup, backup retention, and historical orphan-file reconciliation are distinct operations. No universal backup-purge window is promised on this page; the operator must disclose and follow the verified schedule for the applicable production deployment.

You may submit an account or data deletion request by emailing legal@exitprotocols.com. Eligible active records, stored files, backups, and legally preserved material may follow different schedules.

7. Encryption & Security

  • Encryption at Rest: Evidence files and selected financial fields are encrypted at rest using application-layer encryption appropriate to the deployment. This does not mean every database column, generated report PDF, log, metadata record, backup, or underlying storage layer is application-encrypted; verify deployment controls.
  • Integrity References: Uploaded documents receive a SHA-256 reference for the received bytes. A matching later hash indicates identical bytes; it does not authenticate origin, completeness, or legal admissibility.
  • Report Integrity Reference: Generated report bytes receive a SHA-256 reference. Changing the file changes the computed hash, allowing a reviewer to compare it with the authoritative stored report record.
  • Transport Security: Production deployments are expected to use HTTPS/TLS, but protocol versions, proxy termination, certificate renewal, and internal service paths must be verified for the deployed environment.
  • Access Controls: Active case-party memberships and per-case permission flags govern financial, communication, and evidence actions. Case role labels do not create a firm-wide role or organization tenant. An optional profile-level IP/CIDR allowlist can restrict an individual profile's requests when configured. The current product does not provide firm or organization tenant administration, delegated administrators, centralized invitations, or firm-wide offboarding.
  • Audit Logging: Selected application events are recorded in operational audit logs. These records are not represented as a cryptographically immutable or storage-enforced WORM ledger.

8. Self-Hosted Deployment Options

Containerized self-hosted deployment may be available under a separate enterprise agreement. Network isolation, key custody, sub-processors, backups, telemetry, and support access must be defined and validated for the specific deployment. Self-hosting does not automatically make an environment air-gapped or create legal privilege.

  • Document the permitted network egress and external services.
  • Document encryption-key ownership, rotation, recovery, and backup responsibilities.
  • Disable cloud OCR and external AI unless they are expressly approved and configured.
  • Have counsel and security reviewers assess privilege, retention, and regulatory requirements for the matter and jurisdiction.

9. Your Rights

Depending on your jurisdiction, you may have the following rights:

  • Right of Access: Request a copy of the personal data we hold about you.
  • Right to Deletion: Request deletion of eligible personal data and case information, subject to identity and authority verification, applicable retention duties, legal holds, security requirements, backup schedules, and deployment constraints.
  • Right to Portability: Request your data in a structured, commonly used format.
  • Right to Opt-Out: Opt out of non-essential data processing (note: core forensic processing is essential to providing the Service).
  • Right to Correction: Request correction of inaccurate personal data.

To exercise any of these rights, contact us at legal@exitprotocols.com. Identity, authority, scope, applicable law, legal holds, and deployment constraints will be verified before action. Response timing follows applicable law rather than a universal promise on this page.

10. Children's Privacy

Exit Protocol is not intended for use by individuals under the age of 18. We do not knowingly collect personal information directly from minors. If we learn that a minor used the service or that information was submitted without appropriate authority, we will investigate, restrict access as appropriate, and process eligible deletion subject to identity and authority verification, legal holds, preservation duties, security needs, and backup constraints.

11. Cookie Policy

Exit Protocol uses essential session cookies to maintain your login state and CSRF protection. These cookies are strictly necessary for the Service to function and cannot be disabled.

We do not intentionally deploy advertising pixels or cross-site behavioral analytics. Browser-loaded CDN, font, and scheduling providers described in Section 5 still receive ordinary web request metadata and may use cookies or similar storage under their own policies.

12. Data Breach Notification

Security incidents are investigated to determine affected systems, data, users, and legal notification duties. Notices will be provided when and as required by applicable law and verified incident-response procedures. This page does not promise a universal 72-hour email deadline for every event or jurisdiction.

13. Contact Us Regarding This Policy

For questions, data access requests, or if you require an audit of your data footprint, direct inquiries to:

Exit Protocol
Privacy & Compliance

This policy was last updated on January 15, 2026. We will notify you of material changes via the email address associated with your account.

Need a privacy or deletion request handled? Send data access, correction, deletion, or security questions to the privacy inbox.
Contact Privacy