A coding agent needs to create issues and push commits in three specific repositories, but should have no access to any other repositories in the organization. What is the most secure authentication configuration for this agent?
Select an answer to reveal the explanation.
Short Explanation
A GitHub App is a VIP pass scoped to specific rooms, not a master key. You install it on exactly the three repositories you want to give it access to — it is physically incapable of touching any other repository in the organization, no matter what.
Full Explanation
GitHub Apps are the recommended authentication mechanism for agents that need scoped, multi-repository access. Unlike personal access tokens, which grant access to all repositories the creating user can access, GitHub Apps have two levels of permission scoping: the App definition specifies which permission types and levels are needed, such as issues:write and contents:write, and the App installation specifies exactly which repositories the App can access. Installing the App on only three repositories means it literally cannot make API calls against any other repository in the organization, even if someone tried to use the token against them.
The organization-level personal access token with issues:write and contents:write scopes typically grants access to all repositories the creating user has access to, or can be scoped to specific repositories in fine-grained PATs. However, organization-level PATs tie access to the human user's account, creating a security dependency on that account's continued employment and access level.
The GITHUB_TOKEN provided by GitHub Actions automatically scopes to the current workflow repository. For a multi-repository scenario requiring access to three repositories, the default GITHUB_TOKEN is insufficient because it is scoped to one repository per workflow run. Cross-repository access requires additional configuration.
The machine user account in the organization with collaborator access on the three repositories is a legacy pattern. Machine users are full GitHub accounts that count against organizational seat limits, cannot be scoped below the repository level, meaning access is all-or-nothing per repository, and do not support fine-grained permission types.
GitHub Apps with installation scoping are the current best practice for multi-repository agent authentication.