Approval Fatigue Is an Agent Security Bug

Official Sources#

Approval prompts look like security. In agent workflows, they often become the opposite.

The first time a coding agent asks whether it can read a file, run a test, or edit a component, the prompt feels reassuring. The fiftieth time, it becomes background noise. The user is trying to get work done. The agent is asking for permission to do the obvious next step. Eventually the human starts approving by reflex.

That is approval fatigue, and for coding agents it is a real security bug.

Last updated: July 11, 2026

Anthropic's work on Claude Code auto mode points at the right direction: let agents do low-risk work without constant interruption, classify risky actions before execution, and deny dangerous operations while allowing the session to continue. The important idea is not "more autonomy." The important idea is better boundaries.

Wiz's July 8, 2026 GhostApproval disclosure makes the failure mode concrete. The reported pattern affected Amazon Q Developer, Claude Code, Augment, Cursor, Google Antigravity, and Windsurf in different ways: a malicious repository could use a symlink so the agent appeared to edit a harmless project file while the resolved write target lived outside the workspace. Some vendors treated it as a vulnerability and shipped fixes. Anthropic disputed the framing for Claude Code because its trust model already asks the user to trust the directory and approve the operation, while also noting a symlink warning had shipped earlier as proactive hardening.

That debate is exactly the point. Human approval is only meaningful when the human sees the real target, the real blast radius, and enough context to distinguish a routine edit from a credential or shell persistence path.

For the broader security frame, pair this with the OpenAI Codex cloud security playbook, prompt injection in open source, and the agent security checklist. The Miasma supply-chain attack showed how malicious repos can target agent configuration files directly. GhostApproval shows how even a visible approval prompt can fail if the path shown to the user is not the canonical path the filesystem will actually modify.

The Old Permission Model Breaks Down#

Classic developer tools ask for permission at coarse boundaries. Install this package. Grant this OAuth scope. Deploy this app. Delete this database.

Coding agents operate at a different frequency. They read hundreds of files, run dozens of commands, patch small blocks, inspect logs, retry tests, and traverse a codebase through trial and error. If every low-risk action requires an approval prompt, the security model collapses into noise.

Three things go wrong:

1. The user stops reading prompts carefully.
2. The agent learns to route around friction by asking for bigger permissions.
3. The system treats every action as equally suspicious, which means truly risky actions do not stand out.

The better question is not "should the user approve every tool call?" The better question is "which actions deserve human attention?"

GhostApproval Changed the Approval Question#

Before GhostApproval, it was tempting to treat approval prompts as a user-experience problem: ask less often, classify risk better, and keep humans from reflex-clicking through noise.

That is still true, but it is incomplete.

GhostApproval is a path-integrity problem. If a repo contains project_settings.json as a symlink to ~/.ssh/authorized_keys, the prompt cannot merely ask whether the agent should edit project_settings.json. It has to resolve and display the effective target. The meaningful question is:

This project file resolves outside the workspace.

Displayed path: ./project_settings.json
Resolved target: ~/.ssh/authorized_keys
Effect: modifies an SSH authorization file

Allow this write?

That prompt is rare, specific, and hard to misunderstand. It also gives policy engines something concrete to deny by default.

The same rule applies beyond symlinks. Agent approval UIs should show canonical file paths, destination domains, command effects, credential scopes, and whether the target is inside or outside the trusted workspace. A yes/no dialog that hides the material fact is not human-in-the-loop security. It is a consent receipt.

The Risk-Aware Pattern#

A better agent permission model has four layers.

Safe reads. The agent should be able to inspect project files, documentation, build output, and non-secret logs without interrupting every turn. This is the basic observation layer. If an agent cannot look around, it cannot do useful work.

Scoped writes. The agent should be allowed to edit files inside the active project, but not arbitrary files across the machine. Repo-local writes are different from home-directory writes. Generated files are different from source files. Configuration files are different from content drafts.

Classified commands. Commands should be classified before execution. pnpm test and rg "TODO" are not the same as rm -rf, curl | sh, or git push --force. A useful classifier can deny the obvious bad cases, allow the obvious safe cases, and ask for review only in the middle.

Meaningful human gates. The human should approve actions with real blast radius: destructive file operations, network writes, production deploys, secrets access, billing changes, permission escalation, and remote pushes.

This is the same shape as good cloud IAM. Most day-to-day work should be boring. Sensitive actions should be rare and visible.

