Repository providers

A connected repository points at a clone URL. A repository provider is what makes that clone authorized: it holds the credential, decides whether the credential is yours or the workspace's, and resolves which identity an agent's Git operation runs as. Two providers are real today: GitHub on github.com and GitHub Enterprise for managed-user enterprises. They differ almost entirely in how your organization signs in, not in what an agent does once connected. Pick the provider that matches your front door; everything downstream is the same.

This page is the credential half of getting code into reach of an agent. The connect-a-repository page covers the repository itself; this one covers the provider it authenticates through. For the wider map of what Disco Parrot connects to, and why a repository provider is a different category from a work-item integration, see integrations and providers.

A provider is a credential with a scope

Configuring a provider is a small piece of administrative work. You give it a name, choose its kind, and connect a credential; the platform stores the credential reference and remembers, per person, which GitHub identity it last authenticated as. From then on, every repository that points at the provider authenticates through it, and every agent that clones one of those repositories gets a token the platform mints from that credential at run time. The agent never holds the credential itself. For each Git operation the platform mints a fresh token, scoped to that one operation, and hands the agent that. The token is the disposable thing; the credential it was minted from stays server-side and never leaves the platform. That boundary is covered in full under approved actions.

That is the whole security shape in one line: the credential is configured once and stays server-side, and the agent works the entire time off short-lived tokens minted from it, never the credential itself. An agent that is compromised, or simply wrong, holds a token scoped to one operation that expires on its own, not a key to your code host. The provider is where you make that true for every repository at once instead of one repository at a time. The credential itself lives in your workspace's own secret store, a per-tenant key vault, under a name tied to the provider, and the platform never reads it back out over the wire: ask a provider about its credential and you get whether one is present and which login it resolved as, never the token.

Managing providers is held by the repo-providers.manage scope, which your admins, owners, and workspace operators carry. Connecting your own credential to a provider is a lighter thing, held by every member through integrations.user-credential.manage, so an admin wires the provider once and each person on the team connects their own GitHub identity to it without an admin in the loop. Viewers can see the providers that exist but cannot connect a credential.

Three ways to hold the credential

GitHub gives you more than one way to authenticate, because real teams sit at different points on the trade-off between simplicity and central control. A provider supports three, and which one you choose decides where the credential lives and whose identity the writes carry.

A GitHub App authenticated through OAuth is the default, and for almost every team it is the one to leave selected. Your organization installs the App once, which defines what the App can reach, and then each person authorizes it for themselves. The result is the best of both halves: an org admin controls what is reachable through the App's installation, and each person's commits and pull requests carry their own GitHub identity, so the audit trail in GitHub reads the way it should, with a named person on every change rather than a shared bot.

A GitHub App installation token is the App without the per-person sign-in. It acts at the level of the installation, which suits a workspace that wants one central credential reaching the repositories with no per-user authorization step. Writes carry the App's identity rather than an individual's.

A personal access token is the simplest setup: paste a token and you are connected. The platform checks it against GitHub the moment you paste it, rejects a token it cannot authenticate, and stamps the resulting login as the Connected as identity, so a typo or an expired token is an answer up front rather than a clone that fails later. Both classic tokens, the ones that start with ghp_, and fine-grained tokens, the ones that start with github_pat_, work for general repository access. A token is scoped to whatever you granted it and acts as you. It is the fastest way to connect one person to one repository, and the least centrally governed: there is no org-level install bounding what it can reach, so the blast radius is exactly whatever you minted the token with, no more and no less. For a single engineer on a single repository, that is often the trade worth making.

App OAuth is the one to default to. It is what the product picks when you create a plain GitHub provider, and it is the only one of the three that gives an org central control over reach and every person their own name on their own commits at the same time. The other two each give up one of those: a personal token gives up the central control, an installation token gives up the personal attribution. App OAuth gives up neither. A GitHub Enterprise provider starts from the host installation instead, since its identities come through your enterprise gateway rather than a personal OAuth authorization.

Which one to pick

