Skip to content
redactsure
Book a demo

Explore.

Data Report · By Chris Sowa · Published
Last updated

What Is Approval Fatigue With Coding Agents?

Approval fatigue is the state where a developer has approved so many prompts that approval means nothing, which is how auto-approve modes get switched on. The fix is a scoped grant: approve the task once, with a named scope, an expiry and a person accountable for it.

A credential reference travels from a browser record through a bounded route to a separate API destination.

Engineering leaders who give developers coding agents carry a cost that is easy to miss: a prompt is cheap to show and expensive to read. A coding agent that runs tests, edits four files, installs a dependency and pushes a branch can put a dozen decisions in front of a developer in a few minutes, and each one is worded like the last. The term for what follows is approval fatigue: the point at which the developer stops reading the prompt and starts pressing the key that lets work continue. It describes a person's attention, and it explains why a control that adds another prompt can leave a system less safe than one that removes a hundred. The adjacent failure is an approval that grants too much, and the record used here is forty prompts in a run against one task-scoped grant, read against the vendor documentation that describes where the prompts come from and the research on what an unread approval lets through. The distinction matters because the two fixes point in opposite directions: one adds friction at the moment of action, the other moves the decision earlier. The design question the definition raises is what has to be written down so the check survives when the unit of approval moves from the action to the task.

Key findings

  • Cursor's documentation states that "By default, terminal commands need your approval" and that "All MCP connections need your approval," two defaults that put a decision in front of the developer (Cursor, Agent, 2026).
  • Anthropic reports that sandboxing "safely reduces permission prompts by 84%," since "effective sandboxing requires both filesystem and network isolation" (Anthropic Engineering, 2025).
  • FINRA's 2026 oversight report, as summarized by Debevoise & Plimpton, warns that "Agents may act without human validation and may take actions that exceed the user's actual or intended scope or authority" (Debevoise & Plimpton, 2026).
  • Veracode's research reports that "GenAI models make the wrong choices nearly half the time, and it's not improving," the rate an unread approval waves through (Veracode, 2025).
  • A task-scoped grant moves the decision from each action to the task: one approval names the agent, the pages, the operations and the expiry, and the actions inside that boundary run without a new prompt (What Is Supervised Delegation?).
  • Before any model reads a screen, values chosen by policy are replaced with tokens such as DEPLOY_KEY_001, and real values resolve only at the approved destination at the moment of an approved action (What Is an AI Control Record?).

What does approval fatigue with a coding agent mean?

Approval fatigue is the state in which a developer has answered so many permission prompts that the answer stops carrying a decision. The prompts differ, but they arrive at the same cadence and in the same shape, and the cost of reading each is paid while the task waits. The term describes the developer, not the agent, which may be proposing sensible actions throughout.

The controls this page examines sit at two layers. A governed browser environment covers what an agent reads and does on a rendered page, such as a dashboard, a repository access page or a settings page, and it does not cover the terminal, the IDE, the local filesystem, direct API calls or MCP. Most prompts a coding agent shows a developer sit on the other side of that line, in the terminal and the IDE, so the definition begins with the vendor approval modes.

The record type for this page is forty prompts against one grant. A coding agent is asked to prepare a repository for a release. It checks the branch, runs the tests, edits four files, installs a dependency, commits, pushes, opens a pull request and then opens the repository's settings page to add a deploy key. Forty prompts arrive across those steps, most of them in the terminal, and each one asks for a yes or no. The developer approves the first few after reading, the next few after skimming, and the rest by reflex. One task-scoped grant replaces the sequence with a single approval that names the repository, the operations, the settings page and the expiry.

Forty approvals produce forty chances to catch a bad action and a developer who has stopped catching them. One grant produces a single review, done carefully, plus a record of what it covered.

Why do coding agents ask for so many approvals?

The count comes from the number of surfaces a tool gates separately. Cursor's agent page prompts for two surfaces by default, terminal commands and MCP connections, and says so in one line each (Cursor, Agent, 2026).

Anthropic's permission page describes the other arrangement: rules written in advance. It states that "To block Claude's file tools from reading a file or directory, add a Read deny rule for its path," and that a project's .claudeignore file "has no effect" (Anthropic, Configure, 2026).

