Approval Fatigue Is an Agent Security Bug

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.

Anthropic's recent 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.

For the broader security frame, pair this with the OpenAI Codex cloud security playbook and prompt injection in open source. Both point to the same conclusion: agent safety has to be structural, not a popup storm.

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?"

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.

Sources

• Anthropic Engineering: Claude Code auto mode
• Anthropic: Building agents that reach production systems with MCP
• DevDigest: OpenAI Codex Cloud Security Playbook
• DevDigest: Open Source Has a Bot Problem