Anomity Integrates with GitHub
- Anomity now connects to GitHub. The connector reads the GitHub Apps installed on your organization and every permission each one holds, GitHub Copilot seat assignments, and the org's webhooks, and lands them in the AI Applications inventory next to Google Workspace grants.
- It is part of the launch of cloud discovery, Anomity's third collector: access to company code granted in the cloud, which no endpoint or network control sees after the install click.
- Permissions are scored with read and write tiered apart: a read-only app can never score critical, while write and admin permissions and any access to secrets always count as sensitive.
- Each installation also shows which repositories it reaches: every repository in the org, including ones created later, or only selected ones, with a link to the installation's own page on GitHub where the exact list lives.
- Setup is a one-click GitHub App install. Anomity mints short-lived installation tokens and stores no GitHub secret for the connector. A fine-grained personal access token with organization administration read access is the fallback.
- GitHub shows which apps are installed. Anomity shows which of them are AI, how far each can reach, and how that lines up with the coding agents its Endpoint Sensor sees on developer machines.
Anomity now integrates with GitHub. Connect a GitHub organization and Anomity reads the GitHub Apps installed on it and the permissions each one holds, the GitHub Copilot seats assigned in the org, and the org's webhooks, then classifies and risk-scores all of it in the AI Applications inventory. The connector is available today from Settings, under Integrations, and ships together with the Google Workspace connector as the launch of cloud discovery.
This post explains what the connector reads, how it scores GitHub permissions, how it connects, and why the code host is one of the first places we look for AI the sensors cannot see.
Why GitHub, and why now
AI coding tools increasingly reach your code without touching a developer's machine. A code review bot, a coding agent that opens pull requests, an AI app builder that pushes generated code to a repository: each arrives as a GitHub App installed on the organization. One administrator approves the install, and from then on the vendor's servers act on your repositories with whatever permissions the App was granted, from their own infrastructure. The endpoint never sees it, and neither does the network.
That makes the org's installed Apps the code-side twin of the OAuth grants employees give in Google Workspace, and the same governance questions apply. Which of these are AI? Which can write, administer or read secrets? Which vendor is behind each one? We made the general case in our guide to non-human identity governance: an integration that can act needs an owner and a reason to exist. And for Copilot specifically, the org-level controls we describe in governing GitHub Copilot in the enterprise only help if someone checks they are switched on.
What the connector reads
| From GitHub | What Anomity records |
|---|---|
| GitHub App installations | One row per App installed on the org. Every permission the App holds becomes a scope on the row, written the way GitHub writes it, for example contents:write or organization_administration:read. |
| GitHub Copilot | When Copilot is enabled and readable: one row with the logins of the people holding a seat, the most recent activity across seats, and a note on whether Copilot content exclusion is configured, or whether every repository is exposed to Copilot. |
| Org webhooks | One row per webhook, named by the host it delivers to, with the events it subscribes to. Webhooks are third-party integration endpoints, and some of them point at AI services. |
| Classification and risk | For every row: AI or not, vendor, category, a 0 to 100 risk score with a level, and the human-readable reasons behind it. |
Copilot and webhooks are read on a best-effort basis. If the org has no Copilot, or the connection cannot see webhooks, those reads are skipped and the App inventory still completes.
How GitHub permissions are scored
GitHub permissions arrive as a permission and an access level, and the access level matters more than anything else. We tier read and write apart on purpose: read permissions such as contents:read, administration:read or members:read weigh below the line where a permission counts as sensitive, so an App that can only read can never aggregate to critical. Write and admin permissions sit above it, with organization or repository administration at the top, followed by Actions and workflow write, contents write, and pull request, issue, deployment and package write. Secrets are the exception to the read tier: any access to secrets is sensitive, because reading a secret is the whole attack.
The App's score starts from its strongest permission, rises a little for each additional sensitive one, and rises again when Anomity does not recognize the vendor. The reasons are shown on the row, so a high score reads as 'GitHub org/repo administration (write)' rather than a number. Anomity's own discovery App is recognized as first party, carries an ANOMITY badge and is capped at low: the tool doing the looking should never appear as a finding against you.
Which repositories an App can reach
A permission list says what an App may do. It takes the repository scope to say where, and a later update to the connector added it. 'This App holds administration write' is a scope; 'on every repository in the org, including the ones created next month' is a finding. Each installation now shows which of the two it is:
- All repositories. Shown with a warning and a plain explanation that the permissions extend to repositories created in the future. This is most of the answer, and GitHub returns it in every connection mode.
- Selected repositories. Where GitHub returns the names, they are listed. In most setups GitHub does not let a third party read another App's repository selection, so the console links straight to that installation's page on GitHub, where an org owner sees the exact list, rather than showing an empty one.
How it connects
The preferred connection is a one-click install of the Anomity GitHub App, which means no long-lived GitHub secret is stored for the connector at all.
- In Anomity, open Settings, then Integrations, and choose to connect GitHub.
- GitHub opens the Anomity App's install page. Pick the organization and approve. The App asks for organization administration read access, which is what GitHub requires to list the Apps installed on an org.
- GitHub returns you to Anomity, which binds the installation to your tenant. Before binding, Anomity checks that the installation actually belongs to the person who completed the flow, and an installation can be bound to only one tenant.
- Click Test, then Sync. Each sync mints a short-lived installation token from the Anomity App; nothing reusable is kept.
If installing an App is not an option, a fine-grained personal access token works as a fallback. It needs organization administration read access with the org, not a user, as the resource owner. A classic token with admin:org also works. A token is encrypted at rest and never returned by any Anomity API. Viewing the inventory takes an analyst role, changing the connector takes an admin role, and every change and manual sync is written to Anomity's audit trail.
What this release is, and is not
- It reads and scores. It does not uninstall Apps, change permissions or remove webhooks. Those decisions stay with your org owners, in GitHub.
- It refreshes every six hours and on demand. An App uninstalled from the org drops out of the inventory on the next sync.
- It does not raise findings yet. Policy evaluation and new-app notifications are follow-ups on the same inventory.
- Who installed an App is not on the installation. GitHub records an installation as an org action, not as consent by individual employees, so the row describes the App and its reach, not a list of people.
How Anomity and GitHub fit together
The two halves of AI-assisted development live in different places. On the developer's machine, the Endpoint Sensor inventories the coding agents, MCP servers, extensions, skills, hooks, CLIs and secrets in use, and decides allow, deny or log at the agent hook before a tool call runs. In the org, the AI that reaches code from someone else's servers is a list of installed Apps. The GitHub connector puts that list in the same inventory as the Google Workspace grants, and the AI behind Microsoft Entra and Atlassian lands there too. Teams on GitLab get the same view, plus GitLab Duo posture, from the GitLab connector. Teams on GitLab get the equivalent view from the GitLab connector.
GitHub remains the place where Apps are installed and removed; Anomity does not replace it, or the code scanning, EDR and DLP tools around it. It tells you which of the installed Apps are AI, how far each can reach, and whether the Copilot controls you expect are in place. The consent-and-token side of the same problem is covered in AI and OAuth: the risk report. Anomity collects metadata only, redacts secret values on the endpoint, and is SOC 2 Type II attested. To see the AI holding access to your own GitHub org, book a 30-minute demo.
Frequently asked questions
What does the Anomity GitHub integration do?
It connects one GitHub organization to Anomity's cloud discovery. The connector lists the GitHub Apps installed on the org and the permissions each holds, the GitHub Copilot seats assigned in the org, and the org's webhooks. Each becomes a row in the AI Applications inventory with a vendor, a category, an AI classification and a risk score, alongside the OAuth apps discovered from Google Workspace and other sources.
Why do GitHub Apps matter for AI security?
Many AI coding tools reach code as GitHub Apps: review bots, coding agents that open pull requests, and AI app builders that push to a repository. Installing an App on an org is a single administrator action, and from then on the vendor's servers can act on repositories with whatever permissions the App was granted, from their own infrastructure. Nothing new runs on a laptop, so endpoint and network controls see none of it.
How are GitHub permissions scored?
Each permission an App holds, such as contents:write or administration:read, maps to a weight and a label. Read permissions are deliberately weighted below write and admin permissions, so an App that can only read cannot aggregate to critical. Write and admin permissions, and any access to secrets, count as sensitive. The score also rises when the App holds several sensitive permissions and when its vendor is not one Anomity recognizes.
What does Anomity show about GitHub Copilot?
When Copilot is enabled for the org and the connection can read it, Copilot appears as one row in the inventory with the logins of the people holding a seat, the most recent activity across those seats, and a note saying whether Copilot content exclusion is configured. If Copilot is not enabled or not readable, the rest of the sync completes normally.
Can Anomity show which repositories an App can access?
It shows whether an installation covers all repositories in the org, including ones created in the future, or only selected ones, and an all-repositories installation is flagged with a warning. For selected installations, GitHub generally does not let a third party read another App's repository list, so the console links to that installation's page on GitHub, where an org owner sees the exact list. Where GitHub does return the names, they are listed.
What access does Anomity need?
With the preferred one-click install, the Anomity GitHub App needs organization administration read permission, which is what GitHub requires to list the Apps installed on an org. Anomity mints a short-lived installation token for each sync and stores no secret for the connector. The fallback is a fine-grained personal access token with organization administration read access, with the org as the resource owner, which is stored encrypted and never returned by any API.
Does Anomity flag its own GitHub App?
No. Anomity's own App is recognized as first party: it carries an ANOMITY badge in the inventory and its risk is capped at low, so the tool doing the discovery is never reported to you as a third-party risk.
Does the integration change anything in GitHub?
No. The connector only reads. In this release it inventories, classifies and scores; it does not uninstall Apps or change permissions, which stays with your GitHub org owners.
