Reading · Developers Digest

This site does not allow itself to be embedded. You can still read it on the original site — the toolbar below keeps your place in the directory.

GitHub now lets enterprise owners install third-party GitHub Apps on their enterprise account, and lets any user or organization create apps with enterprise permissions. This opens the enterprise management layer to the broader ecosystem - with a hard security boundary around the most powerful permission set.

On August 7, 2026, GitHub opened up the top of its platform hierarchy. [Enterprise owners can now install public GitHub Apps](https://github.blog/changelog/2026-08-07-enterprises-can-now-install-third-party-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](https://docs.github.com/en/enterprise-cloud@latest/apps/using-github-apps/installing-a-github-app-on-your-enterprise) spell out explicitly. ## What an enterprise-installed app can actually do The [docs](https://docs.github.com/en/enterprise-cloud@latest/apps/using-github-apps/installing-a-github-app-on-your-enterprise) 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](https://developersdigest.tech/blog/agent-identity-security-layer-ai-workflows) are built around: more capability, narrower boundaries. ## Continue Reading - [GitHub Copilot SDK Hits GA: Embed the Copilot Agent Runtime in Your Own Apps](https://developersdigest.tech/blog/github-copilot-sdk-generally-available-2026) - the other big opening of GitHub's platform surface to outside builders - [Zero-Touch OAuth for MCP: Enterprise Auth Gets Practical](https://developersdigest.tech/blog/zero-touch-oauth-mcp-enterprise) - how enterprise-managed authorization is removing per-user auth friction for agent tooling - [Agent Identity Is the Missing Security Layer for AI Workflows](https://developersdigest.tech/blog/agent-identity-security-layer-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](https://developersdigest.tech/blog/ai-agent-auth-platforms-comparison-2026) - how installation and token flows work across the auth platforms - [GitHub Malware Advisories Now Cover Eight Package Ecosystems](https://developersdigest.tech/blog/github-malware-advisories-eight-ecosystems-2026) - GitHub's expanding security tooling for the platform - [GitHub Models Is Retired: What to Use for Model Access Now](/blog/github-models-retired-2026) ## Sources - [Enterprises can now install third-party GitHub Apps - GitHub Changelog](https://github.blog/changelog/2026-08-07-enterprises-can-now-install-third-party-github-apps) - [Installing a GitHub App on your enterprise - GitHub Docs](https://docs.github.com/en/enterprise-cloud@latest/apps/using-github-apps/installing-a-github-app-on-your-enterprise)

GitHub Apps Can Now Be Installed at the Enterprise Level, Opening the Platform to Third-Party Integrators

Comments