Aletheia Privacy Notice

Effective: 2026-10-09. Last updated: 2026-10-09.

Arbiter Security ("we", "us") provides Aletheia, a local-first binary reverse-engineering and vulnerability-research product. This notice applies to the Aletheia desktop application, cloud bridge, account and billing surfaces, and product support.

Data we process

Do not send binaries, proof bytes, credentials or exploit details through an ordinary support email unless support has provided an approved secure channel.

Why we process data

We process data to provide and secure the service, authenticate users, enforce tenant isolation and quotas, perform requested analysis, maintain machine-checkable evidence, bill customers, respond to support and security requests, and improve reliability. Depending on location and context, the legal basis is performance of a contract, legitimate interests in operating and securing the service, compliance with legal obligations, or consent where required.

Local-first and cloud processing

Production analysis requires the signed desktop and Docker. A selected binary is encrypted in an OS-keychain-bound local vault. It is decrypted only into an owner-only ephemeral session directory immediately before a signed, pinned, networkless local worker starts, and the plaintext is removed when that worker terminates. The browser product cannot upload or analyze binaries by itself.

The cloud control plane receives the binary hash and bounded operational metadata needed for authentication, orchestration, continuation, synchronization, and proof management. Original customer files are processed locally; analysis consent does not authorize original-file upload. The dedicated original-file upload routes remain disabled. This restriction is distinct from the sensitive information that may appear in consented derived text, described below.

Aletheia v1.4.17 requires explicit consent before each new or resumed cloud-backed analysis. Consent is scoped to the account, device, binary and run and identifies the provider and destinations receiving the derived context. Declining cancels startup; it does not select an equivalent offline mode. Provider or destination changes require renewed consent before further export. Routine account, billing and update traffic is separate from analysis consent.

Saved-session restore requires fresh consent. Transparent connection recovery may continue only the same live analysis, grant and destinations within the original one-hour consent deadline. Recovery renews the transport connection, not consent; a stopped analysis cannot resume automatically. Revoked consent cannot resume through reconnection.

Consented context may include recovered strings, function names and decompiled text, together with selected findings and other readable derived output. It may contain sensitive or proprietary material, including secrets embedded in the analysed file. We cannot promise to identify or remove every embedded secret. Consider the sensitivity of the selected file, your authority to share derived context and the listed destinations before consenting; future derived output may not yet be known. This disclosure is separate from application authentication and provider credentials: those are used only through their authentication controls, are not supplied as analysis metadata and are not exported as analysis context.

The selected file's native host path and display name are not supplied as cloud metadata or context. Existing filters for named fields and common path patterns remain in place. They do not guarantee removal of all filenames, paths or credentials embedded in recovered text. Proof-byte export requires separate native approval; analysis consent does not grant it or permit worker-originated artifact uploads.

Analysis consent does not authorize analytics, diagnostic or operational logging of the context. The exclusions for customer content in logs, metrics, traces, PostHog events and Sentry reports remain. The selected model provider may receive prompts and consented derived context; provider choice and zero-data-retention requirements remain subject to deployment and session policy where configured. Provider retention and terms are separate from Aletheia's evidence retention.

Aletheia v1.4.17 requires separate approval for each prepared Workbench agent. The native prompt names the local agent and warns about its downstream services. Aletheia internally ties the approval to the prepared recipient's session, executable and launch configuration and to the active analysis consent; those technical identifiers are not displayed in the prompt. Derived results shared with that agent may reach services selected in that agent's own configuration. Aletheia does not control those downstream provider choices. Restarting or changing the recipient requires fresh approval. This approval does not grant additional tool or host execution authority. Connection interruption stops the managed Workbench recipient; restart and review it again after the analysis reconnects. This does not close ordinary host-shell tabs. Withdrawal also stops the managed recipient as far as the native supervisor controls it, but cannot recall data already sent to that agent or its providers.

Withdrawal stops future transmissions and work for the consented analysis. It does not erase previous cloud or provider records, or recall requests already submitted. Use the existing controls to delete or purge Aletheia evidence; provider records remain subject to the provider's controls and retention terms.

Service providers

We use service providers for authentication (Clerk), billing (Stripe), hosting and database infrastructure, selected model inference, opt-out product analytics (PostHog), and privacy-limited error reporting (Sentry). Providers may process data in other countries under their contractual transfer safeguards.

We do not sell customer data. Arbiter Security does not use customer binaries to train models. Processing by a user-selected model provider is governed by that provider's terms. We do not permit advertising profiling from binary-analysis content.

Retention and deletion

Local plaintext analysis copies are ephemeral. Derived cloud evidence expires after 30 days. Users can export or delete individual runs and purge Aletheia account data from Settings. In the signed desktop, account purge first stops local analysis and deletes the encrypted local vault, crash-leftover plaintext, and native vault/device keys. The cloud then cancels an active Aletheia subscription, disconnects local nodes, deletes enrolled device identities, enrollment authority, evidence and API keys, and anonymizes the service identity. A browser can perform the cloud portion but cannot erase a vault on an offline desktop; that local vault must be purged from the desktop.

Payment records required for tax, accounting, fraud prevention or dispute handling are retained as a documented exception. Encrypted backups age out within 30 days; deleted data is not returned to active service after restoration.

See Data retention and Data deletion and export for exact operational rules.

Security

We use authenticated tenant boundaries, least-privilege service roles, encrypted transport, signed desktop updates, a pinned networkless local Docker worker, ephemeral local plaintext storage, database-backed purge fences, and auditable evidence/proof records. No security measure eliminates all risk. Report suspected issues using the security disclosure process.

Your choices and rights

Depending on applicable law, users may request access, correction, export, restriction, objection or deletion. Product analytics can be disabled in Settings. Individual evidence runs can be exported or deleted without closing the account. Requests can be sent to [email protected]; identity may need to be verified before action is taken.

Contact and changes

Privacy questions: [email protected].

We will date material changes and provide notice where required. A new use of customer binaries or analysis content requires a policy update and product review before deployment.