The Code Needed a Human Approval. GitHub Let the Agent Give It.

There is a small piece of GitHub infrastructure that almost every open source maintainer has clicked without thinking about it. Someone opens a pull request from a fork. The CI does not run. A yellow banner appears asking a maintainer to approve the workflow. You look at the diff, you decide the contributor is not trying to exfiltrate your secrets, and you click Approve and run.

That click is a security decision. On 16 August 2026, in a pre release of GitHub Agentic Workflows, it became something an agent can request.

What actually shipped, precisely

The project is github/gh-aw, GitHub Agentic Workflows. It is a system for running AI agents as GitHub workflows, where any write action the agent wants to take goes through an opt in mechanism the project calls safe outputs. The agent does not call the GitHub API itself. It emits a request, and a handler decides whether to perform the mutation.

Version v0.87.0 was published on 16 August 2026 and is marked Pre-release on GitHub. The release notes describe it as a major internal hardening pass, dozens of custom linters, security fixes and refactors, plus one new safe output capability for handling fork pull requests. That capability is approve-workflow-run, described in the release notes as experimental, and pointed at a design record, ADR-52541. The project's own weekly update, published 17 August 2026, repeats the same framing: an experimental safe output that lets agents programmatically unblock GitHub's fork PR approval gate, with strict guardrails.

The workflow was waiting for a person

The gate this feature addresses is described in the ADR in one sentence. GitHub's fork pull request approval gate blocks workflow runs from untrusted forks until a repository maintainer explicitly approves them.

The reason it exists is stated equally plainly, in the section where the project considers simply turning the gate off. That alternative was rejected because the approval gate is a meaningful security control: it prevents untrusted code from fork PRs running in CI with access to repository secrets. Disabling it, the ADR says, trades a workflow convenience problem for a real supply-chain risk.

So the click is not ceremonial. It is the moment a maintainer takes responsibility for letting a stranger's code execute inside their CI environment.

GitHub Agentic Workflows removed the human bottleneck

The ADR is candid about the motivation. AI agents in the gh-aw system could not unblock those runs programmatically. A human had to visit the GitHub Actions UI and click Approve and run. The document calls this a bottleneck in automated workflows where an AI agent is expected to handle routine fork PR triage but cannot advance the CI pipeline without human intervention.

The stated goal, then, is to remove a human step from a security control. I want to be careful with that sentence, because it sounds like an accusation and it is not. It is a description of the problem the feature was built to solve, and the project says so itself.

The agent does not get to approve anything it wants

This is where fairness matters, and where most coverage of features like this goes wrong.

The agent does not receive an approval token. It emits a safe output request. A dedicated handler then performs a series of deterministic checks before anything is approved. According to the ADR, the handler refuses pull_request_target events. It fetches the workflow run from the GitHub API and verifies that the run's event is pull_request, that it has an associated pull request, and that its status is waiting. It requires the workflow filename to match a configured allowed-workflows wildcard list. It requires every associated pull request to be either the triggering pull request or one explicitly listed in allowed-pull-requests. It refuses pull requests from forks unless fork: true is explicitly configured. Before approving, it lists the files modified by each associated pull request and rejects protected-file changes, with a documented exclusion mechanism.

The permissions are narrow and explicit. The operation requires actions: write and pull-requests: read, and it requires a separate external github-token or a GitHub App token, because the default github.token cannot approve fork pull request workflow runs at all. There is a staged mode that previews the request without touching the GitHub API, and the default maximum is one approval per workflow execution. The operation is classified alongside merging and closing pull requests in the project's threat detection categories.

That is a real control layer. Nobody handed a language model an approval button.

Approval is an action too

Here is where my reading starts rather than the ADR's.

The mental model most teams carry for agent safety is a two role model. The agent proposes an action. A human approves it. Everything we call an approval workflow, a permission prompt, a change advisory board or a merge gate assumes those two roles stay in different bodies.

What this feature demonstrates is that the second role is not structurally special. Approving is an API call. It has a verb, a target and a consequence, exactly like deleting a table or transferring money. Once you can express it as an operation, an agent can be given a path to perform it, and the reason it stayed human for so long was convention plus the absence of a mechanism.