Sandboxing changes the count. Anthropic's engineering post gives the number: sandboxing "safely reduces permission prompts by 84%" (Anthropic Engineering, 2025). The same post states that "effective sandboxing requires both filesystem and network isolation" (Anthropic Engineering, 2025).

Anthropic's sandboxing page states that the sandbox covers shell commands only and that Read, Edit, Write, WebFetch, WebSearch, MCP servers and hooks run outside it (Anthropic, Sandboxing, 2026). Cursor's ignore-file page adds that the terminal and MCP tools "cannot block access to code governed by .cursorignore," so a path rule narrows reading and leaves the terminal prompts untouched (Cursor, Ignore, 2026).

What happens when an approval is given without reading?

The first casualty of the fortieth prompt is the reading, not the decision. A developer who has approved thirty actions in a row is still making a choice at the fortieth, and the choice is to keep moving.

The obvious response is to remove the prompts, and every coding agent offers a mode that does. Cursor describes its run modes as "best-effort guardrails rather than a hard security boundary," so choosing a looser mode trades a check for speed rather than removing the risk (Cursor, Agent, 2026). Anthropic's help center states that Claude in Chrome defaults to an automatically approve mode (Does Claude in Chrome Use Your Saved Logins and Open Sessions?).

Debevoise & Plimpton's summary of FINRA's 2026 report flags that "Agents may act without human validation and may take actions that exceed the user's actual or intended scope or authority" (Debevoise & Plimpton, 2026). The concern is validation and scope, not volume, and a switch that removes the prompt removes the validation with it.

GitGuardian's data, as reported by Help Net Security, counted "28,649,024 new secrets exposed in public GitHub commits across 2025," and commits co-authored by an AI coding agent leaked credentials at roughly double the baseline rate (How Do You Let an AI Agent Manage API Keys Without Reading Them?).

What do the vendors themselves say?

Both vendors document gates, and neither documents a grant that covers a task. Cursor's agent page sets two defaults, that "By default, terminal commands need your approval" and that "All MCP connections need your approval," per-action decisions that a run mode can pre-answer (Cursor, Agent, 2026). Its ignore-file page adds that the terminal and MCP tools "cannot block access to code governed by .cursorignore," so a path rule and a command gate cover different ground (Cursor, Ignore, 2026).

Anthropic's documentation is more specific about where each gate sits. The sandboxing page states that the sandbox covers shell commands only, and that Read, Edit, Write, WebFetch, WebSearch, MCP servers and hooks run outside it, so a rule written for one surface does not govern another (Anthropic, Sandboxing, 2026). The page describes masked credentials, where "the sandboxed command sees a sentinel and the local proxy substitutes the real value only on hosts in injectHosts," a control for sandboxed commands and not for the Read tool (Anthropic, Sandboxing, 2026). The same page adds that "A denyRead entry doesn't stop the Read tool" and that Read, Edit and Write follow permission rules instead, so keeping a value from the model is a permission decision rather than a sandbox setting (Anthropic, Sandboxing, 2026).

Dimension Cursor, per its documentation Claude Code, per its documentation What a buyer should verify
Terminal commands Prompted by default Sandboxed when the sandbox is on; Read, Edit and Write follow permission rules Which commands still prompt once a sandbox is on
MCP connections Prompted by default MCP servers run outside the sandbox Whether an MCP server's output reaches the model unread
File reads .cursorignore blocks code accessible by the agent; terminal and MCP tools cannot block it A Read deny rule blocks the file tools; a denyRead entry does not Whether the block covers the tool that actually reads the file
Credentials Not documented on the agent security page Masked credentials: the sandboxed command sees a sentinel and the proxy substitutes the value for listed hosts Whether the value is ever rendered to the model outside the sandbox
Unit of approval Per action, per surface Per action, plus a permission rule Whether a grant can cover a whole task
Run modes "best-effort guardrails rather than a hard security boundary" Not documented on the page What a looser mode stops checking

The pattern across the pages is a decision per action, with a rule or a mode to pre-answer it. A task-level grant is not described in the pages reviewed, and the unit both vendors work in is the action.

