GitHub introduced agent automation controls for GitHub Issues in public preview on July 23, 2026. The feature addresses a practical workflow problem: when an agent labels, types, assigns, or closes an issue, how should a team understand the action and decide which changes can happen immediately versus which should wait for review?
The update has three control points. Approvals let an automation suggest a change instead of applying it; suggestions remain in a panel on the issue and can be accepted or declined individually or in bulk. Confidence gives supported actions a high, medium, or low level. High-confidence changes can apply automatically, while medium- and low-confidence changes remain suggestions. Rationale records a reason for every action, whether it has already applied or is waiting for approval, creating an audit trail.
GitHub also adds the `has:suggestions` search filter so teams can find pending decisions. Repository administrators can configure the automation level and adjust the confidence threshold. The model is closer to workflow governance than an on/off switch: it asks what an agent may do at each risk or confidence level.
The controls work with GitHub Agentic Workflows and Copilot cloud agent automations, and are also exposed through the REST and GraphQL APIs. The initial action set covers labels, fields, issue type, closing issues, and assignees. In GitHub Agentic Workflows, teams can use `issue-intents: true` in workflow frontmatter to require issue intent, or `issue-intents: false` to opt out explicitly. Supported safe outputs include setting issue type or fields, adding labels, closing issues, and assigning to an agent or user.
Potential uses include automated triage, filling missing issue metadata, and spam detection. These are good candidates for applying low-risk, high-confidence changes while routing uncertain cases to a review queue. GitHub also makes an important distinction: approvals are a workflow convenience, not a security control. An agent with permission to change issues can still apply changes directly, so approvals do not replace least privilege, API scopes, organization policies, or audit systems.
Rationale should not be confused with a complete reconstruction of a model’s internal reasoning. It is better treated as governance metadata: a readable explanation of the action, confidence, and state. Teams still need to retain the original input, tool calls, before-and-after values, actor identity, and error handling if they need to reconstruct an event later.
Agent automation maturity is not measured only by whether an agent can modify an issue. It is measured by whether the system can stop at the right risk threshold, ask a person to decide, and leave evidence that can be checked. GitHub’s preview puts confidence, rationale, and approval on the same operating surface, offering a testable governance pattern for connecting agents to more sensitive development workflows.
