GitHub Agentic Workflows without PATs: how to move repo automation onto GITHUB_TOKEN without breaking the workflow

Start with the inherited workflow

Picture a familiar scenario. A DevEx, platform, or backend engineer inherits a GitHub Agentic Workflow that:

• updates files in the same repository;
• opens pull requests;
• sometimes leaves comments or triggers follow-up automation;
• and uses a PAT secret for all of it.

The immediate issue is not that the workflow is broken. The issue is that the team now has to keep track of token ownership, rotation, and accidental overprivilege. In many cases the PAT also grants more access than a single repo job really needs.

What changed

GitHub moved the default trust anchor from a personal token to the workflow’s built-in identity. For the reader, that means something simple and useful: if the automation stays inside one repository, it can often be tied to GITHUB_TOKEN and narrowed with permissions.

A minimal starting point looks like this:

permissions:
  contents: write
  pull-requests: write

This is not a magic snippet. It is a reminder to start from the smallest permission set that still lets the job do its work. If the workflow does not need issues, releases, or other write scopes, do not grant them just because they are available.

A safe migration path

The cleanest cutover is gradual, not dramatic.

1. Inventory every place where the workflow reads or depends on the PAT.
2. Write down the exact actions the job performs: create a PR, push a branch, comment, inspect state, or update files.
3. Narrow permissions to the minimum that covers those actions.
4. Test the workflow in a controlled branch or repo state and verify the side effects, not just the green check mark.
5. Remove the PAT from secrets only after the new path proves it can do the full job.

In short, the migration should answer one question: can this workflow do everything it needs without a long-lived personal token?

Where GITHUB_TOKEN is usually enough

For many internal repo automation tasks, it is:

• updating files in the same repository;
• opening or updating pull requests;
• interacting with that repository within the granted permissions;
• replacing a personal secret with a repository-scoped workflow identity.

That makes GITHUB_TOKEN a strong fit when the automation never needs to leave the repository where it runs. In that setting, the built-in token is easier to explain, easier to govern, and easier to rotate away from accidental complexity.

Where the boundary still matters

It is important not to describe GITHUB_TOKEN as a universal replacement for every auth pattern. Some situations still need something else:

• access to another repository or an external system;
• an organizational policy that requires a different auth model;
• a job that needs broader context than repo-scoped permissions provide.

That is why the real win is not “we deleted a secret.” The real win is that the workflow now uses the narrowest access model that matches the job.

What to verify before removing the PAT

Before the cutover, check three things again:

• the workflow really stays within one repository;
• permissions are no wider than the job needs;
• the team understands how this workflow fits into organization policy and spending controls if automation or Copilot usage is billed to the org.

If any of those answers are still fuzzy, the migration is not finished yet.

Bottom line

If the workflow lives entirely inside one repository and the PAT exists mostly because that is how it was built, it is usually a strong candidate for GITHUB_TOKEN. The benefit is not only that one secret disappears. The bigger win is that repo automation becomes easier to reason about: fewer hidden permissions, less secret maintenance, and less chance that a stale token outlives the workflow that depends on it.