Feature Request

Description

The current suggested method to bypass protected branches is the following:

The GITHUB_TOKEN secret is automatically configured by GitHub, with the same permissions role as the user who triggered the workflow run. This causes a problem if your default branch is protected to specific users.

You can work around this by storing an administrator's Personal Access Token as a separate secret and using that instead of GITHUB_TOKEN. In this case, you will also need to pass the new token to actions/checkout (as the token input) in order to gain push access.

Not everyone would like to use PATs (see reasoning below). After researching this topic intensely lately I stumbled across the following solution:https://github.com/sbellone/release-workflow-example. This repository showcases how one can bypass the branch protection on GitHub via deployment keys.

Use cases

Why PATs are problematic for automation:

1. User dependency and automation fragility: PATs are bound to individual user accounts. When a user leaves the organization, changes teams, or has their account disabled, all automations relying on their PAT immediately break. This creates a critical single point of failure where the "function of systems" becomes dependent on individual employment status.
2. Security breach exposure: PATs grant access to ALL private repositories that the user account can access, not just the specific repository needed for automation. If a PAT is compromised or leaked, the attack surface is significantly broader than necessary. According to Checkmarx research, compromised PATs have been used in large-scale automated attacks on GitHub accounts.
3. Token rotation and lifecycle management complexity: While PATs can have expiration dates, managing rotation at scale becomes tedious and error-prone. Classic PATs historically didn't require expiration, meaning compromised tokens could be misused indefinitely if undetected. Organizations using PATs in CI/CD pipelines face constant maintenance burden to rotate tokens before expiration.
4. Auditing and accountability challenges: Actions performed using PATs can be harder to trace, especially when multiple people or systems share the same token. If several team members have access to a shared PAT secret, determining who actually performed an action becomes difficult.
5. Requires privileged account creation: To use PATs for branch protection bypass, organizations often need to create "bot" or "service" user accounts with elevated permissions, then manage MFA for these accounts.
6. Broad permission scope: Even with fine-grained PATs, the permissions model still grants wider access than necessary for simple deployment workflows. PATs fundamentally operate at the user-account level rather than the repository level.

Why deploy keys are superior:

1. Repository-scoped access: Deploy keys grant access to a SINGLE repository only. The SSH key is attached directly to the repository rather than a user account. This implements the principle of least privilege - if a deploy key is compromised, the blast radius is limited to one repository.
2. No user dependency: Deploy keys are not linked to individual user accounts or organization membership. If the user who created the deploy key leaves the organization, the key remains functional because it's tied to the repository, not the person. This eliminates automation failure due to personnel changes.
3. Simpler rotation with rulesets: With GitHub's ruleset feature (not legacy branch protection), deploy keys can be added to the bypass list directly. The rotation process involves generating a new SSH key pair and updating the secret - no user account management required[web:sbellone].
4. No expiration management overhead: Deploy keys don't have built-in expiration dates, eliminating the constant rotation burden. While this could be seen as a security concern, it's offset by the limited scope (single repository only) and the fact that organizations can implement their own rotation policies as needed.
5. Clear security boundaries: Since deploy keys are repository-specific, security posture is more transparent. Each repository explicitly declares which keys have access, making audit and review straightforward.
6. Read-only by default: Deploy keys are read-only by default and require explicit configuration to grant write access. This fail-safe design prevents accidental write permissions.

Possible implementation

This workflow would allow us to bypass the protected branch as follows:

steps:  -name:Checkout codeuses:actions/checkout@v4with:ssh-key:${{ secrets.DEPLOY_KEY }}

Alternative solutions

Continue using PATs