What is the difference between per-action approval and a task-scoped grant?

The difference is the unit of the decision. Per-action approval asks whether this command, this edit or this connection may proceed, at the moment it is proposed. A task-scoped grant asks what the task is, which resources it needs and how long it should run, once, before the agent starts. The first is a decision the developer makes forty times; the second is made once.

Willison's design patterns point at the same unit: they "constrain the actions of agents to explicitly prevent them from solving arbitrary tasks" (Willison, 2025).

OWASP's non-human identity list supplies the failure the grant addresses. It names NHI2 Secret Leakage as the "leakage of sensitive NHIs such as API keys, tokens, encryption keys, and certificates to unsanctioned data stores" and lists NHI5 as overprivileged identities (OWASP, 2025). A per-action approval can be answered correctly forty times and still leave the agent overprivileged.

AWS states that it strongly recommends not creating access keys for the root user, which rules out the simplest way an agent might be given top-level power that outlasts the task (Is It Safe to Let an AI Agent Set Up Your Cloud Environment?). A task-scoped grant is the opposite shape: it grants what the task needs.

Dimension Forty per-action prompts One task-scoped grant
What is approved One command, edit or connection The task, its pages and its operations
Who decides The developer, forty times A named person, once
When At the moment of the action Before the run starts
Scope Whatever each action needs The smallest set the task needs
Expiry None; the next action prompts again A time and a run boundary
Record A list of prompts and answers A grant, an approver and what it covered
Failure mode Approval without reading A grant that is too broad

A grant that is too broad is the overprivileged identity OWASP names, and a grant with no record is a decision nobody can audit. The design that survives both is a narrow grant, a named approver, an expiry and a record of what it covered.

What does a governed environment change?

A governed environment is a control class that acts where a screen is rendered, before any model reads it, and it changes the unit of approval from the action to the task. A person approves the task: the agent, the pages it may open, the operations it may perform and the time it may run. Inside it the agent works without a new prompt for every command; outside it, nothing proceeds.

In the governed environment, values chosen by policy are replaced with consistent tokens for the whole run, so a settings page that shows a deploy key renders DEPLOY_KEY_001 and the model never holds the value. Real values appear only at the approved destination, at the moment of an approved action, so the key is written to the repository settings form the person approved.

Accountability is the next layer. A named person confirms which values are tokenized and approves each consequential action inside the grant. The record is the last: every screen as tokens, every action and every approval with a name, exported to the organization's own monitoring.

For this page's question, the questions are asked once, at a level where a person can answer them carefully, and the answer is written down. Forty prompts become one grant, one approver and one record.

