Set up the GitHub MCP server

Connect GitHub to C1 through the GitHub API or GitHub’s own hosted MCP server, then register the server and govern its tools.

Activation required. AI access management must be enabled for your tenant before you can use it. To get started, contact the C1 support team for a walkthrough.

C1 can govern GitHub access two ways. Both let your AI clients read from and act on GitHub through governed MCP tools, but they come from different places and appear as two separate entries in your MCP server catalog:

• GitHub MCP — listed as plain GitHub in your catalog. C1 registers GitHub’s own hosted MCP server (api.githubcopilot.com) as a downstream server C1 governs. GitHub doesn’t support dynamic client registration (DCR), so authentication is per-user OAuth through a GitHub OAuth App you register once, or a shared personal access token. Tool calls run with the connected user’s granted OAuth scopes (or the token’s permissions), against GitHub’s own broader tool set — including cross-item search, discussions, and security alerts.
• GitHub API — C1 hosts its own MCP server that translates GitHub’s REST API into tools. You choose between per-user OAuth or a shared personal access token, and access follows the OAuth app’s requested scopes or the token’s repository permissions.

	GitHub MCP	GitHub API
Who hosts the MCP server	GitHub	C1
Authentication	Per-user OAuth (no dynamic client registration — requires a GitHub OAuth App), or a personal access token	Per-user OAuth (requires a GitHub OAuth App), or a personal access token
Access scoping	The OAuth scopes granted at authorization, or the personal access token’s permissions	The OAuth app’s requested scopes, or the personal access token’s repository permissions
Tool surface	GitHub’s own tool set: repositories, issues, pull requests, Actions workflows, discussions, security alerts, and notifications	Repositories, pull requests, issues, Actions, and organization data, mapped to GitHub API endpoints
Setup effort	Register a GitHub OAuth App (or generate a token), then register in C1	Register a GitHub OAuth App (or generate a token), then register in C1

Use the native GitHub MCP option (listed as plain GitHub in your catalog) if you want GitHub’s own broader, agentic tool set, including cross-item search, discussions, and security alerts. Use GitHub API if you want C1’s own curated tool surface mapped directly to GitHub API endpoints.

GitHub MCP

C1 registers as a client of GitHub’s own hosted MCP server (GitHub MCP Server) rather than translating GitHub’s REST API itself. Your users’ AI clients still only ever see C1-governed MCP tools, but C1 proxies each tool call straight through to api.githubcopilot.com under the connected user’s authorized session, then returns the result. The tools available are exactly the ones GitHub’s hosted MCP server exposes — C1 doesn’t reshape or add to them.

Before you begin

• AI access management must be enabled for your tenant. See Enable AI access management.
• GitHub doesn’t support dynamic client registration (DCR) for this server, so — unlike some native MCP integrations — there’s a one-time setup step in GitHub first: register a GitHub OAuth App and provide its client ID and secret. See Set up per-user OAuth below.
• If you’d rather not register an OAuth App, this option also accepts a GitHub personal access token as a shared bearer credential. See Use a personal access token instead below.

In your MCP server catalog, this option is listed as GitHub — distinct from the GitHub API entry, which connects through C1’s own MCP server. If you don’t see either, contact the C1 support team to enable it for your tenant.

Set up per-user OAuth

Per-user OAuth is the recommended way to connect — each user authorizes individually, and every tool call runs under their own GitHub identity and permissions. Unlike C1’s other native MCP integrations, GitHub doesn’t support dynamic client registration for this server, so you need to register a GitHub OAuth App yourself before C1 can prompt users to connect.

First, create a GitHub OAuth App that users will authorize through:

1. In GitHub, go to Settings > Developer settings > OAuth Apps and select New OAuth App (or Register a new application if this is your first one). See GitHub’s guide to creating an OAuth app.

2. Fill in the registration form:

   • Application name — a recognizable name such as C1.
   • Homepage URL — your C1 tenant URL, or https://www.c1.ai.
   • Authorization callback URL — set this exactly to https://accounts.conductor.one/auth/callback. GitHub OAuth Apps allow only one callback URL, unlike GitHub Apps.
3. Select Register application, then copy the Client ID. Select Generate a new client secret and copy the secret — GitHub shows it only once. Store it securely, and if it’s ever exposed, generate a new one, update C1, then delete the old one (best practices for creating an OAuth app).

With your OAuth app ready, register the server and provide its credentials:

