Limit Personal Access Tokens
Replace broad long-lived personal access tokens with scoped, owned credentials and verify each retired token stops working.
Personal access tokens are easy to create and easy to forget. They often keep working after a project ends or a script moves to CI. Inventory them by owner and purpose, then replace broad, long-lived tokens with the narrowest provider-supported credential. OWASP's secrets and authorization guidance supports least privilege and lifecycle review.
Use provider-side token listings where possible. Record a safe token ID, owner, scope, creation time, expiry, and last use. Do not collect the token value. A token with no owner or purpose is a hold for investigation, not a reason to copy it into a new central file.
PAT review sheet
| Field | Decision |
|---|---|
| Owner | Person or workload responsible |
| Purpose | Exact task that still needs the token |
| Scope | Provider actions and resource limits |
| Storage | Approved secret store, not a script or chat |
| Expiry | Provider setting and renewal owner |
| Replacement | App, service account, or workload identity |
| Retirement proof | Provider revoked status or denied safe request |
Separate personal and machine use. A bot should not rely on an employee's PAT if a service identity is available. If the provider supports only a personal token for a needed integration, document the limitation and define a named owner, short expiry, and rotation plan.
Cutover test
Choose one owned integration. Issue a narrower replacement token and run its normal synthetic task. Attempt an unrelated action and require denial. Switch the integration, observe its scheduled runs, then revoke the old PAT at the provider. Verify the old token is no longer accepted through a safe method. Keep the service's health and old-token rejection as separate checks.
Review whether a PAT was copied into CI logs, local files, or backups. Removing it from a script does not end its authority. Record provider status, workload version, and owner signoff without storing secrets. Repeat the inventory periodically and after an offboarding event. A lower token count is not the goal by itself; each remaining token needs a justified, bounded use.
Make offboarding verifiable
Use the offboarding checklist to identify owners, revoke grants and verify the result. Discuss a scoped review of your application's access controls.
Sources
- OWASP Secrets Management Cheat SheetAccessed
- OWASP Authorization Cheat SheetAccessed