# GitHub MCP server for a company with SSO

> A GitHub MCP server for a company with SSO has two sign-ins to settle: your identity provider, and whose GitHub account the tool call actually runs as.

**TL;DR** A GitHub MCP server for a company with SSO has two sign-ins to settle: your identity provider, and whose GitHub account the tool call runs as. Elaichi ships no GitHub connector, but a Gold organization can add GitHub's own remote MCP server as its own remote MCP connector. Calls through it carry the person's Elaichi sign-in, their role's restrictions and an audit row. Each member still connects their own GitHub account.

## Why a GitHub MCP server for a company with SSO is two problems, not one

Someone on your engineering team adds GitHub's MCP server to their AI client, signs in with their GitHub account, and it works. Then the security review asks who that account belongs to, what it can reach, and where the calls are recorded. A GitHub MCP server for a company with SSO has to answer two questions, not one. The second is the harder one.

The first question is identity at your side. When a person opens their AI client and signs in, does your identity provider govern that sign-in? The second is identity at GitHub's side. When the model calls a GitHub tool, whose GitHub account does the call run as? Which repositories does that account see? MCP, the open protocol AI clients use to call tools, does not join these for you. Something has to sit between them.

Start with facts, not architecture. GitHub is not in Elaichi's connector catalog, checked October 2026. Datadog, [Linear](/blog/linear-mcp-server-for-our-engineering-team/), GitLab, PostHog and Miro are in it as native MCP connectors. There the vendor builds and runs the MCP server, and Elaichi handles sign-in, access and audit in front of it. GitHub is not among them, though neighboring engineering apps are, such as the [Argo CD connector](/connectors/argocd/). So this playbook is about bringing GitHub's own remote MCP server under Elaichi's rules, not about a connector Elaichi wrote.

## What changes underneath when you put a gateway in front

Without a gateway, a client talking to GitHub's MCP server holds a GitHub credential and sends every call straight there. Your identity provider never sees those calls, and neither does any log you control.

With Elaichi in front, the shape changes in four places.

**One address, one sign-in.** Elaichi serves MCP at a single endpoint, `https://api.elaichi.ai/mcp`, the same string for every organization. Which organization, person and tools a client reaches comes from the OAuth grant behind its token, not from the URL. OAuth here means the sign-in dance that gives a client a token without handing it a password. There is no per-user or per-team MCP address to create or revoke.

**Your SSO governs the sign-in.** Connecting a client needs a signed-in Elaichi session, so Elaichi's own sign-in rules apply. When a verified domain's SSO connection is enforced, Elaichi refuses any other sign-in for an address on that domain. The message reads "Your organization requires signing in with SSO", and it carries a login URL to the identity provider. That check runs on social and email-code sign-in, on signup and on invite acceptance. It does not run on passkey sign-in.

**Every call carries a person.** Every call made with a grant's tokens acts as the person who approved that grant, in the organization they picked. Each member's grant is their own. Permissions are looked up on each request rather than stored in the token, so a role change applies before the token expires.

**The call is checked before it leaves.** For a remote MCP connector, Elaichi sits in front of that server. Restrictions and OAuth scopes are checked before a call leaves Elaichi. Every call that runs is written to the audit log, and only a tool on that connection's own active list can run.

Calls a client makes to GitHub's MCP server directly, outside Elaichi, do not pass through any of this. That is the honest boundary. A gateway governs what goes through it.

## How a Gold organization adds GitHub's own MCP server

An organization on Gold can add a remote MCP server as its own connector. Over the API that is `POST /connector` with a `remote_mcp` object. In the console it is Connectors, New connector, then "Add remote MCP server" ("Use a server that already speaks MCP. Its tools are found when someone connects."). The form asks for a server URL, a name, a slug and a "New tools" choice of Automatic or Review.

The requirements are narrow and worth reading before you plan the rollout:

- It needs the `connector:create` permission, which among the built-in roles only Org Owner and Org Admin hold. That permission is the only one Elaichi flags High trust, because connector governance binds the connector, not the host it calls.
- It needs the custom connectors plan feature, which Gold includes, and Black, which contains Gold.
- The server URL must use HTTPS and name a host, not an IP address or an internal hostname. It cannot be changed after the connector is created. A different server needs a new connector.
- An organization can hold at most 25 of its own remote MCP connectors.

