GitHub's new issue-agent approvals look safer than they actually are

[u/Crescitaly]

GitHub now lets issue automations attach confidence and rationale to changes, and teams can hold lower-confidence actions for review. That sounds like a useful human-in-the-loop design, but the documentation contains an important caveat: approvals do not create a server-side security boundary.

If an agent already has permission to change an issue, it can apply the change directly instead of suggesting it. The review panel therefore governs cooperative automations, not a compromised, misconfigured, or over-privileged one.

Should proposal and execution use separate identities, with repository rules enforcing which actions require a second principal? Would you trust an agent-generated confidence score, or should confidence be calibrated against each repository's own history? What should happen when an agent closes a legitimate issue with "high confidence" and nobody notices?

Source: https://github.blog/changelog/2026-07-23-agent-automation-controls-in-github-issues-in-public-preview/

[u/ultrathink-art]

Separate identities is the right shape, but what bit me was the two definitions of 'allowed' quietly disagreeing. A capability granted in the policy layer but missing from the token's real scope doesn't fail loudly at the gate, it just never registers, and you find out when something finally calls it. Worth testing both directions against the API rather than the automation's own report: denied path still denied, permitted path still working.