Because audit coverage can miss user-level API calls and may not show the reconnaissance steps an attacker uses first. If GET /user and GET /user/repos are invisible, you can lose the earliest warning signs. Logs are only useful when they capture the exact request classes that reveal identity and access scope.
Why Audit Logs Miss PAT Misuse
GitHub audit logs are valuable, but they are not designed to be a complete behavioural sensor for personal access token misuse. They often capture administrative events, policy changes, and some authentication activity, while missing the user-level API reconnaissance that reveals what a token can actually reach. That gap matters because a stolen PAT is not just a credential issue, it is an NHI visibility problem.
In practice, the attacker usually starts with low-noise calls, then maps repositories, org membership, and scopes before moving to code exfiltration or CI/CD abuse. If those early requests are not logged, defenders only see the later-stage impact. NHIMG research shows how often secret exposure persists in real environments, with 96% of organisations storing secrets outside secret managers in vulnerable locations, which makes post-compromise token abuse a common follow-on risk; see The State of Secrets Sprawl 2025 and Top 10 NHI Issues.
Current guidance suggests treating audit logs as one control layer, not the detection layer itself. For a baseline governance model, align the logging program with NIST Cybersecurity Framework 2.0, but do not assume it will expose every token-led action. In practice, many security teams discover PAT abuse only after repository access has already been enumerated and sensitive assets have already been touched.
How Detection Has to Work in Practice
Effective PAT misuse detection depends on pairing audit records with request-level visibility, identity context, and token lifecycle controls. The key question is not only “did a token authenticate?” but “what scope was exercised, from where, against which resources, and in what sequence?” That is why an NHI governance model must include issuance, rotation, offboarding, and revocation discipline alongside logging; the NHI Lifecycle Management Guide is useful for translating that lifecycle into operational controls.
Practitioners should look for patterns that audit trails alone do not make obvious:
- GET-style enumeration against user and repo endpoints before any write activity
- Token use from unfamiliar geographies, automation hosts, or proxy chains
- Scope escalation attempts, repeated 403s, or sudden access to dormant projects
- Unusual sequencing, such as metadata lookups followed by bulk clone or download activity
- Token reuse after the owning identity has changed password or left the organisation
For control design, use NIST Cybersecurity Framework 2.0 to anchor detection and response, then add policy around PAT expiry, JIT issuance where possible, and rapid revocation. NHIMG’s analysis of the Ultimate Guide to NHIs — Regulatory and Audit Perspectives makes the same point from an audit angle: evidence quality improves only when logs, ownership, and remediation are linked. These controls tend to break down when tokens are shared across CI jobs and personal workflows because attribution becomes ambiguous and revocation creates operational friction.
Where the Model Breaks Down and What to Do About It
Tighter logging and shorter token lifetimes often increase operational overhead, so teams have to balance visibility against developer friction and release velocity. That tradeoff becomes especially sharp in organisations that rely on long-lived PATs for automation, legacy integrations, or cross-repo workflows. Best practice is evolving here, and there is no universal standard for this yet, but the direction is clear: reduce standing token value and make misuse harder to sustain.
One common edge case is when PATs are used inside CI/CD systems that already blur human and machine activity. In those environments, simple “who used the token” questions are often insufficient because the real actor is a pipeline or service account. That is where NHI governance has to move beyond static audit review and into lifecycle enforcement, as discussed in NHIMG’s Shai Hulud npm malware campaign analysis and the Reviewdog GitHub Action supply chain attack case study.
For teams moving toward stronger identity assurance, the practical answer is to pair audit logs with workload identity, short-lived secrets, and zero standing privilege patterns. That direction aligns with the Ultimate Guide to NHIs — Key Challenges and Risks and with the current direction of NIST Cybersecurity Framework 2.0. The practical limit is simple: if logging cannot see token scope in motion, detection will remain partial.
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 and CSA MAESTRO address the attack and risk surface, while NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | PAT misuse is worsened by long-lived secrets and weak rotation. |
| NIST CSF 2.0 | DE.CM-1 | Continuous monitoring is needed when audit logs miss request-level activity. |
| CSA MAESTRO | Agentic and workload identities need runtime controls beyond static logs. |
Augment GitHub audit logs with request monitoring and alert on token misuse patterns.
