It feels to me like AI agents should be their own security principals and use access tokens generated speficically for them on the repos or orgs that they need access to. Handing an AI agent an access token "minted" for a human's account feels to me like the new "write the password on a post-it".

This is what I'm advocating for.

Give each dev's AI agent its own identity with its own access controls and tokens and everything.

It helps solve both the access control and attribution issues

Not just AI agents... basically, if you cd Projects/foo, that should be it's own user (for running npm, etc) that should not have access to parent user data (probably including github tokens, etc).

Why not both?

> basically, if you cd Projects/foo, that should be it's own user

Agreed. I went further and turned that into its own isolated virtual machine. The credentials problem is really annoying though. AI agents need the access in order to be useful.

As long as there’s a way to deterministically tie a model call to a human user. I think a loss of culpability is something some companies are afraid of to some extent.

Loss of liability is what company are built for, see the meaning of LLC as an exemple.

Of course, it is only their employees that are impacted instead of their bottom line, they might be more tolerant?

You are correct but the issue is permission management with finegrained tokens is nighmare. It is not easy to decide what is correct and what is needed for some operation. Furthermore, often software devs think it is important to focus on code rather than permissions - as it is for someone else's responsibility....

Sometimes the basic things missing in the programming world just shock me. How is anyone supposed to know what permissions to give in these systems that have literally hundreds of fine-grained permissions, many of which can also have scope? Even if they're "documented" we all know from experience that some textual descriptions of a permissions won't capture when it is actually used in the code.

Why isn't it standard to have a security log that shows what permissions were requested, with what scope, so we can at least create a minimal set of permissions by trying an operation, seeing what permissions are necessary, and then setting just the needed permissions? If you're worried about that log itself becoming a compromise, make it something that is off by default, and maybe automatically turns off after some period of time, or make me use a burner token for this operation, or something, but the alternative is the world of excessively-broad permissions that we live in now. Why isn't there a helper mode that a dev can use to point at an interaction and say "now give me minimal permissions for those interactions", not only to configure a given key but so we can learn what permissions actually mean in practice?

We're given these super complicated knobs, but all we get for using them is a few textual blurbs about the settings and the blame if we don't configure them exactly correctly, and also the blame if something breaks because we were too tight with the permissions.

This seems such a basic tool to use these super complicated systems yet I've never seen them anywhere on the web.

Perhaps ironically, perhaps just because it was already complicated enough and needed a way to approach usable, the notoriously difficult to use SELinux uses this as the more-or-less standard way of setting permissions. I can't believe I'm missing SELinux.

I use classic tokens on low-privileged accounts for scraping public repos. I suppose organization level permissions would work fine for me.

If classic PATs were to blame, doesn't this mean further private repos could be at risk as well? (apart from the GitHub ones the other day).