# Gemini access to company apps: admin controls

> Gemini access to company apps splits three ways across Gemini Enterprise, the Gemini app and Gemini CLI, and Google documents each surface separately.

**TL;DR** Gemini access to company apps is three separate questions, because Gemini Enterprise, the Gemini app and Gemini CLI are each documented separately by Google. Gemini Enterprise takes a custom remote MCP server over Streamable HTTP, blocked by an organization policy until an admin overrides it, with actions off by default. Elaichi sits behind whichever surface you settle on: one address, each person signing in as themselves, restrictions per role down to a single tool, and one audit log. Elaichi does not name Gemini among the clients its consent screen recognizes, so confirm sign-in in a pilot before you plan a rollout.

## Which Gemini surface are you actually being asked about?

A request for Gemini access to company apps usually arrives as one line in a ticket. It is three questions. Gemini Enterprise, the Gemini app and Gemini CLI each have their own Google documentation page. Settle which one your people run before you design anything. The answer for Gemini Enterprise does not transfer to the Gemini app.

MCP (Model Context Protocol) is the standard way an AI assistant calls tools in other apps.

Google's Gemini Enterprise docs describe a custom MCP data store. It lets you "integrate public tools, as well as MCP-compliant third-party systems, directly into Gemini Enterprise". The same page says "The connector exclusively supports the new StreamableHTTP transport" ([Google, set up a custom MCP server](https://docs.cloud.google.com/gemini/enterprise/docs/connectors/custom-mcp-server/set-up-custom-mcp-server), checked October 2026). That is the surface where an IT admin has real levers. The Gemini app and the CLI are different stories, covered in their own sections below.

## What Gemini Enterprise lets an admin control

Gemini Enterprise starts closed. Google's docs say "By default, Gemini Enterprise blocks the creation of Model Context Protocol (MCP) data stores using a managed organization policy constraint". They add that "an Organization Policy Administrator must override this restriction" ([Google, override the constraint](https://docs.cloud.google.com/gemini/enterprise/docs/connectors/custom-mcp-server/override-constraint-for-custom-mcp-data-stores), checked October 2026). So the first decision is not technical. It is who in your Google Cloud organization holds that role and signs off on the override.

Once the constraint is lifted, Google's setup page for a custom MCP server offers "No authentication" or "OAuth 2.0". It tells you to "Register Gemini Enterprise as an OAuth client application with your identity provider (for example, Okta, Azure AD, or Google)". The same page says "By default, all actions are turned off". It adds that "you can enable up to 100 actions at a time" ([Google, set up a custom MCP server](https://docs.cloud.google.com/gemini/enterprise/docs/connectors/custom-mcp-server/set-up-custom-mcp-server), checked October 2026).

For the Business edition, a team administrator adds a server under Manage team, then Connected apps, with Add MCP Server. Google's help page says "By default, the custom MCP server connection is disabled". It also says "Your MCP server must be exposed to the public internet on a secure HTTPS endpoint", and notes that Pre-GA features "might have limited support" ([Google, Gemini Enterprise Business edition](https://support.google.com/g/answer/17106276?hl=en), checked October 2026). Print that menu path with its date in any runbook you write. Admin paths move.

## Why the Gemini app is a different question

Google does not document the Gemini app's custom MCP path for a work or school account. Its Gemini Apps Help says you can add a custom app with its MCP server URL in the Gemini web app. The same page says "For now, this feature isn't available if you sign in with a work or school Google Account". It also requires that you "Be 18 or over and in the US", and says "Gemini requires manual confirmation for any write actions" ([Google, add a custom app in Gemini](https://support.google.com/gemini/answer/17209137?hl=en), checked October 2026).

