A personal access token inside automation ties a shared workflow to one person’s account and creates a long-lived secret to rotate. Copilot CLI can now run in GitHub Actions without that extra credential.

Quick answer

Use the workflow-provided identity, grant only required repository permissions, pin dependencies, and avoid running agent commands with write access on untrusted pull-request code. Removing the PAT reduces secret risk but does not make the workflow safe by itself.

permissions:
  contents: read
  pull-requests: write

jobs:
  copilot-task:
    runs-on: ubuntu-latest

what changed

Copilot CLI in GitHub Actions no longer requires a separately stored personal access token. Workflows can use GitHub’s supported authentication path, reducing setup and the lifecycle burden of a user-owned secret.

This is a current platform change, so confirm availability for your plan, organization, and installed client before changing a production workflow. Preview features can also change faster than generally available controls.

who should use it

This is useful for issue triage, pull-request assistance, and controlled maintenance jobs. The workflow token is temporary, but its effective permissions and trigger context still decide what an attacker could do.

The practical question is whether the feature removes a real bottleneck or security gap in your workflow. A new control is not valuable merely because it exists; it needs an owner, a narrow purpose, and an observable result.

a safe implementation

  1. Remove the PAT only after identifying its current permissions.
  2. Declare a minimal workflow permissions block.
  3. Separate read-only analysis from write operations.
  4. Protect write-capable jobs with trusted events or environments.

Make the first rollout small enough to reverse. Record the previous behavior, the setting or command that changed it, and the person responsible for deciding whether the experiment expands.

the mistake to avoid

Do not expose a write-capable agent to code from an untrusted fork through pull_request_target. Malicious repository content can influence commands even when no long-lived PAT exists.

Convenience features still operate inside your existing trust model. Repository permissions, protected environments, review rules, test accounts, and audit logs remain important even when the new workflow removes manual steps.

how to verify it

Run the workflow from an approved branch, inspect the authentication path, confirm the removed secret is unused, and test that the job cannot perform an operation outside its declared permissions.

Keep the verification evidence in the pull request or rollout ticket. That gives reviewers something concrete to evaluate and gives the next person a known baseline when the platform changes again.

rollout checklist

  • Confirm the feature and client version are available.
  • Test with non-production data and minimum permissions.
  • Capture expected success and failure behavior.
  • Document rollback and ownership.
  • Recheck the official announcement before a wide rollout.

official reference

The announcement is the source of truth for availability and product behavior. This article focuses on the implementation decisions teams should make around it.