Notifications
Clear all
Topic starter
25/06/2026 3:24 pm
TL;DR: GitHub Apps replace user-tied personal access tokens with short-lived installation access tokens that are managed at the organisation level, narrowing the misuse window for exposed credentials and simplifying lifecycle control, according to Aembit. The governance shift is not just shorter token TTLs, but removing a single-user ownership model that creates avoidable lifecycle drift.
NHIMG editorial — based on content published by Aembit: GitHub App tokens for API automation and lifecycle control
By the numbers:
- 44% of NHI tokens are exposed in the wild, being sent or stored over platforms like Teams, Jira tickets, Confluence pages, and code commits.
- 91% of former employee tokens remain active after offboarding, leaving organisations vulnerable to potential security breaches.
Questions worth separating out
Q: How should security teams replace personal access tokens in GitHub automation?
A: Security teams should replace user-owned PATs with organisation-scoped app credentials wherever the automation is meant to outlive the original user.
Q: When do personal access tokens create more risk than they reduce?
A: PATs become risky when they are used for shared automation, long-lived integrations, or workflows with unclear ownership.
Q: What breaks if GitHub API access is still tied to a single user account?
A: Offboarding, access review, and emergency revocation all become slower and less reliable when the credential belongs to one user.
Practitioner guidance
- Inventory every PAT-backed GitHub workflow Map each token to the repository, script, owner, and business function it supports.
- Replace user-owned automation with GitHub App installations Where scripts or integrations call GitHub APIs, move them to organisation-scoped app installations with repository-level permissions and short-lived tokens.
- Separate key custody from workflow operation Store signing keys in controlled secret storage, restrict who can generate installation tokens, and log each issuance event so token creation is auditable.
What's in the full article
Aembit's full article covers the operational detail this post intentionally leaves for the source:
- Step-by-step GitHub App creation and installation flow for organisation settings
- JWT generation process using the app client ID and private key
- Exact API call format for generating an installation access token
- Example curl invocation patterns for repository action queries
👉 Read Aembit's guidance on using GitHub App tokens for API automation →
GitHub app tokens: what changes for API automation teams?
Explore further
25/06/2026 4:56 pm
GitHub App tokens are a machine identity pattern, not a token-format tweak. The article is really about replacing user-bound credentials with organisation-bound workload credentials. That matters because access governance changes when the subject is a script or integration rather than an employee. For NHI programmes, the relevant question is whether the credential follows the workload lifecycle or the human lifecycle. The practitioner conclusion is to govern the workload as the identity subject, not the user who first created the token.
A few things that frame the scale:
- 44% of NHI tokens are exposed in the wild, being sent or stored over platforms like Teams, Jira tickets, Confluence pages, and code commits, according to The 2025 State of NHIs and Secrets in Cybersecurity.
- 91% of former employee tokens remain active after offboarding, leaving organisations vulnerable to potential security breaches, according to Entro Security.
A question worth separating out:
Q: Who should own lifecycle control for machine credentials used in CI and scripts?
A: The organisation that depends on the automation should own lifecycle control, not the individual who first created the token. That means clear responsibility for issuance, expiry, revocation, and repository scope, with those controls reviewed alongside the workflow itself.
👉 Read our full editorial: GitHub app tokens reduce PAT lifecycle risk for API automation
