Skip to main content

Bring Your Own GitHub App: Connecting Azure SRE Agent to Enterprise Repositories

· 6 min read
Azure SRE Agent Team

What if your SRE agent could access your enterprise GitHub repositories the same way your CI/CD pipelines do — with a governed service identity, not a personal token?​

Azure SRE Agent connects to your GitHub repositories to build rich context about your systems — source code, infrastructure definitions, deployment configs, skills, runbooks, and operational history. This context is what turns generic troubleshooting into root cause analysis that points to the exact file, the exact commit, the exact config change.

For teams on github.com, connecting is a quick OAuth sign-in. Today, we are extending that same deep context to GitHub Enterprise Cloud — and introducing Bring Your Own GitHub App as a first-class authentication model for enterprise teams that need governed, app-based access to their repositories.

Enterprise GitHub, enterprise identity​

Large organizations run on GitHub Enterprise Cloud with EMU (Enterprise Managed Users). In these environments, every identity is governed centrally — tokens are scoped by policy, rotated on schedule, and tied to individual humans.

When an SRE agent needs to access your repositories, the identity it uses matters. With a GitHub App, the agent operates under a service identity registered and owned by your organization. Every repository operation — every clone, every issue query, every file read — is attributed to the App's installation, not to an individual engineer. Your security and compliance teams can trace agent activity to a governed service identity, and your audit logs reflect exactly what happened.

GitHub Apps are the same identity model enterprises already use for CI/CD pipelines, deployment automation, and internal tooling. BYO App extends it to your SRE agent.

How it works​

When you bring your own GitHub App to Azure SRE Agent, the authentication flow uses short-lived tokens with explicit permissions:

Your organization registers a GitHub App on your GHE instance (or github.com) with the specific repository permissions you choose — Contents Read, Metadata Read, and optionally Issues or Pull Requests.

The App's private key lives in Azure Key Vault. The agent's managed identity reads the PEM at runtime, mints a JWT, and exchanges it for an installation token that expires in about an hour. The private key is not persisted outside Key Vault — it is read transiently to mint tokens and then discarded from memory.

Permissions are declared, not inherited. The App has exactly the access you configured at registration. The agent cannot exceed those boundaries regardless of who set it up.

Token refresh is automatic. No human token to expire, no refresh chain to maintain. The agent mints new installation tokens as needed.

For organizations managing multiple GitHub instances — say, one for platform engineering and another for application teams — each instance gets its own GitHub App with its own Key Vault secret. You can assign a different user-assigned managed identity per App for security isolation. Disconnecting one host does not affect others.

What your agent does with GitHub access​

Once connected, your agent uses GitHub for more than source code. Repositories hold the artifacts that define how your services run — and how your agent reasons about them:

Source code and infrastructure definitions. The agent reads application code, Bicep templates, Terraform configurations, and Dockerfiles to understand what a service actually does — not what the docs say it does.

Skills and runbooks. Teams store agent skills, response plans, and operational runbooks as files in repositories. GitHub access lets the agent load and update these artifacts directly.

Configuration and deployment history. Helm charts, pipeline definitions, environment configs, and release manifests give the agent the context to correlate an incident with what changed and when.

Issues and pull requests. The agent can search issues for known problems, check recent PRs for regression candidates, and create issues or PRs when it identifies a fix.

Logs tell the agent what happened. Code tells it why. Your skills and runbooks tell it what to do about it.

The difference with BYO App is the identity under which all of this happens. These operations occur under your organization's App identity — with the permissions you declared, the audit trail you govern, and the key lifecycle you control.

GitHub Enterprise Cloud hosts​

For GitHub Enterprise Cloud domains (*.ghe.com), the Code Access wizard automatically selects BYO App as the authentication method. This is by design — GHE Cloud hosts use App-based authentication exclusively.

The setup:

  1. Create a GitHub App on your GHE instance. Set Contents: Read and Metadata: Read at minimum. Install it on the repositories your agent needs.
  2. Store the private key in Azure Key Vault. Full PEM content as a secret.
  3. Grant the agent's managed identity Key Vault Secrets User on that vault.
  4. Enter Client ID and Key Vault secret URI in Code Access. The agent validates credentials and loads your repositories.

BYO App on github.com works the same way — useful when your organization's policy requires App-based authentication even for public GitHub.

The compound effect​

BYO App amplifies every other SRE Agent capability for enterprise teams:

BYO App + Deep Context → Your agent continuously reads enterprise-hosted code, builds persistent memory, and compounds its understanding of your systems — all under a governed service identity.

BYO App + Incident response → Alerts fire, the agent correlates logs with actual enterprise code. Root cause references specific files and line numbers from your GHE repositories.

BYO App + Scheduled tasks → Automated code analysis, compliance checks, and drift detection run against your enterprise repositories on a schedule — with audit logs attributing every operation to your App.

BYO App + MCP connectors → Combine enterprise GitHub context with Datadog, Splunk, PagerDuty, or any MCP-connected system. The full picture in one conversation.

Enterprise repository access turns your agent from a diagnostics tool into a system expert — one that knows your code, your configs, and your deployment history.

Multiple ways to connect GitHub​

BYO App is the enterprise authentication model, and it's the focus of this post. Azure SRE Agent also supports several other GitHub connection paths depending on your team's needs:

Connection pathBest for
OAuthQuick interactive setup on github.com — sign in and go
PATService accounts or environments where OAuth popups aren't available
BYO GitHub AppEnterprise governance, EMU environments, and *.ghe.com hosts
GitHub MCPBroad GitHub tool coverage with MCP governance controls

You can use multiple paths on the same agent. For example, Code Access with BYO App for enterprise repository context, plus a GitHub MCP connector for broader tool operations. Each path serves different runtime behaviors and can be configured independently.

For a full comparison of all four paths, auth support by host, and permissions guidance, see the GitHub Connector capability page.

Getting started​

  1. Set Up GitHub BYO App Connector — Step-by-step for github.com or *.ghe.com
  2. Connect GitHub Enterprise Cloud — Detailed GHE walkthrough
  3. GitHub Connector overview — Compare all four connection paths and auth types

Resources​