Three checks before Gemini's default connectors reach your CRM, books, and board

The default is already on

You are in the Google Workspace admin console, deciding what the assistant can read. The surprising part is not that Gemini can reach your tools; the seven launch connectors ship on by default in the Gemini side panel.

A small founding team can turn on a useful assistant and, without a meeting, give it a view of customer data, financial records, and board materials. The default setting is the problem. The same setting can save a meeting and leak a board packet in the same afternoon.

As of September 15, 2026, Gemini in Google Workspace can work with Asana, Atlassian Rovo, HubSpot, Intuit Mailchimp, Intuit QuickBooks, Monday, and Salesforce through Model Context Protocol, or MCP, integrations.

The connectors are available on Rapid Release and Scheduled Release domains and cover Business and Enterprise editions plus consumer Google AI, Pro, and Ultra plans.

Inside Sheets, Gmail, Drive, Docs, and Chat, Gemini can obtain information from the connected tools while remaining in the current workflow instead of changing tabs or downloading files. For a small company, that is a speed gain and an exposure question in the same feature.

You do not need to use all of them to need a record of which ones are on. The audit separates useful reach from accidental reach.

Three checks keep the side panel useful

Run these before the next all-hands. The output is a short record you can paste into a decision log, not a new policy document.

• Open the Admin console, go to Apps > Google Workspace > Gemini for Workspace > Third-Party Connectors, and confirm which of the seven connectors are enabled.
• Confirm the access-policies line names the scope the Admin console can manage: domain, organizational unit, or group. Use this format: “Enabled for [Org Unit/group] - read-only for QuickBooks and HubSpot; no write access unless explicitly approved”.
• Send the team notice: “Gemini can now read [tool] in [Workspace app] for [people]”.

Together, the checks turn the default into a decision, make the scope visible, and tell the team what the assistant can reach.

When a connector is on for the whole domain, the access line should say so. When it is limited to an organizational unit or a group, the line should name that scope. A blank line is not a safe answer. The line should be short enough to read in a meeting and strict enough to survive a board question. An answer of “everyone” leaves the scope missing. An answer of “only the ops group” belongs in the notice.

Tie the audit to a named owner in the ops group, not a general chat. That owner should be able to point to the enabled connectors, the access-policies line, and the team notice before the next board question.

The notice belongs in the record

Treat the notice as an operating note rather than a marketing message. It should say what the assistant can reach, where it can reach it, and who is covered. If the team does not know the assistant can reach a tool, the tool is effectively hidden from the people who need to judge its use.

A CRM, a books tool, and a board deck are different kinds of exposure. The CRM holds customer relationships. The books tool holds financial detail. The board deck holds strategy. The audit does not need to classify every field. It needs to say which systems are reachable and who is covered.

Put the audit next to the other operating documents: the decision log, the access review, and the all-hands note. When a new tool enters the stack, the same three checks apply. The notice should be visible to the people who will judge its use, not buried in a release note.