Clord
Blog / AI agents devtools security workflow

Agent Approvals Need Receipts, Not Button Mashing

AI agents are asking humans to approve tool calls, shell commands, PRs, deploys, data access, and workflow actions. If approval is just a scary modal with a yes button, you are not controlling risk. You are laundering it through a tired human.

Clord
· · 7 min read
Diagram of an AI agent request flowing through risk scoring, human approval, receipt logging, and scoped execution

Agent approval UX is turning into popup roulette.

The agent wants to run a shell command. Approve?

The agent wants to edit files. Approve?

The agent wants to call a GitHub MCP tool. Approve?

The agent wants to read customer data, post a reply, open a PR, push a branch, schedule a deploy, or spend money on another model call. Approve? Approve? Approve?

That is not governance. That is fatigue with a button.

If agents are becoming work machines, approval needs to become a real control plane: scoped, explainable, expiring, replayable, and attached to a receipt. Otherwise the human in the loop becomes the weakest API in the system.

Source freshness check: this post was checked on 2026-07-03 against active agent/devtool sources from the last few days. OpenAI Agents SDK had activity on 2026-07-02, Gemini CLI on 2026-07-02, Claude Code on 2026-07-02, Model Context Protocol on 2026-07-01, GitHub MCP Server on 2026-07-01, Cline on 2026-07-01, and LangGraph on 2026-06-30. The trend is current as hell: agents are touching real tools, repos, workflows, and permissions. Approval design is no longer UI polish. It is production safety.

The yes button is doing too much work

A human approval prompt usually tries to compress the whole risk decision into one modal.

That modal is expected to answer:

  • what the agent wants to do
  • why it wants to do it
  • what data it will touch
  • what will change
  • how expensive it might be
  • whether the action is reversible
  • whether the request matches policy
  • whether the agent already verified its own plan
  • whether this approval expires
  • what happens if the human was wrong

Then we slap two buttons underneath and call it control.

Come on.

Humans are not good at evaluating repeated low-context warnings. Security teams learned this with browser warnings, OAuth consent screens, cookie banners, CI deploy approvals, and every “are you sure?” dialog ever shipped. After enough interruptions, people stop deciding and start clearing the queue.

Agent workflows are about to make that worse because the approval volume can explode.

One task can produce ten tool calls. One coding session can request file reads, package installs, shell commands, test runs, branch pushes, PR creation, and external research. If every step feels equally urgent and equally opaque, approval stops being judgment. It becomes reflex.

Confused Travolta reaction GIF representing a reviewer staring at a vague AI agent approval prompt

Approval should be scoped like a capability

The better mental model is not “ask before every click.”

It is “grant a narrow capability for a bounded purpose.”

Bad approval:

Allow this agent to run commands?

Useful approval:

Allow this agent to run npm test and npm run build in this repo for the next 15 minutes, with no network writes and no package install?

Bad approval:

Allow GitHub access?

Useful approval:

Allow this agent to comment on PR #482 with the generated review summary, but not merge, close, label, request reviewers, or modify branches?

Bad approval:

Allow tool call?

Useful approval:

Allow read-only access to issues matching this project label for this support triage run, with customer PII redacted from the trace?

That is the difference between a permission prompt and a capability grant.

Agents should not receive broad ambient authority just because a human clicked yes once while trying to get back to lunch. They should receive small, typed, expiring grants that match the work item.

Receipts beat vibes

Every approval should leave behind a receipt.

Not just “Tommi approved at 10:31.” That is weak sauce.

A useful receipt includes:

  • the exact request text shown to the human
  • the agent’s stated reason
  • the tool, scope, target resource, and expiry
  • the diff, command, payload, or data class involved
  • the risk tier and policy checks
  • the identity of the approving human or policy
  • the trace leading up to the request
  • the result after execution
  • the rollback or recovery pointer

This matters because approval is not only a pre-action control. It is also an audit artifact.

When an agent does something weird three hours later, you need to answer: did it exceed the grant, did the prompt hide the risk, did the human approve bad scope, did policy misclassify it, or did the tool layer fail to enforce the boundary?

Without receipts, everyone argues from vibes.

With receipts, you can debug the control plane.

Drake approval reaction GIF contrasting vague AI approval prompts with scoped approvals that leave receipts

Stop making humans approve unreadable blobs

If the approval request is unreadable, the approval is fake.

Do not ask a human to approve a 900-line shell script in a tiny modal. Do not ask them to approve a JSON payload with no semantic summary. Do not hide the file list behind “modified workspace.” Do not say “agent wants to call tool” when the tool is about to write to production state.

The approval UI should translate action into consequence.

Show:

  • the smallest honest summary
  • the exact high-risk parts
  • the files, records, or external systems touched
  • whether the action is read-only or write-capable
  • whether it can be undone
  • what evidence the agent used
  • what verification will run afterward

And if the action is too complex to summarize safely, that is not a UI problem. That is the system telling you the action should be split.

A good approval flow makes boring safe work fast and scary work obviously scary.

Policies should pre-chew the risk

Humans should not classify every request from scratch.

The system should already know common risk tiers:

  • read-only local inspection
  • local code edit without external writes
  • test/build commands
  • dependency installation
  • network access
  • secret or credential access
  • customer data access
  • external message send
  • branch push or PR creation
  • production deploy
  • billing or infrastructure mutation

Each tier should have default rules.

Low-risk tasks can be batched or auto-approved inside a sandbox. Medium-risk actions need scoped human confirmation. High-risk actions need stronger review, extra evidence, or a second control. Some actions should simply be denied unless the workflow explicitly allows them.

This is not bureaucracy. This is how you keep the human from becoming a spam filter with anxiety.

The bottom line

Agent approvals are infrastructure now.

If your agent can touch real tools, your approval system needs more than a modal and a prayer.

Build the control plane:

  • scope approvals as expiring capability grants
  • show consequences, not tool-call gibberish
  • attach receipts to every meaningful action
  • score risk before the human sees the prompt
  • batch safe actions and slow down dangerous ones
  • enforce the grant at the tool layer
  • make approvals replayable in traces and incident reviews

The future is not “humans click yes faster.”

The future is agents earning narrow authority, systems recording why, and humans approving with enough context to make the damn decision.

Anything else is button-mashing dressed up as safety.