What personal access token policy should apply to contractors?

Set your GitHub organization to require administrator approval for fine-grained personal access tokens, cap their lifetime, and restrict or block classic tokens unless you have a reason. A contractor can still script against your repositories, but only with tokens you have seen and that expire on a date.

Why tokens deserve their own policy

A contractor signs in with two-factor authentication, and then creates a token for a script, a local tool or an integration. That token authenticates without the second factor, may carry broad scopes, and lives wherever the contractor pasted it. Tokens are the easiest credential to forget at offboarding.

GitHub gives organization owners policy controls for exactly this, and they are separate for fine-grained tokens and classic tokens.

The controls GitHub documents

A few details from the documentation worth knowing:

• Only fine-grained tokens are subject to the approval step. Unless you restrict classic tokens, they can access organization resources without approval.
• Tokens created by organization owners do not need approval.
• Public resources stay readable without approval, whatever the policy.
• If you set a maximum lifetime, non-compliant tokens belonging to a member are blocked, but not revoked. People learn their token is non-compliant when API calls are rejected, so tell contractors the rule in advance.
• If your organization belongs to an enterprise, an enterprise level policy can override yours.

Recommended settings for contractor heavy teams

1. Require approval for fine-grained tokens. Keep the default. Each request tells you which repositories and permissions the contractor wants, and you can refuse an over broad ask.
2. Restrict classic tokens. Classic tokens are the broader credential. If a contractor has no need, block them from reaching your organization.
3. Set a short maximum lifetime. Choose a window that matches your engagement length, rather than accepting the long default.
4. Name an approver and a response time. An approval queue that nobody watches teaches contractors to share one token among five people.

Reviewing a token request

When a request arrives, ask:

• Which single repository does it need? Prefer one over many.
• Which permissions? Read only if the job is reading.
• How long? Match the end of the task.
• Where will it be stored? A CI secret store, not a chat message.

At offboarding

Ending a contractor's access to your organization ends what their tokens can reach in it, since a token cannot exceed the account's access. Still, list approved tokens and revoke them as part of exit, because a token approved for a service account or for a shared machine user may be tied to an account that stays. Combine this with the deploy key sweep and the offboarding checklist.

Where tokens are the wrong tool

For build systems, a GitHub App or short lived credentials issued by your pipeline are better than a person's token, since they are not tied to one human. For hosted workflows, GitHub recommends keeping the default GITHUB_TOKEN permission at read only for contents and raising it per job.

Safeguard's compliance and evidence automation can record that your token policy is in place and when it was last checked, and asset discovery helps surface integrations you did not know existed. Try the free scan.

Quick check

Sources

• Setting a personal access token policy for your organization
• Secure use reference for GitHub Actions

Last reviewed: 19 October 2026.