AI assistants become dramatically more useful when they can see your stuff. Search your email. Read your documents. Check your calendar.

The problem is the obvious one: every integration is a new pipeline of your data flowing through someone else’s servers. Connect your Gmail and now the AI company can see your email. Connect your Google Drive and now they can see your documents. The integration layer becomes a data collection layer.

Confer now supports connectors – starting with Google Drive, Gmail, and Google Calendar – and none of that data ever touches our servers.

How connectors usually work

In a typical AI chat product, when you connect a service like Gmail, the OAuth flow is mediated by the AI company’s backend. Your refresh token is stored on their server. When the model wants to search your email, the server uses that token to call the Google API, reads the results, and injects them into the model’s context.

This means the operator has your OAuth tokens and can use them to access your accounts whenever they want. It also means the content of your emails, documents, and calendar events passes through their infrastructure in plaintext. The integration works, but the cost is that a third party now has standing access to your connected services.

Client-side connectors

Confer’s connectors work differently. The entire integration runs on your device.

When you connect Google, the OAuth flow happens directly between your browser and Google using PKCE – a standard designed for public clients where no server-side secret is needed. Your browser opens a popup to Google’s authorization page, you grant access, and Google returns an authorization code directly to your client. Your client exchanges the code for tokens by talking to Google’s token endpoint. Confer’s servers are not involved in any step of this process.

The resulting refresh token is stored in your encrypted profile settings – the same passkey-encrypted blob where Confer stores all your personal preferences. It’s encrypted before it leaves your device, and the server stores it as opaque ciphertext. We cannot decrypt it, which means we cannot use it.

How the model uses your data

When the model decides it needs to search your Drive or read an email, it emits a tool call – a structured request like “search Gmail for ‘quarterly budget.’” But unlike typical architectures where the server executes the tool, Confer’s client intercepts these calls and executes them locally.

The flow looks like this:

  1. Your message is sent to the model over an encrypted channel into the TEE.
  2. The model responds with a tool call: gmail_search({ query: "quarterly budget" }).
  3. Your client receives the tool call and executes it directly against Google’s API, authenticating with the access token that only exists in your device’s memory.
  4. The results come back from Google to your client.
  5. Your client sends the results back to the model (over the same encrypted channel) as context for generating a response.

At no point do the Google API results become visible to the Confer operator. The data flows from Google to your device to the TEE and back. Confer’s infrastructure never sees your OAuth tokens, never calls Google’s APIs on your behalf, and never sees the content of your documents, emails, or calendar events.

What the server sees

This is the same question we ask about every Confer feature, and the answer is the same: nothing useful.

The server stores an encrypted blob containing your refresh token. It cannot decrypt it. It doesn’t know which Google account you connected, or whether you connected one at all – that information is inside the encrypted blob. It doesn’t see the API calls your client makes to Google. It doesn’t see the results. It doesn’t see the tool calls the model makes or the responses your client provides.

The model running in the TEE sees your data for the duration of a request, the same way it sees your messages. But the TEE is attested and reproducible – you can verify what code is running, and that code doesn’t exfiltrate data.

Why this matters

The pitch for AI integrations is compelling: let the assistant see your calendar so it can schedule things, let it read your documents so it can answer questions about them, let it search your email so it can find what you need. These are genuinely useful capabilities.

But every integration in a traditional AI product is a new trust relationship. You’re not just trusting the AI company with your prompts anymore – you’re trusting them with your Google account, your email, your files. You’re trusting that they won’t use that access in ways you didn’t intend, that they won’t get hacked, that they won’t be compelled to hand it over.

Confer’s connectors give you the utility without the trust. Your AI assistant can read your documents, but the company running it cannot.

Try it out!