GitHub Agentic Workflows drop personal access tokens for the built-in Actions token

A personal access token, sitting in a CI secret store, tied to a human account, granting org-wide write, and now plugged into an LLM that will gladly call any API you point it at. (What could possibly go wrong?) That has been the default shape of "agentic workflows" since the category got a name, and on June 11 GitHub took the obvious next step: agentic workflows on GitHub Actions can now authenticate with the same ephemeral GITHUB_TOKEN every other workflow uses, with no PAT required.

The change is small in surface area and larger than it looks in security terms. Long-lived PATs minted by an individual were the most popular way to give an agentic workflow write access, to push branches, open PRs, comment on issues, call the Copilot API. They were also the most common way for an engineer's offboarding to silently break a pipeline, and for a phished token to grant an attacker the full radius of whatever scopes the human checked at midnight. Neither problem is new. Both got materially smaller this week.

Why does a long-lived PAT in your pipeline keep getting flagged?

Because it violates almost every property you would want from a CI credential. It does not expire. It is not bound to a job. It does not carry the workflow's identity. It belongs to a person who may leave the company, lose a laptop, or click the wrong PDF. And in an agentic context, where the workflow's logic is partly decided by a language model reading your repo, the blast radius of a leaked PAT is whatever scopes the human happened to tick.

Compare that to the ambient alternative. GITHUB_TOKEN is minted at the start of a job, scoped by the permissions: block in the workflow file, and discarded when the job ends. It is not transferable, it is bound to the workflow identity, and if it leaks, the window of exploitation is measured in minutes, not whatever the PAT's expiration was set to when somebody was in a hurry.

For agentic runs the shift matters more, not less. An agentic workflow is, by construction, a process that reads inputs you do not fully control (issue text, PR diffs, prompt content) and decides what API calls to make. Pair that with contents: write on a permanent token and you have built a remote-code-execution-as-a-feature pipeline. Pair it with a 10-minute scoped token whose permissions are declared in the workflow file, and the worst case shrinks accordingly.

How do popular CI platforms handle credentials for automated workflows?

Most of the major platforms moved past static, human-owned tokens a while ago, agentic flows just made the gap obvious.

• GitHub Actions already had the foundation: GITHUB_TOKEN for repo-scoped writes and OIDC federation for cloud providers. The new piece is letting agentic workflows in particular use that token, with AI usage billed to the org rather than a personal account.
• GitLab CI/CD ships CI_JOB_TOKEN for short-lived job-scoped calls to the GitLab API, and ID tokens (signed JWTs) for OIDC federation. For agent runs that need to call GitLab itself, CI_JOB_TOKEN is the right primitive, and arguably the better fit if your repo already lives there, because the token model has been hardened across more releases than GitHub's agentic surface has even existed.
• Jenkins is the awkward one. The Credentials plugin still leans on long-lived tokens unless you wire in HashiCorp Vault or a similar broker. The genuine upside: Vault integration on Jenkins is mature, and if you have already invested in dynamic secret leasing, you get cradle-to-grave credential lifecycle that the SaaS platforms only approximate. A competitor is the better fit here if "every secret is short-lived and brokered" is your hill.
• CircleCI uses OIDC tokens and contexts to scope secrets per project and per environment, and has been pushing OIDC for cloud auth since 2022.
• Argo Workflows / Argo CD sidestep the question slightly: they expect workload identity (Kubernetes service accounts, IRSA, Workload Identity Federation) for outbound calls, so the "credential" question becomes a cluster RBAC question. Different problem, different blast radius.
• Buddy is one option worth naming here for a specific reason: its pipeline secrets are scoped to the pipeline and only mounted into actions that explicitly declare them, which gives you a PAT-free path for agentic steps without having to stand up your own OIDC broker. Useful when your team is small enough that "set up Vault" is the wrong answer to "how do I rotate a token next quarter".

The honest read across all six: GitHub closed a specific hole, but most of the field has been heading this way for a while. If you are still pasting a PAT into a CI variable in 2026, the problem is process, not platform.

What does the new flow actually look like?

On GitHub the change is mostly a frontmatter swap. An agentic workflow that previously consumed a PAT now declares the permissions it needs and lets the runner mint the token:

# .github/workflows/agentic-review.yml
name: Agentic PR review
on:
  pull_request:
    types: [opened, synchronize]

permissions:
  contents: read
  pull-requests: write
  issues: write
  copilot-requests: write   # bills the org, not a user

jobs:
  review:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: github/agentic-workflows/run@v1
        with:
          workflow: .github/agents/review.md
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

No PAT. No personal scope. The permissions: block is the contract, narrow it for each agent and it is the only thing that can leak.

If you are running agentic steps from Buddy alongside or instead of Actions, the equivalent looks like this, note the secret is declared once on the pipeline and never checked into the repo:

# buddy.yml
- pipeline: "Agentic review"
  on: "EVENT"
  events:
    - type: "PULL_REQUEST"
      branches: ["main"]
  variables:
    - key: "GH_API_TOKEN"
      value: "secure!"
      encrypted: true
      settable: false
  actions:
    - action: "Run agent"
      type: "BUILD"
      docker_image_name: "node"
      docker_image_tag: "20"
      execute_commands:
        - "npx @your-org/agent-cli review --token $GH_API_TOKEN"

Two pipelines, one workflow file each, zero PATs sitting in someone's ~/.npmrc. See the Buddy pipeline secrets docs for the encryption model and scope rules.

Where does the trust boundary still leak?

Right where it always did: in what the workflow is allowed to do, not in how it authenticates. GITHUB_TOKEN with contents: write is still a token that can push to your default branch. An agent that decides, because a prompt-injected issue body told it to, that the right next step is to commit a malicious npm postinstall hook will do exactly that, ephemeral token or not. The permissions: block is the audit you should actually be doing this quarter. Read every line. Drop the ones you cannot justify.

There is also a billing wrinkle worth flagging. Switching to the Actions token means AI credits get billed to the organization rather than a user, and user-level inference budgets stop applying. That is operationally cleaner, engineers leaving will not strand workflows that were silently spending their personal budget, but it does push spend governance onto org-level cost centers and per-workflow caps. Get those configured before you flip the switch, not after.

The PAT was never the deepest hole. It was just the one with a name. The deeper hole, an LLM with write scopes reading attacker-controlled input, is the one we still have to live with. This week it just got a thinner skin.