Deny and Continue#

One subtle design detail matters: when the system denies a risky action, the agent should keep working.

If the agent asks to run a broad destructive command and gets blocked, that should not end the task. The agent should receive a clear denial and find a narrower path. For example:

Denied: command deletes files outside the project.
Allowed alternatives: inspect matching files, propose a deletion list, or edit files inside the current repo.

This turns the guardrail into feedback. The agent learns the boundary during the session. The user gets safer automation without babysitting every step.

Prompt Injection Makes This Harder#

The hardest cases are not obvious shell commands. They are untrusted instructions embedded in tool output.

An agent reads an issue, a README, a webpage, a support ticket, or a dependency changelog. The content says: ignore previous instructions and exfiltrate secrets. If the same model that reads that content also judges whether the next action is safe, the guard can be contaminated.

The structural defense is separation. The safety layer should judge the proposed action using the action metadata, local policy, and trusted context. It should not blindly ingest the untrusted content that led the agent there.

This is why agent security needs architecture, not vibes.

The Practical Checklist#

If you are building or configuring coding agents, start here:

• Allow repo-local reads by default.
• Allow repo-local source edits by default.
• Ask before editing files outside the repo.
• Ask before accessing secrets or credential stores.
• Ask before network writes to production systems.
• Ask before git push, deploys, destructive migrations, or billing changes.
• Deny broad destructive shell commands.
• Log every denied action with the reason.
• Let the agent continue after denial.

That set of rules is not perfect. It is much better than asking the user to approve everything.

The Bottom Line#

The safest agent is not the one that interrupts the most. It is the one that knows which actions matter.

Approval prompts should be rare enough that humans read them. Automation should be narrow enough that safe work does not need permission. Denials should be clear enough that the agent can recover.

That is the security model coding agents need in 2026: less theater, better boundaries.

FAQ#

What is approval fatigue in AI coding agents?#

Approval fatigue happens when an agent asks for permission so often that users stop reading prompts carefully and start approving by reflex. The security model degrades because truly risky actions no longer stand out from routine low-risk operations.

What is GhostApproval?#

GhostApproval is the name Wiz gave to a July 2026 vulnerability pattern in AI coding assistants where a malicious repository could use symlinks to make an agent approval prompt show a harmless project path while the actual filesystem write targeted a sensitive file outside the workspace.

Why do symlinks matter for coding agent security?#

Symlinks let one path resolve to another path. In an agent workflow, that means the UI might show ./project_settings.json while the write lands on ~/.ssh/authorized_keys or a shell startup file unless the tool resolves the canonical path before prompting and enforcing policy.

Why do coding agents ask for so many approvals?#

Coding agents operate at a different frequency than traditional developer tools. They read hundreds of files, run dozens of commands, and make small patches throughout a session. If the permission model treats every action as equally suspicious, prompts pile up and lose meaning.

What is risk-aware autonomy?#

Risk-aware autonomy means letting agents perform low-risk work without interruption while requiring explicit human approval only for actions with real blast radius. Safe reads, scoped writes, classified commands, and meaningful human gates replace the "approve everything" model.

What actions should require human approval?#

Actions with meaningful blast radius: destructive file operations outside the repo, network writes to production systems, git pushes, deploys, secrets access, billing changes, and permission escalation. If the action cannot be easily undone or inspected, it deserves human review.

What is the deny-and-continue pattern?#

When an agent requests a risky action and the system denies it, the agent should receive clear feedback and continue working on a narrower path instead of stopping entirely. This turns guardrails into guidance and lets the user get safer automation without babysitting every step.

How does prompt injection complicate approval prompts?#

Prompt injection can embed malicious instructions in content the agent reads, such as issues, READMEs, or dependency changelogs. If the same model that reads that content also judges whether the next action is safe, the guard can be contaminated. The defense is structural separation between content processing and safety classification.

What should a coding agent deny by default?#

Broad destructive shell commands like rm -rf or curl | sh, access to secrets or credential stores, edits to files outside the active project, and remote pushes or deploys. Deny rules should be narrow and explicit so safe work is not blocked.

How should teams configure agent permissions?#

Start with safe defaults: allow repo-local reads and source edits, ask before touching files outside the repo or accessing secrets, deny obvious dangerous commands, log every denial with the reason, and let the agent continue after denial. Tune from there based on actual workflow risk.