An AI coding agent proposes broader permissions for your production deployment workflow. An AI reviewer approves the pull request. What should happen before that change reaches production?
For security and engineering leaders adopting coding agents, GitHub’s 28 October releases make this a practical configuration and governance decision. More of the path from proposed code to merge can now involve agents. Teams need to define which changes those agents may make, whose approval is required and what evidence explains the final decision.
GitHub provides substantial controls across that path. Secuarden’s authority-to-change thesis offers a way to evaluate how those controls fit an organisation’s requirements: connect the actor, the final change, the applicable policy and the decision that authorised it.
What GitHub’s releases provide
The following comparison reflects GitHub’s primary announcements published on 28 October 2026. The governance questions are our interpretation of how teams can evaluate their deployment.
| Capability | Documented behaviour | Question for your team |
|---|---|---|
| Copilot code review and approvals | When enabled, Copilot can approve a pull request and count towards required approvals. Approvals default to off, can be restricted by file path and are dismissed after new commits. | Which changes qualify for AI approval, and which require a designated independent approver? |
| Agentic Workflows | Agents perform tasks inside GitHub Actions, reusing runner groups and policy constraints, with layered execution and output safeguards. | What may each workflow access and change, and under which conditions? |
| Agent Merge | Copilot can repair selected pull-request blockers. With auto-merge, GitHub merges once all requirements are met. | How are repairs checked against the final revision and applicable approval requirements? |
Copilot: review and repository approval
GitHub’s Copilot announcement makes approvals generally available. Administrators can enable them at enterprise, organisation or repository level; repository administrators can restrict eligible file paths. Subsequent commits dismiss an existing Copilot approval.
The same announcement introduces Max review effort in public preview. It combines several review agents using models from different providers and reconciles their findings. Teams should distinguish this review-depth option from the separately configurable approval capability.
Agentic Workflows: governed automation inside Actions
Agentic Workflows automate tasks such as issue triage, CI analysis, documentation and test writing. Natural-language workflow definitions compile into Actions YAML.
GitHub documents read-only default permissions, integrity filtering, sandboxing, firewall controls, safe-output validation and threat detection before proposed changes are applied. These are meaningful governance controls. Teams should examine how their chosen permissions, outputs and workflow configuration implement their own change policy.
Agent Merge: repairing blockers on the path to merge
Agent Merge can watch a pull request and address selected failing Actions workflows, merge conflicts or both. It works in a cloud development environment and remains subject to applicable organisation and enterprise policies.
When combined with auto-merge, the pull request merges after its requirements are satisfied. This makes the treatment of subsequent repairs important: teams should verify which checks and approvals apply to the code that ultimately merges.
Review, approval and authority work together
A review assesses a change. A repository approval satisfies a configured approval requirement. Authority to change concerns whether the actor and proposed action are permitted under organisational policy.
These functions can be implemented together through platform controls and organisational processes. Their effectiveness depends on the rules a team establishes, the permissions it grants and the evidence it retains.
Secuarden’s thesis is that this relationship should be explicit and inspectable for AI-assisted changes. A team should be able to explain how a human request became agent activity, how that activity produced a change and why the resulting change was accepted. This is an architectural perspective; specific enforcement and evidence capabilities depend on the products and configurations in use.
Follow one sensitive change
Return to the deployment workflow. An agent proposes a broader permission scope. Copilot may review the proposal and, where configured, approve it. Agent Merge may later repair a failing workflow or resolve a conflict.
For that scenario, establish four rules:
- Scope: Define whether the agent may propose deployment-permission changes and which repositories and environments are in scope.
- Authority: Decide whether a permission expansion needs approval from a designated owner independent of the proposing action.
- Revalidation: Specify which checks and approvals must repeat after another automated edit, and verify that behaviour against the final revision.
- Evidence: Retain the actor, final change, applicable policy, approval decisions and outcome so the decision can be reconstructed.
These questions evaluate the complete delivery process. They do not imply that an individual GitHub product lacks a particular feature.
Make independence a concrete requirement
For a sensitive change, name the decision owner and define how their authority is separated from the action being assessed. Depending on policy, this may involve a designated human approver or a separately governed control.
Multiple agents can improve the breadth of a review. Organisational independence also requires a defined trust boundary: who controls the decision rules, who can alter them and who can inspect the evidence? Teams should document those responsibilities alongside their technical configuration.
A checklist for security and platform leaders
| Decision | Evidence to examine |
|---|---|
| What may each agent change? | Workflow permissions, repository scope, eligible file paths and affected environments. |
| Who authorises sensitive changes? | Approval configuration, designated owners and separation-of-duties requirements. |
| What happens after an automated repair? | Approval dismissal, rerun behaviour and checks tied to the final revision. |
| Can the decision be reconstructed? | Linked change history, actor identity, policy configuration, checks and approvals. |
The aim is a delivery process in which automation has a clear mandate and every sensitive change has an explainable decision.
At Secuarden AI, our focus is the authority and evidence behind AI-assisted code changes. Adopting coding agents? Talk to us about how your team authorises sensitive changes and verifies the decision record.
Control what AI can change. Prove what it did.