A previously proposed idea asked for this, and it was marked as completed with the introduction of Restricted Contexts. However, contexts are just a workaround, and they are not a good workaround for the following reasons / use cases: This relies on usage of contexts. If the downstream jobs from the approval don't use any secrets, I'd still have to set a context on those jobs purely for permissions separation. This is a hack and adds confusion. For auditing purposes, it doesn't make sense that a developer should be able to approve the workflow if they are not allowed to deploy. The list of people allowed to deploy are not necessarily on the same team, nor are the entirety of their teams allowed to deploy. If I have Bob and Brad who are part of the Ops and SRE teams, but I don't want everyone on Ops or everyone on SRE to be able to deploy, I'd have to essentially create an entirely new team with Bob and Brad just to restrict who can deploy. This information I believe belongs in CircleCI, not in Github. Github is not doing the deployment. And in this specific use case, it's a far better experience to be able to explicitly say who is allowed to approve. CCI-I-1183
