Limiting scope of a PAT to a single repository

I’m currently using TravisCI in our team to build private NPM packages and publish them to Github packages. I have created a bot account, added it to our team and using its PAT in Travis. Now let’s say John has access to repository A but doesn’t have access to repository B. Problem is because of the bot account PAT having access to both repositories, John can edit “.travis.yml” file in repository A and therefore gaining access to repository B. My first thought was to create a bot account per repository, Unfortunately that is not going to work because I need to pay $9 for each of them.

Is there any way to limit the scope of a PAT to a specific repository? or something that will fix this?

Thank you!

1 Like

@mo-harris wrote:

Is there any way to limit the scope of a PAT to a specific repository? or something that will fix this?

Thank you!

There’s not a way to limit the scope of a personal access token to a specific repository. We understand that you don’t want to grant applications permissions they don’t need, and these applications probably don’t even want to ask you for these permissions. In some cases, this might even prevent you from using an application.

It’s a very important topic and we’re glad you’re bringing it up with us. Providing more granular OAuth scopes is already the biggest blip on the API team’s radar and it’s something we’d love to do. However, we can’t make promises about if and when the scopes you wished for might be available – the API team is rolling out additional scopes as they are completed.

The best way to keep track of changes is to follow the API blog, and ping us if you have any questions about the available scopes:

Improving this situation about scopes is something the team has been working on. You might want to check out the GitHub Apps features:

GitHub Apps allow per-repository access and more finely-grained scopes. One appropach you could take is creating a GitHub App whose sole responsibility is to manage a single file in any of the repositories its installed to:

From there, you could install that GitHub App to the relevant repositories. Creating and using a GitHub App wouldn’t require you to buy another seat. In fact, you can create as many GitHub Apps as you need to perform these sort of programmatic and administrative operations that would have normally been delegated to another person on your team. We hope this helps!


Thanks for the solution.

We ended up using GitHub App installation tokens with limited access to specific repositories.

From what I learnt from my testings, GitHub Packages don’t work with GitHub App installation tokens. Is that right or I’m missing something?

1 Like

I can’t understand why it doesn’t have a feature yet.

I think it should add the per-repository limit feature as soon as possible.

Permissions are more intertwined than you might think.

Currently, It need to create an account on github to configure the above features.

  • This called machine user in github.

If I use Enterprise, I have to pay extra. Most importantly, changing the keys is inconvenient and this has a negative impact on security.

Also, having to form a private access token on the CI server or development server is terrible.

1 Like

@mo-harris - My apologies for not catching your question the first time around! :scream:

Our Authentication in a workflow’s section, Permissions for the GITHUB_TOKEN outlines each of the API endpoints a GitHub App can access. At this time of writing, packages are accessible by the GITHUB_TOKEN provided by GitHub Actions, where read/write access is granted on root repositories and read access is given on forked repositories.

:wave: @DingGGu , hey there, and welcome to our GitHub Support Community! I acknowledge where you’re coming from and think the best place to share that feedback is with our product team through this official feedback form. If you’re interested in learning what our team is working on next, we suggest checking out our GitHub Roadmap FAQs for the latest.

I see where you’re coming from. Granular permissions came top of mind for the team who initially developed GitHub Apps, and in my earlier reply, I mentioned the approach of using GitHub Apps as an alternative from machine users. If you’ve tried GitHub Apps already and found that feature doesn’t meet your specific need, I’d be curious to learn more about what specific advantages you’ve found a machine user to have.

That additional context would help me understand where you’re coming from and I can check on our end to see if there are other alternatives that might be of interest!

1 Like

Let me add some content to my question. One way to get authorize when pulling Docker images using GHCR is to use PAT.

Therefore, I need to register my Github PAT on the CI server or Kubernetes on Docker Credential.

I’m worried about this, and I’m looking for another way.

I think a great way to do this is to let Github create tokens that give you GHCR-per-container image-specific access.

In the current situation, I understand that even though the authority of Source and GHCR (which was added this time) are separated on Github, each team must have a different authority system, which creates N additional enterprise accounts and creates non-centralized tokens. It means you have to manage it individually.

Thanks for responding.


@DingGGu - Thanks for sharing that context with me. I’m going to look into this with one of my colleagues this week and see if there might be an alternative approach that could be useful. I’ll follow up by Friday with my findings (wherever I land).

1 Like

If I may add a different use case.
It would be super nice to be able to provide token access for
With tools like deno now supporting the execution of scripts via URL it would greatly simplify our deployment, and as a positive side effect, the load on github servers. Instead of having to do a pull each time we could just hit the CDN.