A value the model reads is a value it can repeat: extraction research recovered training data verbatim (How to Use AI Agents to Deploy Azure GPU Virtual Machines). Least Exposure is the term for limiting what the agent receives for a task (What Do RedactSure's AI Security Terms Mean?).

Methodology and limitations

This page rests on vendor documentation from Cursor and Anthropic, including a Claude Code permission page, a sandboxing page and an engineering post about sandboxing; on a law firm summary of FINRA's 2026 regulatory oversight report; on OWASP's non-human identity risk list; on a practitioner analysis of design patterns for agent security; on a Veracode press release about generated code; and on existing RedactSure research pages. Vendor pages were read between October 20, 2026 and October 21, 2026, and each Sources line carries the date for its page. Quoted facts are cited to the page that states them, and figures from the Veracode press release are cited as reported rather than as independently measured.

RedactSure did not test any of the named products hands-on. Where the page says a behavior is not described in the pages reviewed, the statement covers the vendor pages cited and not the product's full behavior; the run modes, sandbox coverage and permission rules described here are the vendor's own account. Vendor features change, and the page carries its date, so a release after that date should be treated as unreviewed until the vendor page is read again. The page does not compare prompt counts across products. Statements about RedactSure describe current design, and RedactSure is deploying now with enterprise and government customers. The example describes a record type, a repository prepared for a release with forty prompts and one task-scoped grant, and not an organization.

Determinations about whether a particular approval flow meets a contractual, regulatory or audit requirement belong to counsel, assessors and the organization's own security and compliance officers. Nothing here replaces a test of the organization's own agent and its approval record, repeated after each release.

What the record shows

For a team deciding how much to let a coding agent do, the record on this page is consistent in one respect: every vendor control reviewed answers a decision at the moment of an action, and none of them describes a grant that names a task and the time it may run. Cursor prompts per surface, Claude Code prompts or applies a permission rule, and the modes that reduce the prompts are described by their own vendor as best-effort guardrails. The research and the regulatory record describe what happens when the answers are given without reading: agents act without validation, and generated code is wrong often enough that the check matters. The alternative is a larger decision made earlier, with a name on it. Counting is the simplest test here: pick one agent and one task, count the prompts the run produces, and ask which of them a single named person could have answered before the run began.

Frequently asked questions

What is approval fatigue with coding agents?

Approval fatigue is the point at which a developer has answered so many permission prompts that the answer stops being a decision. It is a description of attention, not of the agent, which may be proposing sensible actions throughout. It shows up first in the prompts that look routine, because those are the ones answered by reflex. To test for it, ask a developer to explain the last five approvals and count how many can be reconstructed from memory. Most teams find the explanation stops at the third one.

Why do coding agents ask for approval so often?

Each tool gates a different surface: terminal commands, MCP connections, file edits outside the workspace, network access. Cursor prompts for terminal commands and MCP connections by default, and Claude Code applies permission rules to its file tools while its sandbox covers shell commands only. Each gate is a separate decision, so the count rises with the number of surfaces rather than with the risk of the task. A task that touches four surfaces produces four kinds of prompt.

Does auto-approve mode solve approval fatigue?

It removes the prompts, which is not the same as answering them. Cursor calls its run modes best-effort guardrails rather than a hard security boundary, so a looser mode trades a check for speed. The fatigue disappears and so does the record of who allowed what. A mode is a setting on a gate, not a substitute for a decision that someone stands behind. The switch is easy to turn on and hard to see in a later review.

What is a task-scoped grant?

A task-scoped grant is one approval that names the agent, the pages it may open, the operations it may perform, the resources it may touch and the time it may run. Inside that boundary the agent works without a new prompt for each action. The unit of the decision moves from the command to the task. The grant is only as good as its scope and its expiry, which is why both have to be written down. A grant with an unclear boundary is a prompt with extra steps.

How long should a task-scoped grant last?

Long enough to finish the task and no longer. A grant that outlives the run becomes standing access, which is the overprivileged identity OWASP lists as a non-human identity risk. The expiry should be a property of the grant rather than a reminder someone sets. A team that cannot say when a grant ends cannot say what the agent can still do tomorrow. Set the expiry before the run and check it after, rather than extending it in place. Check the date on it first.

Can a developer still review what was approved?

Only if the approval leaves a record. A prompt that is clicked and forgotten produces nothing a reviewer can read later. A grant should carry the name of the approver, the scope, the time and the screens the agent saw, so the review can happen after the run rather than during it. The record is the difference between a decision and a reflex. It should name the pages as well as the actions, since the pages are what the model read.

About the author

Chris Sowa is a founder of RedactSure and a former CEO of an AI company; he started it years before ChatGPT existed. He previously led AI at Accenture, served as Global VP of Strategy & Innovation at Schneider Electric, was CCO of Sovos, and spent more than a decade at Oracle, with earlier roles at SAP and IBM.

How RedactSure Turns Forty Prompts Into One Approved Grant

Forty prompts arrive at the speed of attention, so the answer that keeps work moving is the one a developer gives without reading.

The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company.

Before: the developer approves forty prompts across the run, then approves the settings page without reading it, and the deploy key is rendered to the model. Inside: one grant covers the task, the settings page renders DEPLOY_KEY_001, and the real key resolves when the named approver confirms the addition.

RedactSure is deploying now with enterprise and government customers. Anthropic reports that sandboxing "safely reduces permission prompts by 84%."

Everyone else controls where data can go. RedactSure controls what the AI can see.

See it on your own workflow

Forty prompts in one run teach people to approve without reading. Bring a task your developers approve over and over and see, with test values, the one grant they would read instead. Book a demo

Book a demo

Book a demo

Having trouble? Open the booking page or email us.