A personal access token is a reusable credential that authenticates a user or service to an API without a password. In practice, it inherits the permissions of the owning identity, which makes it a high-value non-human identity when it is exposed, copied, or left valid after the original task is complete.
Expanded Definition
A Personal Access Token, or PAT, is a user-bound credential that lets an application call an API without reusing a password. Unlike a session cookie, it is typically issued for automation, scripts, or integrations and can persist until revoked.
In NHI practice, a PAT should be treated as a Non-Human Identity because it carries the permissions of the owning account and can act independently of a person at runtime. That makes it useful, but also dangerous when teams confuse convenience with containment. Definitions vary across vendors on whether PATs are “service credentials” or “user tokens,” yet the security outcome is the same: whoever holds the token can act as that identity. The OWASP Non-Human Identity Top 10 treats these credentials as governance objects, not just developer utilities.
The most common misapplication is treating a PAT like a disposable password substitute, which occurs when teams issue it broadly, store it in plaintext, and fail to tie it to a specific use case or expiration window.
Examples and Use Cases
Implementing PATs rigorously often introduces lifecycle overhead, requiring organisations to weigh developer speed against tighter issuance, rotation, and revocation controls.
- Short-lived automation for CI/CD jobs that need to clone repositories, publish packages, or call internal APIs without human login prompts.
- Temporary access for a contractor or support workflow where a token must be scoped to one task and removed immediately after completion.
- API integration testing where a PAT is safer than sharing a password, but still must be vault-managed and logged like any other secret.
- Incident response playbooks that use a PAT to access a recovery endpoint, then revoke it once the outage is resolved.
- Platform administration scenarios where a PAT is created for a bot account, aligned to least privilege, and monitored through an approval workflow.
The operational lesson is visible in incidents such as the Salesloft OAuth token breach and the JetBrains GitHub plugin token exposure, where exposed tokens turned routine integration access into broad downstream compromise. In practice, PAT use often sits beside other token formats defined in modern identity guidance, including the OWASP Non-Human Identity Top 10, which stresses that issuance, storage, and revocation matter as much as the token itself.
Why It Matters in NHI Security
PATs become a governance problem when organisations lose track of where they are stored, who can use them, and whether they still map to an active business need. In 2025, GitGuardian reported that 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, showing how quickly reusable credentials can spread once they leave controlled systems. That exposure risk is amplified by the fact that many tokens are duplicated, forwarded in tickets, or left valid after a project ends.
Entro Security’s research adds an especially important warning: 91% of former employee tokens remain active after offboarding. For PATs, that means offboarding, vault hygiene, and automated revocation are not optional. The same pattern appears in broader secret-sprawl guidance such as the Guide to the Secret Sprawl Challenge and the Ultimate Guide to NHIs, both of which emphasise that credential exposure becomes a system issue, not a one-off mistake.
Organisations typically encounter PAT risk only after a token leak, unexpected API activity, or failed offboarding review, at which point the token has already become operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | PATs are reusable NHI secrets that fall under secret management and lifecycle control. |
| NIST CSF 2.0 | PR.AC-1 | PATs implement authenticated access and must be governed as part of identity assurance. |
| NIST SP 800-63 | AAL2 | PAT usage inherits the assurance of the owning identity and should reflect strong authenticator policy. |
Match PAT issuance and reuse limits to the assurance level of the parent identity.
Related resources from NHI Mgmt Group
- How should teams respond when a GitHub personal access token is exposed in an AI chat history?
- Should organisations prioritise token controls before expanding SaaS access?
- What is the difference between access token abuse and refresh token abuse?
- What is the difference between OAuth and token exchange for AI agent access?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on May 30, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
