Gemini Enterprise per-user MCP credentials vs Sume OAuth and key

Gemini Enterprise's Oct 2 federated query uses MCP with each user's own credentials. Sume offers per-user OAuth with mcp:read or mcp:write, or a shared API key.

4 min readSume
All posts

Google's Gemini Enterprise release notes for October 2, 2026 describe a federated query mode for Data Cloud connectors (AlloyDB, BigQuery, Cloud SQL and Spanner). It queries data in place using the Model Context Protocol and each user's own credentials. Sume's hosted MCP can follow the same per-user pattern through OAuth, or a shared API key if you prefer one identity.

The Google facts are from its release notes. The notes cover Data Cloud connectors, not Sume, so treat this as a design comparison.

Per-user versus shared

Identity models (read 2026-10-04)
ModelWho the server seesSume option
Federated query (Gemini Enterprise)Each user's own credentialsOAuth: each user consents to mcp:read and optionally mcp:write
Shared service identityOne account for everyoneAPI key sent as Bearer or x-api-key
Read-only defaultCannot change datamcp:read hides write and paid tools
Token lifetimeSet by the vendorSume access tokens last one hour, no refresh token

Which identity should pay?

With OAuth, each user's own Sume account is the one that is charged, so spend follows the person. With a shared API key, one balance pays for everyone and you must meter use yourself. The OAuth docs describe consent and scopes, and authentication covers the key headers.

Pick OAuth when you want an audit trail by person. Pick a key when a backend job runs without anyone present.

Checklist

  • Decide per workflow: per-user OAuth or a shared key.
  • Start every user on mcp:read.
  • Plan for token expiry; a one-hour token does not suit a long unattended job.
  • Do not mix identities in one thread; the account that holds the token pays.

Sources

Related posts

More in Integrations

All Integrations posts

Written by Sume