The methods are not a menu of equals; one is the default and the other two are for named situations. The decision usually takes one read of where you are:

• A team of more than a handful of people on github.com. GitHub App OAuth. An org admin installs the App once to bound what is reachable, each person authorizes it for their own name, and writes land under real identities. This is the answer for almost everyone.
• A workspace that wants one central credential and does not need per-person attribution. The App installation token. Service-style automation where "the workspace did it" is a fine thing to read in the history.
• One engineer, one repository, no org-level App. A personal access token. The fastest connection there is, scoped to exactly what you grant it, for when the central-control story would be overhead you do not need yet.

When in doubt, App OAuth. The other two exist because real teams have the second and third situations, not because they are alternatives you weigh fresh every time.

Access resolves per person

A provider can hold more than one credential at once: a tenant-wide default the workspace set up, and a personal one you connected for yourself. When an agent's Git operation needs a token, the platform resolves it in a fixed order. Your own credential is used if you have one; the tenant default is the fallback if you do not; and if neither is in place, the operation stops with a clear message rather than running as the wrong identity.

That order is the whole trick: a workspace can default everyone onto one shared App and still see each person's work land under their own name. The few people who need a different identity, an engineer with a personal token for a repository the App does not reach, connect their own and it takes precedence; everyone else rides the tenant default without thinking about it. The agent inherits whichever identity resolves, and the audit trail records the operation against the person whose credential ran it.

The identity picker

When you have authenticated as more than one GitHub identity, the identity picker lets you choose which one a provider is bound to. It is a compact list, reachable from a Change control, of the GitHub logins you have signed in as: each shows its avatar and handle, a check on the one currently in use, and an Enterprise marker on logins that came through a managed-user enterprise. From the same list you can connect an identity you have not used yet, or add a fresh GitHub or GitHub Enterprise credential. The picker is what makes the per-person credential model usable in practice: it is the one place you say use this identity here, and the agent follows.

A provider, resolved per person

Sarah, the analytics lead, sets up the team's GitHub provider once. An org admin has installed the GitHub App on orcette, so she picks GitHub App OAuth, authorizes it as @sarah, and the provider goes green. Every repository the team connects, orcette/insights among them, now points at this one provider.

Maya joins the work a week later. The first time she opens a Flow against orcette/insights, the provider has the tenant App but no credential from her, so her operations would fall back to the tenant default. Maya wants her own commits under her own name, so she authorizes the App as @maya from the identity picker. From then on her runs resolve to @maya, Sarah's resolve to @sarah, and the same provider attributes each person's pull requests to them, off one App install nobody had to duplicate.

Nothing about the repository changed between the two of them. The provider did the resolving, and the per-person order, your credential first and the tenant default behind it, is what made one shared App read as two named people in GitHub's history.

GitHub Enterprise is a managed-user enterprise

The GitHub Enterprise provider is for organizations on GitHub Enterprise Cloud with managed users, where your people sign in to GitHub through your own identity provider and their accounts are provisioned and governed by your enterprise. It is GitHub Enterprise on github.com, reached through your enterprise's sign-in, not a GitHub server you host yourself.

What it needs that the plain GitHub provider does not is your enterprise name, the slug that appears in your enterprise's github.com URLs. The platform normalizes it to lowercase and uses it to route sign-in through your enterprise: instead of sending you to GitHub's ordinary authorization screen, it sends you to your enterprise's single-sign-on gateway at github.com/enterprises/your-slug/sso, GitHub hands you off to the identity provider you configured, and once your identity provider authenticates you, you land back to finish connecting. Disco Parrot never runs the SAML or OIDC exchange itself. GitHub does, the same way it does when your people sign in to github.com directly; the platform only performs the redirect that kicks off your enterprise's sign-in and takes the authenticated identity back from the other side. Your identity provider stays the single front door, and the agent is downstream of it like everyone else.

What a managed user is

