---
title: "GitHub"
description: "Scoped GitHub token access for AI agents"
url: "https://gazebohq.com/services/github"
---

GitHub automation can read proprietary source, alter workflows, open pull requests, create releases, and manage issues. A token delivered to an agent should therefore be designed around a repository and operation, not around convenience. Prefer a fine-grained personal access token, GitHub App installation token, or other GitHub-supported identity with only the required repositories and permissions; account for organization approval, SSO authorization, token expiry, and branch protection before an agent runs. Gazebo brokers the resulting credential to the approved workflow rather than putting it in every developer tool or CI variable.

## Why do AI agents need scoped GitHub access?

GitHub’s token or App permissions are the capability boundary: a Gazebo profile cannot turn a repository-admin token into a read-only token once released. Broad classic tokens also make a compromised agent capable of reaching unrelated repositories or changing automation. Pair narrowly configured GitHub credentials with per-agent retrieval grants, then correlate Gazebo events with GitHub audit logs, commit signatures, Actions logs, and API activity. Removing a profile stops new issuance from Gazebo; revoke the GitHub token or installation, and investigate pushed commits or workflow changes, if the value may have escaped.

## How it works

1. Create a GitHub identity with explicit repository selection and minimum permissions, such as Contents read for analysis or Pull requests write for a PR bot. Verify SSO, organization policy, expiry, and any GitHub App installation scope.
2. Store that token separately and assign it only to the agent profile that performs the matching task; keep write and read-only workflows on different credentials.
3. The runtime requests it via MCP. Gazebo authorizes the profile before release, avoiding a permanently shared token in local configuration.
4. Use Gazebo’s retrieval log with GitHub audit/API events to trace a proposed or completed action. Branch protections, required reviews, and Actions permission settings remain essential controls after authentication.
5. Disable a profile for immediate containment. If a token was exposed, revoke it at GitHub, issue a replacement to the remaining profile, and review repository, workflow, and deployment changes made during the exposure window.

## Use cases

**Repository-scoped tokens per agent:** Configure repository selection in the GitHub fine-grained token or App installation, then place that credential behind the matching Gazebo profile. An agent assigned to one repository cannot rely on Gazebo naming alone for isolation; GitHub must reject access to every other repository. Review organization token policy and SSO authorization before deployment.

**Read-only vs write access by workflow:** Use separate GitHub credentials with genuinely different permissions: read-only Contents and metadata for analysis, versus only the specific pull-request or contents permissions required for an authoring bot. Map them to separate profiles and retain branch protections so a write-capable agent cannot bypass review merely because it authenticated successfully.

**Contractor isolation:** Give the contractor workflow a time-bounded, repository-limited credential and a distinct Gazebo profile. Remove the profile at the end of the engagement and revoke or expire the GitHub credential if the execution environment is no longer trusted. Audit access records should be matched against GitHub’s organization audit log for actual cloning, pushes, and permission changes.