The actual technical guts of this approach, the part most HN people care about, most cloud providers have been doing for over a year now: you take (say) an HTTP API call that's enabled by a fully-privileged bearer token, you hide the bearer to token from the client inside a proxy, and then you have clients use the proxy instead of the real service, which screens requests.
Then all you're adding here is the classical notion of a "capability", which is to say that you're explicitly and inseparably coupling naming and privileges. In a capability system there is no "github.com" with ambient privileges; there's only "github.com.capabilities.dev/this-set-of-privileges". To know the API endpoint is to know and be limited by the set of things you're allowed to do.
This idea is interesting and important but I think screened access to Github undersells it, or is a half-hearted implementation. In a capabilities system, those capability blobs are the only way to access services. In a K8s system where you're opting in to a specific set of "capabilities" but still have ambient permissions for lots of APIs, you're not really doing capabilities so much as a fancy token system.