Does an AI assistant need my email account password?

A connection screen can make fundamentally different credential models look identical. With OAuth, the user authenticates at Google or Microsoft and approves a list of permissions; the assistant receives tokens, not the primary password. With IMAP, some providers offer OAuth while others expect an app-specific password. A product may also ask for a normal password, which creates a much larger trust and recovery problem. Buyers should identify the method before entering anything and understand that authentication, authorisation and product approval are separate layers. The current code supports one Google OAuth connection plus encrypted IMAP credentials. It never sends raw credentials to the language model. Ask any vendor to show you the revocation path and the exact scopes they request, and to demonstrate both rather than describe them.

How does OAuth connect an AI assistant to email?

OAuth redirects the user to the email provider, where the user authenticates and authorises defined scopes; the application receives tokens representing that grant. The provider password remains with the provider.

A short-lived access token authorises API requests. A refresh token can obtain new access tokens after they expire, allowing the assistant to observe authorised work while the app is closed. Refresh tokens therefore require secure long-term storage even though they are not passwords. The provider can invalidate the grant, and the app should remove its stored token on disconnect.

The current Google gateway uses one product OAuth client and requests offline access. It stores an encrypted refresh token, then mints a fresh access token server-side for Gmail or Calendar calls. The browser and model do not receive that stored refresh token. Google recommends secure storage, smallest necessary scopes and incremental authorisation where practical.

Which Google permissions does the current product request?

The present connection requests identity, Gmail reading and sending, plus Calendar reading and event editing. Buyers should judge that bundle against the features they intend to use.

The bundle does not request full Gmail modification or deletion. However, “read-only” is not “low sensitivity”; a mailbox's value lies in what it reveals. The app currently requests all operational scopes at first Google connection rather than asking incrementally when a user first enables sending or calendar work. That may be a reasonable simplicity tradeoff, but it should be described accurately and reviewed against Google's least-scope guidance.

When is an app password used instead?

An app password may be needed for an IMAP mailbox whose provider does not support the product's OAuth flow; it should be unique, revocable and never be the user's reused primary password.

The current IMAP connector recognises common Gmail, Outlook, Yahoo and iCloud hosts and can accept host, port, email and a credential. It establishes a TLS connection to read mail. The credential is encrypted before storage using AES-256-GCM with a deployment-supplied key. Server-side mailbox calls decrypt it only when required.

The UI and documentation should tell a user whether to generate an app-specific credential, not casually label the field “password.” Providers have different requirements, and some disable basic authentication. If an organisation supports OAuth, that is normally preferable because scopes and consent are more visible. App passwords remain secrets with potentially broad mailbox access, so create one only for this connection and revoke it at the provider after deletion.

How are connector credentials separated from the model?

The reasoning model should ask a governed tool to read or act; it should never receive the refresh token, app password or client secret. This separation limits what malicious content or a model error can expose.

In the current architecture, the OAuth client secret and encryption key come from deployment environment variables. Encrypted credentials reside in database records. Provider calls occur in server-side gateway modules, and tool results contain business data rather than raw secrets. This follows the core boundary in the email-access safety guide.

The adopted policy says restricted credentials belong behind a secrets manager and not in logs or model context. In practice, encrypted connector values are stored in Firestore while the encryption key is supplied separately; the public description must say that precisely rather than implying every token value itself lives inside Secret Manager. Key rotation, access logging and production-administrator access still need operational evidence.

What should a correct disconnect do?

Disconnect should stop polling, delete locally stored credentials, revoke provider authorisation where supported and produce a verifiable result. It should not rely on a status label alone.

The current IMAP delete route checks ownership and removes the credential record. Google disconnect removes the user's stored Google record, which prevents future local token use. The function also intends to call Google's revocation endpoint, but it reads a redacted connection object that does not contain the refresh token. Provider revocation therefore cannot be claimed from the current code path.

Before publication, the implementation must decrypt the token within the privileged disconnect function, attempt provider revocation, handle failure visibly, always delete the local record and verify the grant through a real Google account. The user should also receive instructions for Google's connected-app control when provider confirmation fails. Send approval is no substitute for revoking the underlying capability.

How should you test a connection before trusting it?

Use a synthetic mailbox and verify consent, storage, action and revocation as separate events. A successful “Connected” badge proves only the beginning of the flow.

1. Record the provider account and every requested scope.
2. Decline one permission, if supported, and observe which feature stops.
3. Read a unique test message and confirm the correct account is used.
4. Prepare a draft and verify nothing sends without the intended confirmation.
5. Disconnect in the product and confirm polling stops.
6. Inspect the provider's connected-app page for the grant.
7. Attempt another read and send; both should fail.
8. Reconnect and verify that old credentials were not silently reused.

For IMAP, revoke the unique app password at the provider and confirm the connector fails safely without exposing it in an error or log.

Who it is not for

Do not connect a mailbox when the product requires a reusable primary password, cannot state its scopes, or cannot demonstrate credential deletion and revocation. Those are fundamental connection controls.

Enterprise tenants may also block unverified OAuth clients, sensitive scopes or third-party IMAP access. Shared and delegated mailboxes need explicit identity, ownership and audit handling. A security policy may require administrator consent, customer-managed keys or an approved vendor assessment before any token exists. Do not work around those controls with a personal app password.

If the task is only occasional writing, copying selected text into an approved tool may be proportionate to persistent mailbox access. Continuous observation should earn its wider credential surface through real administrative value.

Conclusion: should an assistant ever ask for your password?

An AI assistant should normally connect modern email through OAuth, leaving the primary password with the provider and obtaining only the scopes needed for chosen features. A unique app password can be a defensible fallback for IMAP, but it must be encrypted, isolated from the model, independently revocable and deleted on disconnect. The current implementation follows these principles in token encryption and server-side provider access, while requesting a broad operational Google bundle for read, send and calendar functions. Its local disconnect stops future app access, but provider-side Google revocation needs correction and a real test. Buyers should treat that distinction as the standard: inspect the consent, verify the stored authority and prove that both the application and provider stop accepting it.