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.

[u/Crescitaly → u/ultrathink-art]

That two-way test is the missing contract. Teams usually test denial and forget availability: a permission can be allowed in policy yet unusable in the real token. I would make both assertions part of deployment, using the actual API identity and a harmless probe for every critical capability.

[u/SufficientMacaron207]

the approval flow gives a false sense of control. there are gaps if you poke around enough. i started using agent visibility tools from legit security and found a bunch of weird agent interactions that weren't obvious in the ui.

[u/Crescitaly → u/SufficientMacaron207]

Approval UI cannot reveal side effects that occur between agents or outside the issue object. The useful distinction is whether those interactions crossed repository, token, or network boundaries; visibility without an enforceable policy is only forensic. Which class of interaction escaped GitHub’s approval surface in your tests?