The Button Says Approve

Six days ago, GitHub added approval controls for agents that tidy up issue trackers. Yesterday, it added an approval hold for potentially malicious automated workflows.

The buttons may look related. The machinery behind them is not.

In GitHub Issues, an automation can now explain why it wants to change a label, field, issue type, assignee, or status. It attaches a confidence level. High-confidence changes can happen automatically, while medium- and low-confidence changes wait as suggestions for someone to accept or decline.

That is a thoughtful review surface. It routes uncertainty toward a person without filling the issue with bot commentary. It also gives the maintainer a little more than a mysterious changed label and the uneasy feeling that a filing cabinet has begun reorganizing itself overnight.

GitHub is unusually plain about the limit, though: these approvals are a workflow convenience, not a security control. An agent with permission to change the issue can apply the change directly instead of suggesting it. The review step exists because the automation was told to ask.

The newer GitHub Actions hold has different weight. When GitHub identifies a potentially malicious workflow in a public repository, it stops the run before execution. The workflow stays stopped until a collaborator with write access approves it through an authenticated web session. The system is holding a door shut, not asking the visitor to remember their manners.

Both interfaces use the language of approval. One organizes attention. The other changes what can happen.

That difference will matter far beyond code hosting as agent interfaces spread through inboxes, finance systems, support desks, and shared workspaces. A person sees a panel saying "Waiting for approval" and reasonably assumes the system has entered a safer state. The words suggest consequence. They do not reveal whether the agent is unable to proceed, has merely promised to wait, or could choose another route with the permissions it already has.

Approval has become one of those product words that sounds more precise than it is.

Sometimes it means a suggestion has been placed in a queue. Sometimes it means execution is blocked at a server boundary. Elsewhere it may mean a probabilistic model has decided this action looks consequential enough to interrupt someone. The interface often flattens those arrangements into the same button, the same pause icon, the same reassuring sentence about keeping a human in the loop.

The person clicking pays for that ambiguity. A tired maintainer may examine an issue label with the vigilance of a security decision, wasting scarce attention on a reversible change. The same person may later approve a workflow with the casual rhythm learned from clearing harmless suggestions. The interface has taught one gesture to carry incompatible meanings.

Repeated permission prompts do not reliably repair the problem. Anthropic's account of how it contains Claude says users approved roughly 93 percent of Claude Code permission requests. Attention declined as the prompts accumulated. The company responded partly by moving more safety work into containment: sandboxes, virtual machines, and network controls that limit what an agent can reach even when a person is tired or a model finds an unexpected path.

This is the old security lesson of least privilege meeting the newer interface habit of conversational delegation. Permission is structural. Approval is an event. A well-designed system needs to show how the two relate.

When an agent asks to proceed, the useful details are surprisingly ordinary. What exact action is paused? Where is the pause enforced? What remains possible with the agent's existing access? Can it bypass the review by choosing another tool or action? What happens if nobody answers? These are not implementation notes hiding beneath the product. They are the meaning of the button.

GitHub's separate workflow execution protections point toward a clearer pattern. Administrators can define which actors and events may trigger workflows, and GitHub evaluates those rules before a run begins. The important sentence in the documentation is physical: an unauthorized actor or event never reaches execution. That tells a user what the control does in the world.

Agent products need more of that language. "Suggestion only" should look and sound different from "blocked by policy." A reversible metadata change should not borrow the alarm of a credential-bearing workflow. A prompt generated by a model should disclose that the model chose the interruption. An enforced boundary should name what enforces it and what sits outside it.

We have argued that agent controls need weight: consequence should be felt before action, not discovered afterward. Approval adds another requirement. The control needs an honest account of its force.

This also complicates the humane hope that uncertain agent work can simply be handed to people. People are not exception queues, and an interface that forwards every doubtful decision to a person has only automated the easy part. Confidence routing can be useful when the remaining cases are bounded, explainable, and supported by enough context to judge. It becomes abandonment when the system exports ambiguity while retaining the permissions that created it.

The best approval surface does more than put a person near the action. It makes the action genuinely wait, gives the person the evidence needed to decide, and preserves a boundary that remains meaningful after attention gets tired.

The button says approve. The interface should also say what the click is capable of approving—and what, until then, the system has made impossible.