On this page
People connect their most consequential information to software: correspondence, calendars, documents, and unfinished work. A useful personal context system needs access to some of that material. It also needs an account of what happens to it that is precise enough to challenge.
Zortex is built around a local-first premise. Connected information is synchronized into storage on the user's device, where an index helps retrieve relevant records. That gives the user a useful boundary: keeping a working copy and searching it do not, by themselves, require sending the contents of every connected account to an AI provider.
Local storage is the default boundary for the synchronized record. OAuth authorization and a requested handoff to a cloud AI are separate, visible data paths.
The commitments we can state
Our application privacy policy makes specific commitments for Google user data that Zortex handles under its control: no sale, no use for targeted advertising, and no training or improvement of generalized AI or machine-learning models using that data. It also commits Zortex's Google API use and transfers to Google's Limited Use requirements.
These are commitments about what Zortex does with Google information. They are not a substitute for reading the terms of a separate AI provider the user connects. Selected context returned to an assistant can be processed by that provider, including in the cloud. Its retention and processing terms may differ.
The website has its own, separate privacy policy. Reading a journal article is not the same activity as synchronizing Gmail. The website uses server-side visit counts without analytics cookies or third-party advertising pixels. Joining the waitlist involves supplying an email address and confirming it. Neither should be confused with the storage used by the desktop application.
Where the data moves
The usual path begins with an authorization decision. A user chooses a Google account and sees the permissions requested by Google. Authorized records can then be synchronized into the device's local vault and index. When the user asks an assistant for help, Zortex can retrieve a permitted subset and send a result to the assistant host.
Here is the boundary in plain text:
Google account --authorized sync--> Local vault and search index
|
| permitted result, on request
v
Connected AI host
(cloud processing possible)
Explanatory diagram of a data-handling boundary; actual access depends on the service and permissions.
The generated geometric cover is available as a vector illustration.
There is a second path for authorization. The shared Google OAuth configuration uses a Cloudflare-hosted broker to exchange or refresh credentials with Google. Authorization codes, PKCE values and refresh credentials can travel through that broker. The reviewed handler processes credentials rather than mailbox or document contents, but this is still off-device processing. We do not describe it as a connection that never leaves the computer.
Permissions follow the recipient
A connector's Google permission and an assistant's Zortex grant answer different questions. The first determines what a Google account authorizes Zortex to request or change. The second determines what a particular connected AI integration is allowed to receive from the local system.
The gateway has scoped retrieval paths, including filters for sources or kinds of records and a ceiling on the form of returned content. A reference is less revealing than a summary; a summary is less revealing than an unrestricted raw record. These distinctions matter because an assistant often needs a fact, not the full document containing that fact.
The grant defines what a connected AI may retrieve. A broad grant can expose broad context, while even a short excerpt may contain a sensitive name or decision. Selection happens at the source and content-form boundaries.
Each protection has a defined scope
Zortex's OAuth secret cells use AES-256-GCM authenticated encryption. That statement concerns stored credentials. It does not establish that all synchronized email bodies, index entries, metadata and content files are encrypted by the application. The product has an encrypted-vault path for supported macOS configurations, while actual storage protection also depends on the operating system and installation.
We will not transfer a macOS security claim to every Windows installation without evidence. Users should keep device encryption enabled, protect their operating-system account and review which assistant integrations can reach their vault.
The right to change course
Disconnecting a source disables the relevant grant but preserves previously synchronized local records. Revoking a provider authorization stops future authorized access; it does not erase the copy already on the device. Removing local information requires a separate deletion process, as does removing any material retained by an external assistant.
These are deliberately different operations. Blurring them would make control look simpler than it is.
Every privacy statement should identify the actor, the material, the transfer boundary and its exceptions. That is how a user can decide whether the selected AI should receive a record.
The current operational details are in the application privacy policy, including its scope, retention rules and contact address. The policy, not this article, is the authoritative description when an implementation or configuration changes.
Sources: product implementation and the application privacy policy, reviewed October 9, 2026.
