[schpet]

i was more thinking like, if i am working on project ABC for org XYZ it's understandable that if my dev vm gets owned that ABC is leaked. it's not that acceptable if all of org XYZ's repos that i have access to get leaked. and especially not acceptable if everything i have access to, including other orgs, and the admin ability to do destructive operations on them, gets exposed. but status quo is that that's absolutely the case, and you basically need org specific github accounts to reduce the risk of that. or use the knee-capped fine grained PATs that github offers but don't work for common things like seeing if your PR is green.

agree generally with what your getting at though: doesn't solve this problem. but even just a basic reduction in blast radius would be nice.

[alexfoo]

I completely agree, but I don't think many developers will enjoy the new hoops that will need to be jumped through in order to do various things more securely.

Having to switch between accounts with different tokens with vastly pared down access is going to feel quite restrictive and suffocating.

Some devs won't have the patience to wait for some other department to vet and import a new npm package, or the latest update to it, before it can be used.

Some devs will be frustrated not being able to run their favourite IDE which isn't on the approved list, or their favourite plugins which haven't been vetted yet.

Some devs will get annoyed that they have to reboot more and more frequently to get the latest OS updates because things like Copy-Fail/CVE-2026-31431 appear out of nowhere and can be weaponised by malware to break between accounts or out of VMs and other sandboxed envs to get access to more keys/PATs/etc.

Another alternative is endless MFA requests which leads to request fatigue and accidentally approving the malicious/unwanted action.

It's going to be interesting how the industry deals with all of this. I can see it getting a lot worse with some even more significant breaches before it starts to get better.