Security & Local Processing

Local-first promise

LocalPrivate Tools is built around a simple rule: private file work should happen in your browser, not on our content-processing servers.

This page explains what that means in practical terms and how users can verify the boundary.

What is processed locally

• PII scanning, review, redaction previews, redacted file generation, and risk reports.
• CSV, TSV, JSONL, Parquet, and spreadsheet analysis workflows where browser support is sufficient.
• Document parsing, local search, chunks, embeddings, local AI context, citations, and review reports.
• Temporary worker state and in-memory indexes used during a session.

Allowed network requests

No-upload does not mean the product never connects to the internet. It means user content is not sent out for processing. The following requests may still occur:

• Website pages, scripts, styles, fonts, images, and other static assets.
• WASM files, model weights, model manifests, hashes, and example files from the assets domain.
• Account authentication, license activation, license status sync, device management, and free quota metadata.
• Creem checkout, payment, invoice, refund, and chargeback flows.
• Main-site analytics for public website pages only, not App workspace behavior or user content.
• User-reviewed manual support or error reports if the user chooses to send them.

Data that must not be uploaded by the App

• User files, file paths, parsed text, document body text, SQL query text, SQL output, and cleaned datasets.
• PII match raw values, redaction previews, full risk report bodies, redacted files, and exported review reports.
• Document chunks, embeddings, prompts, answers, citations, Q&A context, and local model context.

Local storage boundary

The App may store non-content settings and product resources locally. Examples include license metadata, preferences, browser capability state, cached WASM files, cached model weights, and user-approved non-sensitive templates.

Sensitive session content should be memory-only by default. If a future feature persists sensitive content, it must be explicit, opt-in, and easy to clear.

Security limits

Local processing reduces content exposure, but it does not make a device secure by itself. Users are still responsible for device security, browser profile security, downloaded files, shared computers, browser extensions, malware, and files they choose to export or send elsewhere.

How to verify the no-upload boundary

• Open browser DevTools and clear the Network log.
• Load the App workspace and drag in a representative private file.
• Run the relevant scan, query, redaction, document review, or local AI workflow.
• Confirm that requests are limited to static assets, model or WASM downloads, account, license, payment, or non-content metadata.
• Confirm that file content, parsed text, SQL results, PII raw values, chunks, embeddings, prompts, answers, and reports are not sent in request payloads.

Reporting security issues

Before launch, add a security contact email and vulnerability disclosure process here. Do not include private customer files in security reports unless support explicitly requests a safe minimal reproduction.