GitHub Access Management
Governs how users are added to, removed from, or have their permissions changed across GitHub repositories and teams, with approval workflows and automatic permission provisioning.
- Handles add and remove requests for repositories and GitHub teams
- Checks current permissions and identifies the right groups
- Routes every request through an approval chain before any change is made
- Provisions or revokes access automatically once approved
- Integrates into the employee offboarding flow to ensure clean access removal
What GitHub Access Management does
GitHub Access Management governs who can reach which repositories and teams. Add and remove requests both run through it: the agent reads current permissions, works out the right groups to change, routes the request through an approval chain before anything is touched, and provisions or revokes access automatically once approved. It also plugs into employee offboarding, so a departure removes source code access as part of the same flow rather than as a task someone remembers later.
Who GitHub Access Management is for
Engineering leads, platform teams, and IT owners of the GitHub organisation, plus the security teams who have to answer for who can read the source.
GitHub permissions get granted in DMs and never audited. Access is added to unblock someone, the grant outlives the reason, and repository and team membership drifts away from anything anyone would approve today. Offboarding is the sharpest edge: source code access is often the last thing removed, if it is removed at all.
How GitHub Access Management works
A request to add or remove access to a repository or GitHub team, or an employee offboarding that includes GitHub.
- Take the add or remove request
Handles both directions for repositories and GitHub teams through one governed flow.
- Read current permissions
Checks what the user already has and identifies the right groups to change, so the request is scoped correctly.
- Route for approval
Sends every request through its approval chain before any permission is modified. Nothing changes on the strength of the ask alone.
- Provision or revoke
Applies the approved change automatically, adding or removing the access without a manual step in the GitHub UI.
- Close the loop on offboarding
Runs as part of the employee offboarding flow, so a departure removes repository and team access cleanly.
Repository and team membership that reflects approved decisions, applied automatically, with departures removing access as part of offboarding rather than after it.
Capabilities
- Add and remove in one flow - Grants and revocations for repositories and GitHub teams are handled by the same governed path.
- Current-permission awareness - Reads existing access and identifies the right groups before proposing a change.
- Approval before any change - Every request passes through an approval chain first, so no permission moves unreviewed.
- Automatic provisioning and revocation - Approved changes are applied without anyone clicking through GitHub settings.
- Offboarding integration - Slots into the employee offboarding flow so source code access is removed as part of the departure.
- Auditable decisions - Each change carries the request, the approval, and the applied result.
Main use cases
New engineer joining a service team - An engineer needs write access to three service repositories. One request, the agent identifies the right teams, the lead approves, and access is provisioned - instead of a chain of DMs and a partially completed setup.
Departure that actually removes source access - An engineer leaves. Because the agent is part of the offboarding flow, repository and team membership is revoked with everything else, so source code access does not outlive the employment.
Answering "who can read this repository?" - A security review asks how access to a sensitive repository is controlled. Every add and remove ran through an approval chain and was applied automatically, so the trail is the answer.
Integrations
| Integration | Role in the agent flow |
|---|---|
| GitHub | Reads current repository and team permissions, and applies the approved add or remove |
| Your connected identity provider (e.g. Okta, Microsoft Entra ID, Google Workspace) | Resolves the requester and the approvers, and links GitHub identity to the employee record |
| Harmony Service Desk | Native ticketing - creates the ticket, tracks it, and records the outcome |
| Harmony Notifications | Delivers updates through each recipient's preferred channel: Slack, Teams, or email |
FAQ
Both. Add and remove requests are handled for repositories and for GitHub teams, since in practice access is managed through a mix of the two.
Meet more Agents