So the question a policy has to answer changes shape. It used to be enough to write down which actions require approval. That sentence quietly assumed that requires approval and requires a person were the same statement. They are not, and this release is the clearest illustration I have seen of the gap.

Notice what the project itself does with that gap. It does not treat approval as a low risk read operation. It puts approval in the same threat category as merging and closing pull requests, defaults it to one per run, demands a separate credential, and lists file level protections in front of it. Read the design decisions as a statement of belief and they say: this mutation is dangerous enough to constrain heavily. I agree. That is precisely why it belongs in the authority model rather than outside it.

The rejected alternatives are the most revealing part

Two options were considered and turned down, and both are informative.

The first was giving agents a pre authorized token with actions: write and letting them call the REST API directly. The ADR rejects it because it skips the safe output sandboxing guarantees, naming per handler max counts, staged preview mode, GitHub App token rotation and threat detection classification, and warns that circumventing those controls for one operation would create an inconsistent security posture.

The second was disabling the fork approval gate entirely, which the ADR rejects as trading convenience for supply chain risk.

Between those two rejections sits the actual design. Keep the gate. Do not give the model a credential. Make the approval a constrained, logged, rate limited mutation that a deterministic layer decides whether to execute. Whether or not you would enable this in your own repository, that is a coherent position, and it treats approval as sensitive rather than administrative.

What the project says could go wrong

The ADR does not oversell itself. Under negative consequences it states that actions: write is a broad GitHub permission scope, and that a compromised or misbehaving agent with this safe output enabled could approve workflow runs from malicious forks. It also notes that the sequence of fetching the run and its files, verifying eligibility, then approving is not atomic, so a time of check to time of use race is theoretically possible, while adding that the practical risk is low because the approval endpoint validates eligibility server side.

Two things are true at once. The project acknowledges a genuine failure mode, and the entire design exists to constrain it. Nothing I have read suggests GitHub considers the feature unsafe overall, and there is no incident here. No malicious fork was approved. No breach occurred. This is an architecture story, not an incident story.

I should also state what the documents do not settle. ADR-52541 is dated 13 August 2026 and was marked Draft when we read it, with a closing note asking reviewers to finalize it before changing the status to Accepted. So it is a design record under review, not a finalized GitHub wide architecture standard, and its details could change. How widely the safe output is adopted, and by which repositories, is unknown to us.

This is not the same story as Claude Code auto mode

It would be easy to file this next to Claude Code making auto mode the default, and they are genuinely different.

Auto mode automates the question of whether a human needs to be asked. A classifier decides which actions are routine enough to skip the prompt. Escalation is what became automatic.

This is the other half. The question of whether approval is required has not changed at all. GitHub's gate still says a fork run requires approval. What changed is who is capable of supplying it. One system automates the decision to escalate. The other delegates the approval operation.

Those failure modes are not the same. A bad escalation decision means a person never saw something they should have. A bad approval decision means the security control was satisfied by something that is not a person and cannot be held accountable in the way the control assumed.

Human Authority becomes programmable

The vocabulary here is ours, not GitHub's, and I want to be explicit about that. Neither the release notes nor the ADR uses the language that follows.

Moona Intelligence has been using Agent Authority to mean the set of actions an agent is permitted to execute, against which targets, with whose permission. This release makes a companion term useful. Call it Human Authority: the set of decisions reserved for a person, and the conditions under which that reservation can legitimately be delegated to software.

The moment approval becomes an executable operation, Human Authority stops being an implicit property of the system and becomes something you have to declare. Which decisions must be made by a person. Which of them can be delegated to a deterministic rule. Which can be delegated to a model. And when a decision was made, which of those three made it.

We have been circling this from other directions. When AWS shipped an agent that could submit a decision but not finalise it, the boundary was drawn between preparing an outcome and committing it. When we argued that you cannot prompt your way out of agent authority, the point was that authority is decided at execution, not in the instruction. And when an agent created another agent, the open question was which permissions travel with a delegation. Approval authority is the same family of question, one rung higher.

The question after the question

If you run agents against repositories, cloud accounts or databases this week, the useful exercise is not to have an opinion about gh-aw. It is to look at your own approval steps and ask which of them assume a human, and whether that assumption is written down anywhere or merely inherited from a time when no software could click the button.

Because once agents can approve consequential actions, does this require approval is no longer the last question.

The next one is: who is authorized to give it?