That matters for a rollout plan. If everybody signs in with a managed Workspace identity, Google does not document that route for them. The Workspace admin console covers something else: the Gemini app's connection to Workspace services. Google's admin help says that setting "is on by default, meaning users can connect Workspace apps to the Gemini app". It also says it "Requires having the Gemini Settings administrator privilege". Custom MCP servers are not documented on that page ([Google Workspace, control Gemini App access to Workspace services](https://knowledge.workspace.google.com/admin/generative-ai/gemini-app/turn-google-apps-in-gemini-on-or-off), checked October 2026).

So a request that reads "let the Gemini app see our CRM" needs splitting. The Workspace switch governs Workspace apps. Anything outside Workspace is a different surface and a different approval. [Microsoft Copilot with Salesforce](/blog/microsoft-copilot-salesforce-jira/) runs into the same split from the other vendor's side.

## Which transport does Gemini CLI speak?

Check which binary your engineers actually run before you write a CLI step. Google's Gemini CLI MCP documentation says "Gemini CLI supports OAuth 2.0 authentication for remote MCP servers using SSE or HTTP transports". A banner on that page reads "Unpaid tier and Google One users: Gemini CLI was replaced by Antigravity CLI on June 18th, 2026" ([Gemini CLI, MCP servers](https://geminicli.com/docs/tools/mcp-server/), checked October 2026).

Confirm the transport in the same pass. Elaichi serves MCP at POST https://api.elaichi.ai/mcp over the Streamable HTTP transport, as JSON-RPC 2.0 messages. GET and DELETE on that address answer HTTP 405 with Allow: POST, and no session id is ever issued. For the request shape itself, [a single MCP request on the wire](/blog/json-rpc-over-streamable-http/) walks through it.

One audit detail is specific to command-line clients. Elaichi shows a client's name as verified only when every non-loopback redirect address it registered maps to the same known client. Exactly seven clients can be verified: Claude, ChatGPT, Cursor, Grok, Perplexity, Mistral and Devin. Elaichi's code names Gemini CLI among the clients that register only loopback redirects, which prove nothing. Gemini's shared account-linking hosts are left out of the verified list on purpose. Such an entry shows the name the client registered for itself, flagged as self-reported.

## What governed Gemini access to company apps looks like behind one address

A governed layer does not change which Gemini surface an admin is configuring. It changes what sits behind the address that surface points at. Elaichi serves MCP at one endpoint, POST https://api.elaichi.ai/mcp, the same string for every organization. The URL says nothing about who is calling. That comes from the OAuth grant: the standing permission a person approves on Elaichi's own consent screen for one named client ([one endpoint against one per team](/blog/one-endpoint-vs-per-team-endpoint/)).

Three things follow from that, and they are the reason to put a control plane in the path at all.

**Each person signs in as themselves.** Every person connects their client once and approves their own grant. Calls on that grant act as that person, in the organization they picked, and Elaichi checks their permissions fresh on every request instead of trusting the token. Nobody is sharing one service account, and nobody is pasting an API key into a client.

**Restrictions bind a role or one member, down to a single tool.** A restriction rule has a mode of allow or block, a target, and lists of whole connectors and of single tools. Each tool is written as a connector and a tool name. A rule follows the operation a tool performs, not its display label, so a renamed tool still hits its block ([how blocks and allows find a tool](/blog/block-matches-name-allow-matches-operation/)). A restriction targets a role or one member, never a team and never the whole organization. That is the part people get wrong first; [choosing between one tool and the whole app](/blog/per-tool-vs-per-app-restrictions/) covers the six cases.

**One audit log, across every connector.** An organization has one audit log across all its connectors, with one entry for each connected-tool call that reaches execution (a call refused earlier writes none). Each entry names the person, the connection and the MCP client, so a Gemini call can be told apart from a Claude one. Elaichi keeps 90 days. Beyond the in-app trail, export to your own Datadog comes with the Black plan. [What an AI agent audit log must capture](/blog/what-an-ai-audit-log-must-capture/) lists every field.

The catalog behind that address holds 650+ connectors in two kinds. Elaichi authors and runs most of them itself. The rest are native MCP connectors: the vendor runs the server, and Elaichi puts sign-in, restrictions and the audit log in front of it ([registry against first-party connectors](/blog/mcp-registry-vs-first-party-connectors/)). A team on Gold can also add its own remote MCP server as a connector. Browse [the connector catalog](/connectors/) for what is already there.

## How to check whether a Gemini client can sign in at all

Test it in a pilot before you plan anything around it. Elaichi's authorization server was written with Claude, ChatGPT and Cursor in mind. Its code names Claude Desktop, claude.ai connectors and Cursor as the clients it serves, and its consent screen recognizes the redirect addresses of seven clients. Gemini is not among them. Elaichi keeps no list of approved MCP clients. Any client that supports OAuth dynamic client registration, PKCE with S256 and a browser sign-in can connect. Confirm that your Gemini surface does all three.

Check two specifics first. MCP clients register themselves at POST https://api.elaichi.ai/oauth/register, and a client_id must be one Elaichi issued there. Any other value gets invalid_client with "Unknown client_id", and Elaichi does not support Client ID Metadata Documents. Google's Gemini Enterprise setup page describes registering Gemini Enterprise as an OAuth client with your identity provider ([Google, set up a custom MCP server](https://docs.cloud.google.com/gemini/enterprise/docs/connectors/custom-mcp-server/set-up-custom-mcp-server), checked October 2026). That is a different shape from dynamic registration. Prove the flow with one account before promising it to a department. PKCE is mandatory too, and S256 is the only method accepted. When sign-in fails, [the OAuth error messages](/blog/mcp-oauth-errors/) name the cause.

## The trade-offs to settle before you commit

Three come up in every review, and none of them has a flattering answer.

Client-side per-tool controls cannot see your apps. Elaichi never lists a connected tool by name in a client's tool list, however few there are. A client finds them with search_tools and runs them with execute_tool. A client control that gates individual tool names therefore acts on execute_tool as a whole. It cannot single out one connected app. Per-app and per-tool control has to live in Elaichi, as restrictions.

There is no per-call approval over MCP. The grant is the approval: the scopes a person ticks on Elaichi's consent screen stand for that client's later calls. Elaichi does not ask again per call. Any confirmation a person sees is their own client's prompt. Google's Gemini Apps Help says the Gemini app requires manual confirmation for write actions ([Google](https://support.google.com/gemini/answer/17209137?hl=en), checked October 2026), which is the client's behavior rather than Elaichi's.

Timing is not instant. A role, team-membership, restriction or access-grant change takes effect within about two minutes. Revoking a grant, removing or suspending a member, revoking a share and disconnecting an account are all effective on the next call.

## When you do not need any of this

If one team uses one app, and Gemini Enterprise's own actions list already covers it, a control plane is overhead. Google's own defaults do a lot of work on that surface. The organization policy blocks MCP data stores until an admin overrides it ([Google, override the constraint](https://docs.cloud.google.com/gemini/enterprise/docs/connectors/custom-mcp-server/override-constraint-for-custom-mcp-data-stores), checked October 2026). Actions are off until somebody turns them on ([Google, set up a custom MCP server](https://docs.cloud.google.com/gemini/enterprise/docs/connectors/custom-mcp-server/set-up-custom-mcp-server), checked October 2026). The same holds if everything your people want sits inside Google Workspace. There the Workspace connection is the thing to govern.

The case for one governed address starts when the apps come from several vendors and the people come from several teams. Someone then has to answer who did what, in which app, last Tuesday. [When you do not need an MCP gateway yet](/blog/when-you-dont-need-an-mcp-gateway/) argues the other side honestly, and [what a control plane actually is](/blog/what-is-an-mcp-control-plane/) sets out the category. For the shape of the rules themselves, see [how governance is configured](/use-cases/governance/), and for the two-place approval pattern on another vendor, [approving apps for Claude across a company](/blog/approve-apps-employees-connect-to-claude/).

## FAQ

### Can a work or school Google Account add a custom MCP server in the Gemini app?

Not for now. Google's Gemini Apps Help says "For now, this feature isn't available if you sign in with a work or school Google Account". It also requires the person to be 18 or over and in the US (https://support.google.com/gemini/answer/17209137?hl=en, checked October 2026). For managed company accounts, the custom MCP path to look at is Gemini Enterprise instead. The Workspace admin console setting governs the Gemini app's connection to Workspace services; custom MCP servers are not documented on that page.

### Does Gemini Enterprise allow custom MCP servers by default?

No. Google's documentation says Gemini Enterprise blocks the creation of Model Context Protocol data stores by default, using a managed organization policy constraint. It adds that an Organization Policy Administrator must override that restriction (https://docs.cloud.google.com/gemini/enterprise/docs/connectors/custom-mcp-server/override-constraint-for-custom-mcp-data-stores, checked October 2026). Google's setup page says all actions are turned off by default and that up to 100 actions can be enabled at a time. Its Business edition help page says a custom MCP server connection is disabled by default.

### Which MCP transport does a Gemini Enterprise custom connector need?

Streamable HTTP. Google's Gemini Enterprise documentation says the connector "exclusively supports the new StreamableHTTP transport" (https://docs.cloud.google.com/gemini/enterprise/docs/connectors/custom-mcp-server/set-up-custom-mcp-server, checked October 2026). Elaichi serves MCP at POST https://api.elaichi.ai/mcp over the Streamable HTTP transport, as JSON-RPC 2.0 messages. GET and DELETE on that address answer HTTP 405 with Allow: POST.

### Is Elaichi tested with Gemini?

Elaichi does not name Gemini among the clients it serves. Elaichi's authorization server code names Claude Desktop, claude.ai connectors and Cursor. Its consent screen recognizes the redirect addresses of seven clients: Claude, ChatGPT, Cursor, Grok, Perplexity, Mistral and Devin. Elaichi keeps no list of approved clients, so any client that supports OAuth dynamic client registration, PKCE with S256 and a browser sign-in can connect. Confirm all three in a pilot before planning a rollout.

### How quickly does a restriction change reach an AI client?

A role, team-membership, restriction or access-grant change in Elaichi takes effect within about two minutes. Revoking a person's grant, removing or suspending a member, revoking a share and disconnecting an account are effective on the client's next call, because every MCP request re-reads the grant.

## Read next

- [How to restrict ChatGPT Enterprise connectors](/blog/restrict-chatgpt-enterprise-connectors/) — You can restrict ChatGPT Enterprise connectors per app, and per group on Enterprise and Edu. Here is exactly where that grain stops.
- [How to approve apps for Claude across a company](/blog/approve-apps-employees-connect-to-claude/) — There are two places you approve apps for Claude: Anthropic's connector controls, and the restriction rules behind your one MCP endpoint.
- [Microsoft Copilot with Salesforce: two paths](/blog/microsoft-copilot-salesforce-jira/) — Microsoft Copilot with Salesforce indexes your CRM for search. Live reads and writes from Claude, ChatGPT or Cursor take a different path.