What happened

GitHub shipped three new controls for agent automation inside GitHub Issues, in public preview as of July 23, 2026. These controls apply when an AI agent labels, types, assigns, or closes an issue on your behalf, whether that agent runs through GitHub Agentic Workflows (GitHub’s own scripting tool for automating agent actions), a Copilot cloud agent automation (an assistant that works in the background rather than inside your editor), or a custom script calling GitHub’s API directly.

The changelog post describes three pieces:

  • Approvals: instead of applying a change immediately, an automation can suggest it. The suggestion waits in a panel on the issue until someone accepts or declines it, either one at a time or in a batch.
  • Confidence: each supported action gets rated high, medium, or low confidence by the agent that proposed it. High-confidence changes apply automatically. Medium- and low-confidence changes wait for a person to review them.
  • Rationale: every action, automatic or suggested, records the reasoning behind it. That gives you an audit trail of what changed and why, instead of a label or assignment appearing with no explanation.

Search has:suggestions in your issue list to find every issue with a change waiting for review. Repository admins set the automation level, which controls the confidence threshold: how confident an action has to be before it applies on its own versus waiting in the queue.

Why it matters

The useful part of this feature is also the part that is easy to misread. GitHub’s own documentation states it plainly: “Approvals are a workflow convenience, not a security control. They don’t enforce a server-side boundary, and an agent with permission to change issues can directly apply changes rather than suggest them.”

In plain terms: turning on Approvals changes how a well-behaved automation presents its work to you. It does not change what an automation is technically allowed to do. If an agent, integration, or script already has permission to edit issues in your repository, nothing about the Approvals panel stops it from making that edit directly and skipping the suggestion queue entirely. The actual boundary is whatever permission scope you granted that agent or GitHub App when you installed or authorized it, not the review panel sitting on top of it.

This matters more the more issues a repository processes automatically. A small project might not notice a wrong label. A repository that auto-closes issues based on agent confidence, or auto-assigns them to the wrong person, can lose track of real bugs or route work to the wrong place with no one watching, especially since high-confidence actions apply without waiting for anyone.

Who should care

This applies to anyone using GitHub Issues to track work on a repository, whether you are running a solo project or a small team. It matters most if you already use, or are considering, an automation that touches issues: a GitHub Agentic Workflow, a Copilot cloud agent automation, or any third-party integration authorized against your repository’s issue permissions.

It matters less if your repository has no issue automation running today. But if you are about to turn one on for the first time, this is exactly the moment to read the permission scope you are granting, not just the confidence settings.

What builders should do next

Before trusting the confidence threshold to protect you, check what permission scope the automation actually holds. In your repository’s Settings, under Integrations, find the specific GitHub App (a third-party or vendor integration installed on your repository with its own permission scope) and check its installed permissions. Confirm whether it has write access to issues at all, and whether that access is broader than the specific actions you want it to take.

Then run a bounded test instead of trusting the feature by reputation. Turn on Approvals for one label-heavy repository, set the automation level to hold everything but high-confidence changes, and let it run for a week. At the end of the week, check three things: how many high-confidence changes applied automatically were actually correct, how many suggestions in the has:suggestions queue you had to decline, and whether the recorded rationale for each change matches what actually happened. If the automatically applied changes have a real error rate, tighten the automation level so more of its output waits for you, rather than assuming a “high confidence” label means “correct.”

End of article