Public reachability is not an Elaichi quirk. Claude reaches a custom connector's remote MCP server from Anthropic's cloud rather than from the user's device, so the server has to be reachable over the public internet (checked October 2026, [Anthropic's custom connector guide](https://support.claude.com/en/articles/11175166-get-started-with-custom-connectors-using-remote-mcp)).

A new remote MCP connector is private to the organization until it is shared, and its creator becomes its owner. Members then connect it with their own sign-in.

Whether GitHub's own MCP server has been brought under Elaichi's governance this way is not something this post asserts either way. The mechanism is in the product. Confirm the specific server with your own test before you plan around it.

## Where GitHub Enterprise Managed Users sits in this

GitHub Enterprise Managed Users is GitHub's model where accounts are provisioned and owned by your identity provider. It answers the GitHub-side half of the question: which GitHub account a person has, and what it can see. It does not answer the Elaichi-side half, because Elaichi has its own membership, roles and restrictions.

The practical point is that these two layers stack rather than substitute. A remote MCP connector signs members in one of four ways. With `oauth_auto`, Elaichi registers itself with the server as an OAuth client. With `oauth_client`, the admin supplies a pre-registered client. `custom` covers an API token, a custom header or basic auth, and `none` means no sign-in at all. Where the server uses OAuth, each member connects with their own sign-in at the vendor, which is where your managed-user model applies.

GitHub has its own switch on the other side of this. Its MCP servers in Copilot policy is disabled by default (checked October 2026, [GitHub's MCP documentation](https://docs.github.com/en/copilot/concepts/context/mcp)).

Elaichi never forwards its own MCP access token to a remote MCP server. An OAuth server sees only a token its own authorization server issued.

The consequence to plan for: a connection someone shares runs on its owner's account. If the app on the other end should see each person, the tools must run on that person's own connections. One shared connection cannot do it. For the full version of that argument, see [AI agents with employee permissions](/blog/ai-agents-employee-permissions/).

## Which GitHub tools each role may call

To a restriction rule, a remote MCP tool is resource `mcp` with the upstream tool name as its method. In Elaichi, restriction targets are role or user only; the organization default is the absence of a rule, which means allow everything. To keep a team off a tool, write the rule on their role or on each member.

Two behaviors decide how you write the rules.

A layer with only block rules has no allowlist, so everything it does not block passes it. Blocking some write tools leaves every write tool you did not name reachable.

An allow rule turns on the allowlist for its layer just by existing. Once a role carries any allow rule, every connector and tool its allow rules do not name is blocked for that role. That applies across all connectors, not only the one the rule mentions. So an allowlist for a review-only role needs whole-connector allow rules for every other app that role uses, or the role loses them.

Tiering matters too. Each remote tool gets a risk tier from its MCP annotations. `readOnlyHint` true makes it read and `destructiveHint` false makes it write. Anything else, including no annotations at all, makes it destructive. A manager can lower it per tool with a tier override, cleared if the server's tier later rises above it. Over MCP, `mcp:tools` alone runs every tier, reads, writes and deletes, so no consent checkbox holds a client to reading GitHub. To hold a role to reads, block the write and delete tools, or have the person pick toolboxes of read tools at consent.

A restriction change takes effect within about two minutes. Grant revocation, member removal and suspension are effective on the next call, and so is revoking a share.

For the reasoning behind picking per-tool or per-app rules, see [Restrict one AI tool or the whole app?](/blog/per-tool-vs-per-app-restrictions/)

## What the reader sees at the client

In Claude, Elaichi is one connector. In ChatGPT, it is one app. Elaichi is a single MCP server named Elaichi for the whole organization, not one per toolbox or connected app.

The tool list holds Elaichi's own `elaichi__` operations. It adds `search_tools` and `execute_tool` when the grant reaches any connected tool, plus `run_code` where Code Mode is on. By design, connected tools are never listed one by one, however few there are. A model finds a GitHub tool with `search_tools` and runs it with `execute_tool`.

That has a consequence for client-side controls. No tool in Elaichi's list names a connected app. So a client control that gates individual MCP tools can act only on `execute_tool`, `run_code`, `elaichi__toolbox__execute` and `elaichi__synthetic_tool__execute` as wholes. It cannot single out GitHub. Per-app and per-tool control is set in Elaichi, as restrictions.

Elaichi marks `execute_tool` and `run_code` destructive and open-world. A client setting that lets read-only tools run unprompted therefore still prompts for every connected-app call, reads included. In Codex, `default_tools_approval_mode` set to `writes` prompts for any tool not marked read-only (checked October 2026, [OpenAI's MCP docs](https://learn.chatgpt.com/docs/extend/mcp)). Cursor asks for approval before using MCP tools by default (checked October 2026, [Cursor's MCP docs](https://cursor.com/docs/mcp)).

When a call is refused, the model gets an in-band message on an HTTP 200, not a protocol error. A restriction refusal says whether the block comes from the role or from the person's own account. It also says an admin can lift it through an access request. A missing scope names the consent checkbox to tick and says the user must reconnect.

## When GitHub's own server, straight, is the right answer

Sometimes a second vendor buys you little. That is the case when GitHub is the only app your engineers reach from AI clients, every one of them already signs into GitHub through your identity provider with managed users, and you are content with the logs GitHub itself keeps. GitHub's server needs no gateway to work, and one address for one app is not an address problem.

The case for putting it behind Elaichi starts when GitHub is the third or fourth app on the list. Then you get one endpoint that Claude, ChatGPT and Cursor all sign into, and one set of role restrictions across every app. You also get one audit log, where a GitHub call and a Jira call sit side by side. Elaichi keeps 90 days of audit history; for longer, forward it to your own log service, which comes with the Black plan, launching soon.

One more caution. Elaichi checks a custom connector's config for shape, not for where it points. Restrictions bind a connector's identity, its slug and the forks that declare descent from it, never the host it calls. So a restriction on one connector does not stop a new connector aimed at the same API. That is why `connector:create` sits with Org Owner and Org Admin only.

For the wider engineering rollout, see [MCP for coding agents across an engineering org](/blog/coding-agents-company-tools/), and for the catalog itself, [browse the connectors](/connectors/).

## FAQ

### Does Elaichi have a GitHub connector?

No. GitHub is not in Elaichi's connector catalog, checked October 2026. An organization on the Gold plan can instead add GitHub's own remote MCP server as its own remote MCP connector, created by an Org Owner or Org Admin. Calls through that connector are then governed by Elaichi's restrictions, OAuth scopes and audit log. Datadog, Linear, GitLab, PostHog and Miro are in the catalog as native MCP connectors. There the vendor runs the server and Elaichi handles sign-in, access and audit.

### How does SSO apply to an MCP client connecting to Elaichi?

Connecting an MCP client needs a signed-in Elaichi session, so Elaichi's sign-in rules apply. When an organization enforces an SSO connection on a verified email domain, Elaichi refuses any other sign-in for an address on that domain. The refusal reads "Your organization requires signing in with SSO" and carries a link to the identity provider's login. That check runs on social sign-in, email-code sign-in, signup and invite acceptance. It does not run on passkey sign-in.

### Can a restriction hold an AI client to read-only access in GitHub?

Not through a consent checkbox. Over MCP, the mcp:tools scope runs every tier of connected tool, writes and deletes included. No scope limits a client to reads in a connected app. To hold a role to reads, write restriction rules that block the write and delete tools for that role. The other route is to have the person pick toolboxes containing only read tools at consent. A restriction change takes effect within about two minutes.

### Does each person need their own GitHub account connected?

If you want GitHub to see the individual person, yes. Every call through a connection uses the account that connection was made with, whoever is calling. A shared connection therefore runs as its owner at GitHub. For per-person identity, each member connects their own GitHub account with their own sign-in. They then run tools from their own connections rather than from a connection someone shared with them.

### What does an AI client see when Elaichi is connected?

One MCP server named Elaichi for the whole organization, added as one connector in Claude or one app in ChatGPT. Its tool list shows Elaichi's own operations plus search_tools and execute_tool, and run_code where Code Mode is available. By design, connected tools are never listed one by one, however few there are, so the model finds a tool with search_tools and runs it with execute_tool.

## Read next

- [Linear MCP server for our engineering team](/blog/linear-mcp-server-for-our-engineering-team/) — A Linear MCP server for our engineering team changes whose account each call runs as, which tools stay on, and what the audit log keeps.
- [Zoho CRM MCP server for our sales team: two paths](/blog/zoho-crm-mcp-server-for-our-sales-team/) — A Zoho CRM MCP server for our sales team can mean two different things. Here is what changes underneath, and what a rep sees in ChatGPT or Claude.
- [Connect Linear to Claude for our product team](/blog/connect-linear-to-claude-for-our-product-team/) — To connect Linear to Claude for our product team, govern Linear's own MCP server: per-person sign-in, a block rule, review for new tools.