1. Follow Register an MCP server and select GitHub from the catalog.

2. When you configure authentication, choose OAuth2 — per-user passthrough and enter your OAuth app’s client ID and client secret.

3. Save your changes. The first time a user calls a GitHub tool from their AI client, they’re redirected to GitHub to sign in (if they aren’t already) and approve the requested scopes, then returned to C1 (authorizing OAuth apps).

What access is granted

When a user authorizes, C1 requests these scopes on GitHub’s consent screen (scopes for OAuth apps):

• repo — full read/write access to public and private repositories, including code, commit statuses, invitations, collaborators, deployment statuses, and webhooks.
• read:org — read-only access to organization membership, organization projects, and team membership.
• read:user and user:email — read access to the user’s profile data and email addresses.
• read:packages and write:packages — download/install and upload/publish access to GitHub Packages.
• read:project and project — read-only and read/write access to user and organization projects.
• gist — write access to gists.
• notifications — read access to the user’s notifications, plus mark-as-read and subscription management.
• workflow — the ability to add and update GitHub Actions workflow files.
• codespace — the ability to create and manage codespaces.

Tool calls then run with the connected user’s own GitHub permissions across whichever of these scopes they hold — for example, a user without write:packages can’t publish a package through a GitHub tool even though C1 requested that scope.

Use a personal access token instead

If you’d rather not register an OAuth App, GitHub’s hosted MCP server also accepts a personal access token (PAT) — classic or fine-grained — as a shared bearer credential that authenticates every user as one identity.

1. In GitHub, generate a token under Settings > Developer settings > Personal access tokens. GitHub recommends fine-grained tokens, which you can scope to specific repositories and permissions (types of personal access tokens); a classic token works too, but it can reach every repository you can access.

2. Copy the token — GitHub shows it only once.

3. Follow Register an MCP server and select GitHub from the catalog.

4. When you configure authentication, choose Bearer token and paste the token. C1 sends it as Authorization: Bearer <token> on every request.

How GitHub MCP credentials are shared

• Per-user OAuth. Each user authorizes with their own GitHub account, so tool calls run under that user’s GitHub identity and inherit only the scopes they granted. GitHub attributes each action to the individual user.
• Personal access token. Every user’s tool calls use the one token you provided, so GitHub sees a single shared identity. C1 still attributes each call to the individual user in the AI tool usage audit log.

Discover and govern tools

After you register the server, C1 runs tool discovery against GitHub’s hosted MCP server. Discovered tools appear on the server’s Tools tab.

Each tool starts as either Pending review or automatically Approved, depending on the option chosen when the server was set up or your tenant’s default tool settings in AI > MCP > Settings. See Require tool approval and Default tool classification.

Before anyone can call a GitHub tool, it must be approved, added to a toolset, and bound to an access profile. Continue to Govern tools and toolsets to set this up.

Tool discovery runs even if authentication isn’t complete yet, so seeing discovered tools doesn’t confirm a user has authorized. You confirm access when an approved user successfully calls a GitHub tool from their AI client.

Manage access to GitHub MCP

• Rotate the OAuth client secret on your OAuth app’s settings page in GitHub (Settings > Developer settings > OAuth Apps), then update the secret on the server’s authentication settings in C1.
• Rotate a personal access token by generating a new one in GitHub and updating it in C1. Set an expiration on the token so it rotates on a schedule.
• An individual user can revoke their own authorization at any time. In GitHub, go to Settings > Applications > Authorized OAuth Apps, then select Revoke next to C1 (reviewing your authorized OAuth apps).
• An organization owner can restrict or revoke OAuth App access org-wide if the organization has third-party application access restrictions enabled (about OAuth App access restrictions).

GitHub API

C1 hosts the GitHub MCP server, so your users’ AI clients only ever see MCP tools — they never call GitHub directly. When an AI client calls one of these tools, C1 makes the matching request to the GitHub API using the credentials you configure here, then returns the result to the AI client. The credentials you set up below are what C1 uses to call GitHub on your users’ behalf.

GitHub supports two ways to authenticate, and you choose one when you register the server:

• Per-user OAuth (recommended). Each person authorizes with their own GitHub account, so every tool call runs under that user’s GitHub identity and permissions.
• Personal access token. A single token authenticates everyone, so all tool calls reach GitHub as one shared identity.

For a deeper comparison of shared versus per-user credentials, see Configure authentication.

Before you begin

