An enterprise security team needs a CI/CD agent running in GitHub Actions to push artifacts to GitHub Packages and open pull requests. The security team requires that: all agent actions appear in audit logs attributed to the agent rather than a human user, no long-lived credentials are stored in repository secrets, and permissions are explicitly declared and reviewable. Which authentication mechanism best satisfies all three requirements?
Select an answer to reveal the explanation.
Short Explanation and Infographic
A GitHub App is like giving your agent its own employee badge with a photo ID — every door it opens gets logged under that badge, not borrowed from a human employee. Option C is correct: GitHub App installation tokens are short-lived (auto-expire in 1 hour), appear in the audit log under app/[app-name], and require explicit permission declarations in the App manifest that org admins can audit and revoke. This hits all three requirements simultaneously — no other option does.
Full explanation below image
Full Explanation
GitHub Apps represent the gold standard for machine-to-machine authentication in the GitHub ecosystem. When a GitHub App authenticates using its private key to obtain an installation token, that token: expires automatically after one hour (no long-lived credentials), is scoped to only the repositories in the specific installation (least privilege), and records every API action in GitHub audit logs attributed to the App identity rather than any human user. The App manifest declares required permissions upfront, making it auditable and approvable by organization admins before installation.
Option C is correct because it satisfies all three enterprise requirements: auditability (audit logs show app/[app-name] as actor), no long-lived credentials (installation tokens expire hourly and the private key never leaves the secret store), and explicit reviewable permissions (declared in the App manifest).
Option A fails the no-long-lived-credentials requirement. A PAT stored as a repository secret is a long-lived credential — it does not expire unless manually rotated. If the secret is accidentally logged or exposed through a misconfigured workflow, the credential remains valid until manually revoked. Also, audit logs show the service account user identity, which can be confused with a real human account.
Option B fails multiple requirements. Deploy Keys are SSH keys for git operations only — they cannot be used for GitHub REST API calls to push to GitHub Packages (which uses HTTP) or open pull requests. They also do not appear in audit logs in a useful way and require manual rotation.
Option D is close but falls short on the persistent identity requirement. GITHUB_TOKEN is scoped to the current workflow run and cannot be reused across runs, but it is attributed to github-actions[bot] — a generic actor — rather than a uniquely identifiable App. It also cannot easily push to GitHub Packages in cross-repository scenarios or open PRs in repositories outside the current workflow context.