On this page

A personal context engine is useful because it can remember more than an individual chat. That is also the reason the boundary between the context engine and a connected assistant deserves careful attention.

Connecting Gmail to Zortex and connecting an AI assistant to Zortex are two distinct authorizations. Google decides which Google APIs and records the application may access. Zortex's grants and policies decide what a particular AI integration may receive from the local context system. The assistant's own terms then govern information it has already received.

A provider's API grant, a Zortex retrieval grant and a receiving AI's retention policy govern three different steps.

Begin with the recipient

The first question for any AI integration is: who will receive the result? A locally running assistant and a hosted assistant do not have identical data paths. Both can use an MCP connection, but a cloud-backed host may transmit returned content to its model provider for processing.

The application privacy policy is explicit about this. Permitted search results, metadata and selected content can reach an assistant host. Local synchronization does not imply that subsequent processing is local. The host and its provider may have separate retention, security and training terms.

We do not claim that Zortex can erase information already retained by an independently selected AI provider. We do not label an assistant safe merely because its logo appears in a connection menu.

Examine the grant, not the marketing description

The Zortex gateway includes per-app access controls. A grant can specify which vault paths or kinds of record are in scope and how much detail may be returned. The implementation distinguishes reference, summary, compressed and raw forms of content. Its retrieval scope filtering happens before the context engine assembles candidates for that grantee.

That is meaningful: a request for a project summary should not silently become permission to search every record in every source. It is also not sufficient on its own. A grant expressed as every path, every kind and raw content is extremely broad, regardless of how elegantly the interface presents it.

When evaluating a connection, the questions we use are concrete:

  • Identity: Which app or host is making the request, and which permission grant belongs to it?
  • Purpose: What task requires this information right now?
  • Scope: Which sources, record kinds and content forms are available?
  • Transfer: Does the response remain on this device or enter a separate provider's systems?
  • Exit: How is the grant revoked, and who can delete copies already transferred?

Those five checks identify the receiver, purpose, permission scope, transfer route and way to stop further access. Third-party retention remains governed by the receiving service.

What the gateway is meant to enforce

An MCP request reaches an integration boundary before receiving context. Applicable access controls can narrow candidate retrieval by path and record kind. Results then have a content-form ceiling. The gateway exposes grant information so a connected client can inspect its effective scope.

Assistant request
       |
       v
App identity + active grant
       |
       v
Source/kind scope --> Relevant local retrieval --> Content-form limit
                                                  |
                                                  v
                                             Assistant host
                                             (provider terms apply)

News diagram for news third party ai access

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.

An important difference remains between receiving a reference and receiving its underlying content. A reference can still reveal a title or association. A short summary can contain an individual's name. Restricting form reduces exposure but is not equivalent to a guarantee that nothing sensitive crosses the boundary.

Distinguish actions from answers

An assistant asking “What did we decide?” is different from an assistant asking Zortex to send or modify something. The underlying Google permission sets the outer API capability: for example, the Calendar declaration is read-only while Gmail and Drive declarations include broader scopes. Zortex's action handling and grant policies must still govern what a specific request can execute.

The useful review question is not simply whether an assistant “has access.” It is whether it has the right access for this task, in this form, at this moment. Supported actions depend on the particular host, current grant and requested operation.

Responsibilities after disclosure

Zortex commits not to sell Google user data, use it for targeted advertising or use it to train generalized models. The commitment covers Zortex's own handling and applicable transfers; it does not automatically rewrite an independently chosen provider's terms. Our integrations must remain consistent with our Google data commitments, and users should also review the provider they select.

Revoking a Zortex grant can stop future disclosures through that grant. It does not retract an answer already delivered to a hosted model. The user may need to use that provider's deletion controls as well.

Narrow, reviewable access starts with an identifiable source, host and content form. The application privacy policy records the disclosure, revocation and retention rules.

Sources: product implementation and the application privacy policy, reviewed October 9, 2026.