• AI access management must be enabled for your tenant. See Enable AI access management.
• For per-user OAuth, you need permission to create an OAuth app on your GitHub user account or organization.
• For a personal access token, you need the GitHub account whose access the token should carry.

In your MCP server catalog, this option is listed as GitHub API — distinct from the GitHub entry, which connects to GitHub’s own hosted MCP server. If you don’t see either, contact the C1 support team to enable it for your tenant.

Option 1: Set up per-user OAuth

With per-user OAuth, you register one GitHub OAuth app and each user authorizes individually. This keeps every action attributable to the user who took it, with only the access that user already has in GitHub.

Create a GitHub OAuth app

Register an OAuth app in GitHub so C1 can prompt each user to authorize with their own account. For the full walkthrough, see GitHub’s latest guide to creating an OAuth app.

1. In GitHub, go to Settings > Developer settings > OAuth Apps and select New OAuth App.

2. Fill in the registration form:

   • Application name — a recognizable name such as C1.
   • Homepage URL — your C1 tenant URL, or https://www.c1.ai.
   • Authorization callback URL — set this exactly to https://accounts.conductor.one/auth/callback. GitHub OAuth apps allow only one callback URL.
3. Select Register application.

4. Copy the Client ID, then select Generate a new client secret and copy the secret. GitHub shows the secret only once.

Register the server with OAuth

With your OAuth app ready, register the server and provide its credentials.

1. Follow Register an MCP server and select GitHub API from the catalog.

2. When you configure authentication, choose per-user OAuth and enter your OAuth app’s client ID and client secret.

3. Save your changes. The first time a user calls a GitHub tool from their AI client, they’re prompted to connect their GitHub account.

Option 2: Use a personal access token

A personal access token authenticates every user as one shared GitHub identity. Use this when per-user attribution in GitHub isn’t required. GitHub offers fine-grained tokens, which are recommended because you can limit them to specific repositories and permissions.

Create a personal access token

Generate a fine-grained personal access token in GitHub for C1 to authenticate with. For the full walkthrough, see GitHub’s guide to creating a fine-grained personal access token.

1. In GitHub, go to Settings > Developer settings > Personal access tokens > Fine-grained tokens, then select Generate new token.

2. Set a token name, an expiration, and a resource owner (your account or an organization).

3. Under Repository access, choose which repositories the token can reach, then grant only the repository permissions you need, such as read access to Contents, Issues, and Pull requests.

4. Select Generate token and copy it. GitHub shows the token only once.

For a shared production setup, create the token from a dedicated service-account user so activity is attributable to C1 rather than a person.

Register the server with a token

With your token ready, register the server and provide it as the credential.

1. Follow Register an MCP server and select GitHub API from the catalog.

2. When you configure authentication, choose Bearer token and paste your personal access token.

3. Save your changes. C1 starts a sync that discovers the tools the GitHub server exposes.

How GitHub API credentials are shared

How GitHub sees your users’ activity depends on the method you chose:

• Per-user OAuth. Each user authorizes with their own GitHub account, so tool calls run under that user’s GitHub identity and inherit only the access they already have. GitHub attributes each action to the individual user.
• Personal access token. Every user’s tool calls use the one token you provided, so GitHub sees a single shared identity. C1 still attributes each call to the individual user in the AI tool usage audit log.

For how shared and per-user credentials work across MCP servers, see Configure authentication.

Discover and govern tools

After you register the server, C1 runs tool discovery against GitHub. Discovered tools appear on the server’s Tools tab.

Each tool starts as either Pending review or automatically Approved, depending on the option chosen when the server was set up or your tenant’s default tool settings in AI > MCP > Settings. See Require tool approval and Default tool classification.

Before anyone can call a GitHub tool, it must be approved, added to a toolset, and bound to an access profile. Continue to Govern tools and toolsets to set this up.

Tool discovery runs even if your credentials are incorrect, so seeing discovered tools doesn’t confirm that authentication is working. You confirm your GitHub credentials when an approved user successfully calls a GitHub tool from their AI client.

Manage your GitHub credentials

• Rotate the OAuth client secret in your GitHub OAuth app under Settings > Developer settings > OAuth Apps, then update the secret on the server’s authentication settings in C1.
• Rotate a personal access token by generating a new one in GitHub and updating it in C1. Set an expiration on the token so it rotates on a schedule.
• Adjust access by editing the OAuth app’s scopes or the token’s repository permissions in GitHub.