GitHub Dropped PAT Auth for Agents. Your Merge Gate Just Got More Important.

On June 11, GitHub announced that agentic workflows no longer need a personal access token. Agents can now authenticate with the built-in GITHUB_TOKEN that Actions already provides to every workflow run. No PAT creation, no secret rotation, no scoping headaches.

That's good news for security. It's also a shift in where the responsibility for code quality actually sits. When the credential barrier to opening a PR drops to zero, the merge gate becomes the only mandatory checkpoint between an agent's output and your main branch.

What actually changed

Until this change, any AI agent running inside GitHub Agentic Workflows needed a PAT to interact with the GitHub API on behalf of a user. That meant someone had to generate the token, store it as a secret, scope it correctly, and remember to rotate it. In practice, most teams created a broadly scoped PAT, stuck it in a repo secret, and forgot about it until something broke or leaked.

The GITHUB_TOKEN is different in three ways that matter:

• Short-lived. It's minted at the start of a workflow run and expires when the run finishes. There's no long-lived credential to leak.
• Run-scoped. Permissions are defined in the workflow file itself. If you set contents: read, that's all the token can do, regardless of what the user who triggered the workflow could do.
• Not tied to a person. The token represents the workflow run, not an individual developer. That sidesteps the problem of agent actions showing up under someone's personal GitHub identity.

There's also a billing angle. When an agentic workflow uses the Actions token in an org-owned repo, AI credits get billed to the organization instead of the individual developer. Teams need to enable the "Allow use of Copilot CLI billed to the organization" policy and add copilot-requests: write to the permissions block in their workflow markdown file.

permissions:
  contents: write
  pull-requests: write
  copilot-requests: write

The friction was doing more work than you think

Before this change, setting up a PAT was annoying but it served as an implicit gate. Someone had to actively decide to give an agent credentials. That decision point forced at least a brief conversation about scope, permissions, and what the agent would actually do with write access.

Now that conversation doesn't happen by default. Any workflow that already has pull-requests: write in its permissions block can open PRs. No human needs to provision a token. No one needs to approve the agent's access. The agent just... ships.

That's fine if you have a solid review process. It's less fine if you don't. And this is where the merge gate becomes critical.

Count the checkpoints in your pipeline

Think about the path agent-generated code takes from idea to main branch. Before this change, there were at least two checkpoints:

1. Credential provisioning. A human creates and configures the PAT.
2. PR review. A human (or automated reviewer) evaluates the PR before merge.

Checkpoint one is now gone. If you don't have a required status check or branch protection rule enforcing a review on every PR, checkpoint two might be optional too. That leaves you with zero mandatory checkpoints between an agent writing code and that code landing in production.

Zero is not a number you want here.

GitHub's own controls aren't enough

GitHub has built real security controls into agentic workflows: agents run with read-only permissions by default, a threat-detection job scans proposed changes, and the Agent Workflow Firewall restricts outbound traffic to allowlisted domains. These are good controls. They protect against prompt injection and exfiltration.

But they don't review code quality. They don't check whether a function handles edge cases, whether a migration is backwards-compatible, or whether the agent introduced a subtle logic bug that passes all existing tests. That's the job of a code review gate, and GitHub's built-in protections don't fill that role.

Where a review gate fits

A required status check is the cleanest way to enforce review on agent-generated PRs. It's a branch protection rule that blocks merge until a specific check passes. If that check is an AI code reviewer, every PR gets a semantic review before it can land, regardless of who or what opened it.

This is exactly where Tenki's Code Reviewer sits. It runs as a required status check on every PR, reviewing the diff for bugs, logic errors, and security issues. In independent benchmarks, Tenki caught 84 out of 122 seeded bugs (68.9% recall), compared to 28.7% for CodeRabbit and 24.6% for Copilot's built-in reviewer. At $1.00 per review, it's cheap enough to run on every PR without worrying about the cost of agent-generated volume.

The important thing is that this works the same for agent PRs and human PRs. The merge gate doesn't care who opened the PR. It cares whether the code is ready.

Setting it up

If you're running agentic workflows with the new GITHUB_TOKEN auth, here's the minimum setup to ensure every agent PR still gets reviewed:

1. Add a code review check to your CI. Install Tenki (or whichever reviewer you use) as a GitHub App on your repo. It will automatically post a status check on every PR.
2. Make it required. Go to Settings > Branches > Branch protection rules for your main branch. Under "Require status checks to pass before merging," add the review check name. This blocks any PR from merging until the reviewer has passed.
3. Lock down bypass. If you're on GitHub Enterprise, use rulesets instead of branch protection rules. Rulesets can apply to admins too, which prevents anyone from bypassing the check.
4. Upgrade your agentic workflow CLI. Run gh extension upgrade aw to get the latest version with GITHUB_TOKEN support.

If you also want org-level billing for the AI credits your agentic workflows consume, enable the Copilot CLI billing policy and add copilot-requests: write to the permissions section of your workflow file.

The real question isn't whether agents can open PRs

They can. They could before, and now it's easier. The question is what happens between the PR being opened and the code reaching main.

GitHub removed the credential friction because it was a security liability, and that was the right call. But every friction point you remove from one end of the pipeline needs to be compensated somewhere else. If you're not enforcing a review gate on merge, you're trusting that every agent-generated diff is correct, secure, and ready for production. That's a bet, not a process.

Add the check. Make it required. Then let the agents ship.