Promoting use of fine-grained PATs
11 April 2026
Software development is becoming an increasingly risky business. Supply chain attacks are more frequent than ever, and those of us using agentic LLMs run the risk that it will add a dependency automatically that contains malware. We're perfectly capable of doing that without LLMs of course (see typosquatting) but it's riskier when an LLM can add the dependency, download it, and run it, all before you get a chance to realise what it's doing.
As a result many of us are making an effort to isolate our development environments. This means both isolation between projects and isolation from our "main computer" that we're using to do the work, which probably contains most of our personal data.
If you run your development in a container or remote SSH server there are two things to worry about if malware takes over: the code itself if your repo is private or proprietary, and the SSH key or token that you're using to communicate with the git remote. The most popular choice is an SSH key, which can be stored with varying levels of security. In practice, in many situations malware will be able to make use of that key, either by exfiltrating an unencrypted key or by using the SSH agent.
The trouble with a service like GitHub is that your SSH keys are user-scoped. If someone gets your key then they have access to all of your repos, along with all of those shared with you by other users and organisations. If you're trying to isolate your environment it's kind of upsetting if the GitHub authentication in that environment grants a wider scope of permissions than it needs to.
GitHub does have three features for narrower permissions, but they all have their own issues.
Codespaces are convenient for some projects but they're costly and the organisation that owns the repo has to pay for them. SSH Deploy Keys are a repo-level mechanism not designed for regular development workflows. Some people use it for this purpose but it's going against the grain.
Fine-grained PATs are great because you can set exactly which repos and capabilities are permitted for that token, but there is a wrinkle. If you're working on another organisation's repo then by default you can't create a PAT on your own—you have to submit a request that an org admin needs to review and approve. The good news is that there's an option to turn that off, which means that developers are free to create tokens with the narrowest required permissions for each situation.
If you're a developer, consider asking for the ability to use PATs freely. If you're an organisation, consider changing the setting from the default so that contributors are able to use PATs proactively and independently.
I think it would be neat if GitHub allowed you to restrict specific SSH keys to particular organisations or repos. For personal use, honestly my favourite thing is to use Codespaces. It feels a little bit silly not using the computational power of my laptop but it automatically creates repo-scoped tokens so it's a pretty excellent level of isolation with very little effort.
Serious Computer Business Blog by Thomas Karpiniec
Posts RSS, Atom