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, 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. 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:createpermission, 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).
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).
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.
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?
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). Cursor asks for approval before using MCP tools by default (checked October 2026, Cursor's MCP docs).
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, and for the catalog itself, browse the connectors.
