Google’s new Gemini data connectors inherit user permissions—but cannot be pinned to specific tables

Google has put live enterprise-data querying directly inside Gemini Enterprise, previewing first-party Data Cloud connectors for BigQuery, Spanner, Cloud SQL and AlloyDB for PostgreSQL. The launch is pitched as a lower-friction alternative to deploying a custom Model Context Protocol server: Gemini handles managed authentication, discovers relevant assets through Knowledge Catalog, generates SQL and executes it against the source under the end user’s credentials. Google’s launch post says Looker connectivity is also in preview.

The important operating detail is in the documentation rather than the launch headline. A connector is not scoped to a selected dataset, table or database instance. Once attached to an app, it can reach every resource in that source that the authenticated user is permitted to query. Google’s connector documentation says Knowledge Catalog metadata, custom instructions and skills can guide discovery, but they do not turn that broad permission set into a deterministic resource boundary.

Identity is the access boundary

In federated-query mode, the connectors query data in place rather than copying or indexing it into a Gemini Enterprise data store. Each connector uses a first-party MCP server and authenticates with the user’s IAM permissions or OAuth 2.1 credentials. Knowledge Catalog supplies accessible schemas, glossary terms, relationships and enriched metadata; the agent then formulates and executes SQL through the connector.

That design preserves existing row- and column-level controls, according to Google. It also means administrators should review what users can query before enabling conversational access—not assume that a prompt, connector description or preferred dataset limits the reachable estate. The connector’s default connection can be read-only, but “read-only” and “narrowly scoped” are different controls.

Broad connector or curated agent?

Google explicitly separates two deployment patterns. Data Cloud connectors are intended for exploratory, ad hoc work across broad schemas. Conversational Analytics data agents are purpose-built for a domain: teams preselect datasets or tables, define metrics and KPIs, and supply verified queries. Google says that curation can improve accuracy and create deterministic scope, while the broad connector can vary on complex or normalized schemas.

The trade-off is especially sharp for operational databases. Google’s limitations section says federated queries over relational databases have no table scoping or verified queries. A Cloud SQL, AlloyDB or Spanner connector may therefore be convenient for discovery while remaining a poor fit for a workflow that must always stay inside a certified table set.

There is also a context trade-off. The broad Gemini root agent can retain conversation context across multiple connected sources and experiences. A curated data agent is limited to one source, and Google warns that subagent handoffs may not preserve the full root conversation context.

For operators, the practical rule is straightforward: use the connector when user-level permissions are already the intended boundary and exploratory access is acceptable. Use a scoped data agent when the permitted analytical surface must be smaller than everything the user can technically query. Managed authentication removes middleware; it does not remove the need to choose the right authorization and accuracy boundary.