3 ms·
> temporary per-repo permission scope or token that allowed only pull and push to the repo in question How about pull from the repo but only push to a staging
by amluto 4mo ago
> temporary per-repo permission scope or token that allowed only pull and push to the repo in question
How about pull from the repo but only push to a staging area from which the user, but not the token, can push for real?
Frankly, LLM agents should do this too. Letting your LLM push seems foolhardy to me.
- moi2388 4mo agoThat makes so much more sense.
- alostpuppy 4mo agoExe.dev has an integrations feature which is similar allowing you to grant access to specific repos without having give the VMs credentials. I think it’s a similar pattern to iron.sh. I have been thinking more and more about how I might use this pattern.
- namibj 4mo agoJules is heavily restricted in what it can do to your repos.
- lifis 4mo agoYou can just fork the repository, give it access to the fork and then merge what you want
- deleted 4mo ago[deleted]
- amluto 4mo agoThis is a piece of cake using GitHub’s excellent permission system. (I’m joking, of course. Service accounts are nowhere to be seen. OAuth can’t even scope to an organization, let alone a repository. And this whole github.dev thing illustrates that you don’t even need to explicitly grant permission to issue broadly scoped tokens.) Also, forking is pretty heavyweight just to launch something that, for all anyone knows before starting actual work, is being used as a read only viewer.
- ndegwaduncan 4mo agothe scope problem is actually worse with agents than with github.dev. the architectural answer is the same though: the credential the agent operates with should be scoped to the task and expire when the task ends.