GitHub Apps Can Now Be Installed at the Enterprise Level, Opening the Platform to Third-Party Integrators
TL;DR
GitHub Apps can now be installed at the enterprise level, opening enterprise management to third-party integrators, with a security boundary on top permissions.
Last updated: August 8, 2026
On August 7, 2026, GitHub opened up the top of its platform hierarchy. Enterprise owners can now install public GitHub Apps created outside their enterprise on their enterprise account, and any user or organization can now create GitHub Apps with enterprise permissions. Until now, only the enterprise's own teams could build apps that touched the enterprise account itself. The management layer of the platform - org creation, SCIM provisioning, cross-org installs - is no longer GitHub-owned territory.
Here is what changed, where the boundaries are, and why the security carve-out matters more than the feature itself.
What shipped#
Two changes landed together:
- Third-party installs. An enterprise owner can install a public GitHub App created by any account on their enterprise. Integrators get a real product surface: apps built for enterprise management scenarios - provisioning, org lifecycle, compliance - can now reach the enterprise account the same way they already reach organizations and repositories.
- Enterprise permissions for everyone. Any user or organization can register a GitHub App that requests enterprise-level permissions. Previously, enterprise permissions were only available to apps owned by or within an enterprise.
An enterprise-level installation is scoped to the enterprise account itself. It does not grant access to the organizations or repositories inside it. Apps that want org or repo resources still install there separately, which GitHub's installation docs spell out explicitly.
What an enterprise-installed app can actually do#
The docs list the supported operations:
- Create organizations in the enterprise (GraphQL
createEnterpriseOrganization) - Manage users at the enterprise level
- Create and manage GitHub App installations in organizations
- Manage enterprise custom repository properties
- Call the enterprise SCIM APIs
The installation token carries the same rate limit as a GitHub Enterprise Cloud organization, and limits are per installation: an app installed on one enterprise and two organizations holds three tokens with three independent budgets.
The preview comes with real limitations. Webhooks are not supported at the enterprise level, so no event-driven integrations for enterprise activity. Not every enterprise API accepts app tokens yet. And the installation flow has a requirement worth noting: apps can request non-enterprise permissions too, but only the enterprise permissions are granted at install time, and a third-party app must be public for a different enterprise to install it.
The security boundary is the real story#
The most interesting part of the announcement is what is explicitly blocked. Apps that request the Enterprise organization installations and Enterprise organization installation repositories permissions cannot be installed across enterprise boundaries. The changelog says it plainly: "This API set is extremely powerful because it can manage all app installations across organizations in an enterprise."
That is the difference between an app that manages one enterprise and an app that could reach into every organization inside it - or, installed on many enterprises, every organization in all of them. GitHub is treating that capability as a single-tenant function: the app must be owned by the enterprise it serves. If your app uses those permissions, it cannot be installed across enterprises; if it is already installed across multiple enterprises, it cannot add the permission.
This is the right call and a familiar pattern. The strongest permissions stay tied to the account that owns the resource, and third-party reach stops at the boundary where one tenant's apps start managing another's orgs. For integrators it means designing around the permission split from day one: request the cross-tenant permissions only if your product is genuinely single-tenant enterprise tooling, and build the org-install flow as the default for everyone else.
Why this matters for developers#
For the platform ecosystem, this is the missing distribution channel. GitHub Apps have been installable on organizations and repositories for years, but the enterprise account was a sealed tier. Now an independent developer can ship a provisioning tool or an org-lifecycle product with a genuine enterprise story, not a workaround that installs on every org one by one.
For agent and AI tooling, the timing is not accidental. Enterprise agents increasingly need administrative reach - creating sandbox orgs, wiring SCIM, managing installations - and every agent integration we have covered runs through the same identity and permission machinery. The question is always scoped access, not raw ability. GitHub's decision to open the layer while keeping the org-install permission single-tenant is the same tradeoff agent identity systems are built around: more capability, narrower boundaries.
FAQ#
Can third-party GitHub Apps be installed on an enterprise account?#
Yes. Since August 7, 2026, enterprise owners can install public GitHub Apps created outside their enterprise on the enterprise account, and any user or organization can create GitHub Apps that request enterprise permissions. A third-party app must be public for a different enterprise to install it.
Does an enterprise-level installation give access to organizations and repositories?#
No. The installation is scoped to the enterprise account itself. Apps that need organization or repository resources still have to be installed there separately.
What can an enterprise-installed GitHub App do?#
Per GitHub's docs, it can create organizations in the enterprise, manage users at the enterprise level, create and manage GitHub App installations in organizations, manage enterprise custom repository properties, and call the enterprise SCIM APIs. Webhooks are not supported at the enterprise level, and not every enterprise API accepts app tokens yet.
Which permissions cannot be used across enterprise boundaries?#
Apps that request the Enterprise organization installations and Enterprise organization installation repositories permissions cannot be installed across enterprises, because that API set can manage all app installations across organizations in an enterprise. An app already installed on multiple enterprises cannot add those permissions.
Continue Reading#
- GitHub Copilot SDK Hits GA: Embed the Copilot Agent Runtime in Your Own Apps - the other big opening of GitHub's platform surface to outside builders
- Zero-Touch OAuth for MCP: Enterprise Auth Gets Practical - how enterprise-managed authorization is removing per-user auth friction for agent tooling
- Agent Identity Is the Missing Security Layer for AI Workflows - scoped capabilities, revocation, and audit trails for agents acting across tools
- AI Agent Auth Platforms Compared: Arcade vs Composio vs Nango vs Stytch - how installation and token flows work across the auth platforms
- GitHub Malware Advisories Now Cover Eight Package Ecosystems - GitHub's expanding security tooling for the platform
- GitHub Models Is Retired: What to Use for Model Access Now
Sources#
Get the next deep dive like this in your inbox
One email a week on News and the rest of the AI dev stack. Free.
Read next on AI coding tools
GitHub Models Is Retired: What to Use for Model Access Now
GitHub Models is retired as of July 30, 2026 - the playground, inference API and BYOK are gone. The shutdown timeline and where to get model access now.
6 min readClaude Code Cross-Session Messaging: Your Agents Can Now Talk to Each Other
Claude Code v2.1.224 lets one running session message another over a first-party channel - plain text, permission-aware, with approval dialogs when bypass-mode sessions talk to each other. Here is what ships, how delivery and inbound controls work, and where the feature stops.
7 min readGitHub's AutoGPT Playbook: The Repo Instruction File Is Now an API for Other People's Agents
AutoGPT's playbook for AI pull requests: AGENTS.md placement, enforced PR templates, trigger-phrase skills and a CLA that keep agent-heavy repos reviewable.
7 min readNew here? Start with
Technical content at the intersection of AI and development. Building with AI agents, Claude Code, and modern dev tools - then showing you exactly how it works.
