GitHub Gives Enterprises a Full Count of Who Holds the Keys

Most security teams can tell you how many people work in engineering. Far fewer can tell you how many credentials those people, and the apps they’ve installed, hold against the company’s source code. That gap is where a lot of trouble starts.

GitHub wants to close it. On September 21, the company announced that GitHub Enterprise Cloud owners can now export a full inventory of every credential that can access their enterprise. The export covers SSH keys, classic and fine-grained personal access tokens (PATs), OAuth app access tokens, and GitHub App user-to-server and installation tokens.

Teams can pull the list as a CSV from Enterprise Settings, under Authentication Security, or through a paginated REST API. They can filter by user, app, credential type, or organization. Each record includes the owner, scopes, creation and expiration dates, and the last time the credential was used. GitHub says teams can correlate that data with audit logs to see how credentials are actually being used.

Access isn’t limited to enterprise owners. GitHub added a fine-grained permission, “View enterprise credentials,” so security or compliance staff can run reviews without holding full admin rights. That’s a small detail, but it matters. The people who audit credentials often aren’t the people who should be able to change enterprise settings. Support for GitHub Enterprise Server is planned for upcoming releases.

The timing makes sense. Credentials have become the easiest way into software supply chains. In May, GitHub disclosed that attackers exfiltrated about 3,800 of its internal repositories after an employee installed a poisoned version of the Nx Console VS Code extension. Researchers noted that extensions like that can reach everything on a developer’s machine, including SSH keys and cloud credentials. GitHub’s response included rotating critical secrets, “with the highest-impact credentials prioritized first.”

That phrase describes the hard part. Prioritizing rotation assumes you know what you have. Many organizations don’t.

GitGuardian’s State of Secrets Sprawl 2026 report puts numbers on the problem. It found 28.65 million hardcoded secrets added to public GitHub in 2025, up 34% from the year before. It also found that 64% of valid secrets detected in 2022 were still active and exploitable as of January 2026. Internal repositories were about six times more likely than public ones to contain hardcoded secrets.

The new inventory doesn’t cover hardcoded secrets. Those are a different problem. But the pattern is the same. Credentials get created for a task, then outlive the task, the project, and sometimes the employee. A PAT made for a one-off migration script three years ago may still carry write access today. An OAuth app someone authorized during a vendor trial may still hold a token. Nobody revoked it because nobody remembered it existed.

Agentic AI raises the stakes. Coding agents, CI bots, and AI assistants all need tokens to read and write code. Every agent a team adds is another non-human identity with its own credentials, often created in a hurry and scoped broadly to get a pilot working. As agents spread across teams, the credential count grows faster than any manual review can keep up with.

“Anyone building with AI can now create credentials, and accountability for them lands back on IT and security,” said Mitch Ashley, vice president and practice lead for CIO & technology buyers and software lifecycle engineering at The Futurum Group. “Enterprises that ignore that gap discover it during incident response, rotating keys they didn’t know existed.”

An exportable inventory changes what a review looks like. Instead of chasing individual org admins for lists, a platform or security team can pull one dataset and ask direct questions. Which tokens have no expiration date? Which haven’t been used in 90 days? Which classic PATs still carry broad scopes when a fine-grained token would do? Which GitHub Apps hold installation tokens in organizations that no longer use them?

For most practitioners, the API is the more useful piece. It lets teams build the review into daily operations. Pull the inventory on a schedule, compare it against the last run, flag new long-lived tokens, and send stale ones to their owners for cleanup. Feed the results into existing SIEM or identity governance tools, so credential hygiene sits next to the identity data security teams already watch.

Ashley said how often teams pull the data matters. “Pulled once a quarter, a credential inventory is an audit artifact,” he said. “Pulled daily via the API and compared run-over-run, it becomes an operating control.”

There are limits. An inventory shows what exists. It doesn’t revoke anything or enforce policy on its own. “The next step to watch is policy enforcement, since an inventory still depends on someone acting on what it finds,” Ashley said. Until then, teams need to decide what “too old” or “too broad” means, and they need a process to act on it. Credentials that live outside GitHub, such as cloud keys stored in a CI variable or a token pasted into a Slack thread, won’t show up here. And GitHub Enterprise Server customers will have to wait.

Still, visibility comes first. You can’t set expiration policies, enforce least privilege, or respond quickly to a breach without knowing which keys are out there and who holds them. For most enterprises, the first export will likely turn up credentials nobody knew were still active. That’s an uncomfortable finding. It’s also the point.