If your organization is not already on managed users, the term is worth a sentence. In an ordinary GitHub setup, a person owns their github.com account: they created it, they hold its password, and your organization grants that personal account access to your repositories. In a managed-user enterprise, GitHub flips the ownership. Your enterprise provisions the accounts, your identity provider authenticates them, and a person cannot sign in to their managed account except through your front door. There is no personal password to phish and no account that outlives the employee, because the account was never theirs to keep.

That is why the GitHub Enterprise provider needs your enterprise name and routes sign-in the way it does. It is not adding a security layer of its own; it is standing downstream of the one your enterprise already runs, so an agent reaching your code passes through the same gate your engineers do, governed by the same identity provider and revocable the same instant. Because your identity provider already knows who you are, the enterprise sign-in skips the account picker the plain GitHub flow shows: there is one identity for you behind that gateway, and it picks it. If your organization is not on managed users, the plain GitHub provider is the right one, and this section is context for the day you are.

One practical difference follows from the managed-user model, and it follows from your own controls. A managed-user enterprise governs which surfaces are enumerable, so the repository-listing call the plain GitHub provider relies on is not dependably open. Adding a repository there is therefore direct: you paste the clone URL for each one rather than picking it from a list. It costs one extra paste at connect time and changes nothing downstream. Once a managed-user repository is connected, an agent clones it, works against it, and opens pull requests on it exactly as it would any other GitHub repository. The connection is the only part that differs; the work is the same.

Configure a provider

Providers live under Repositories in Platform, alongside the repositories that point at them. The list shows each provider with the GitHub mark, a kind badge reading GitHub or GitHub Enterprise, and a status: Connected as @login with a green dot when a credential is in place, Not configured with a grey one when it is not. New Provider and the per-row delete are gated to the people who hold repo-providers.manage.

Creating one is a short form: a name, a kind, and a provider identifier that derives from the name the way a repository's does. Choose GitHub for github.com and GitHub Enterprise Cloud, or GitHub Enterprise for a managed-user enterprise, which adds the enterprise-name field. The kind is fixed once you save, so a provider does not change shape under the repositories that depend on it.

The order is forgiving on purpose. You can create the provider now, with its name and kind, and connect the credential later, because the two are often different people's jobs: an admin defines that the workspace authenticates to orcette through a GitHub App, and the engineer who actually holds a GitHub identity connects it when they arrive. A provider with no credential yet reads as Not configured in the list and blocks nothing until a repository tries to use it, at which point the resolution order produces a clear stop rather than a silent failure. A workspace can run more than one GitHub provider if it needs to, each named explicitly by the repositories that use it; the first one created stands as the default identity surface when nothing more specific is chosen.

Deleting a provider is guarded the same way deleting a repository is. While any repository still points at a provider, the delete is refused and names the repositories that depend on it, so you detach or repoint them first. A provider goes away only once nothing relies on it, which keeps a delete from quietly breaking every repository that authenticated through it.

Why providers are their own thing

It would be simpler, on the surface, to fold the credential into the repository: one form, paste a token, done. Disco Parrot keeps the provider separate because access and code are different concerns that change on different clocks. A credential is something a person holds, an organization governs, and a security review asks about; a repository is just a URL and a branch. Pulling them apart means a workspace can wire its GitHub App once and connect a dozen repositories to it, a person can carry one identity across every repository they touch, and an admin can answer what can agents reach and as whom by looking at the providers rather than auditing every repository one at a time.

For a planner, the provider is the thing that turns "we use GitHub" into something an agent can act on: set up once by an admin and rarely touched after, you connect your GitHub identity the first time and the product remembers, so the next agent run just works. For an engineer, the three credential shapes map to the ways you already authenticate to GitHub, and the identity picker is how you keep reads on the App and writes under your own name. For a lead, the provider is the seam where central control and personal attribution meet: the App installation bounds what is reachable, and each person's identity bounds whose name the work carries. For the person who has to approve connecting a code host, every property they would ask about is fixed and locatable: the credential lives in one named place, resolves per person in a fixed order, mints only short-lived tokens, and never reaches the agent itself. The question of what an agent can do in your repositories stops being an audit and becomes a page you can point at.