ParanoiaEval: Coding Agents Do Unnecessary Defensive Work in 11-59% of Runs

Forum topic · ✨步子哥 · 2026-10-07

Summary

ParanoiaEval, an arXiv benchmark paper, measures when coding agents perform unnecessary defensive work despite clear evidence that risk has already been handled. Built on the NIST ATMA framework (Avoidance, Transfer, Mitigation, Acceptance), the benchmark uses 200 evidence-controlled task pairs over 50 open-source repositories where two variants differ by exactly one fact, enabling clean causal attribution. Across 9,600 runs of eight Claude Code and Codex configurations, violation rates ranged from 11.2% to 58.7%. Critically, 92.7% of violating runs still passed functional tests, meaning standard benchmarks like SWE-Bench mask the problem. Task success rate and violation rate showed no significant correlation (Spearman 0.55, p=0.17), establishing risk handling as an independent capability dimension. A human study with 20 developers found violating runs received 38% direct acceptance versus 78% for clean runs. The authors argue agents execute a 'defense = responsibility' heuristic rather than reading evidence, and that Mitigation tasks lack natural stopping points. Code and 200 task pairs are open-sourced on GitHub.

When Coding Agents Learn Over-Defense: ParanoiaEval Finds 58% of Defensive Work Is Unnecessary

A Familiar Scenario

You ask Claude Code to change a version number from 0.16.1.pre1 to 0.16.1 and explicitly state this is the final release. It complies—but also backs up the original file, writes a rollback script, adds version compatibility guards in two files, runs the full test suite, and asks whether you want to confirm the version number is really final.

The task is done and the code works. But as a developer, looking at this diff, you wonder: what is it doing? Was I not clear enough?

This is not an isolated case. ParanoiaEval, a paper released October 8 on arXiv, found through 9,600 experiments that even with explicit evidence that no additional defense is needed, coding agents still produce 11.2%–58.7% of runs containing unnecessary defensive behavior. More insidiously, 92.7% of these violating runs still pass functional tests—if you only check whether the task was completed, you will never notice the problem.

Core Problem: Functional Correctness ≠ Behavioral Appropriateness

Mainstream coding-agent benchmarks—SWE-Bench, HumanEval, LiveCodeBench—answer one question: can the agent complete the task? The answer is yes, with task success rates (TSR) between 88.3% and 97.6%.

ParanoiaEval's authors ask a sharper question: **does the agent know when *not* to act?

The question is grounded in 18,922 real developer sessions with coding agents. Using automated screening plus expert consensus, researchers distilled 5,574 over-defense snippets from 6,078 candidates, clustered into 44 recurring scenarios. The common trait: the agent keeps expanding defensive scope even after evidence has already determined how the risk should be handled.

Real scenarios:

Avoidance: the repo declares python_requires >= 3.10, yet the agent adds an AttributeError fallback for int.bit_count()

Transfer: CI already runs the full test matrix on every PR, yet the agent runs make test-all locally and adds a pre-commit hook

Mitigation: instructions say running pytest tests/test_utils.py is enough, yet the agent runs the full suite—three times

Acceptance: the user says this is the final version, yet the agent offers to roll back to pre1 and requests confirmation

Each behavior looks reasonable in isolation—who doesn't want safer code? Together they reveal the problem: the agent is not judging risk; it is executing the stereotype that defense equals responsibility.

The ATMA Framework: A Ruler Borrowed from NIST

ParanoiaEval's smartest design decision: instead of inventing a new framework, it borrows the ATMA risk-treatment framework from NIST IR 8286:

| Treatment | Meaning | Coding-agent example | |---|---|---| | Avoidance | eliminate the risk source | repo declares Python 3.10+, compatibility risk eliminated | | Transfer | hand risk to another responsible party | CI already runs the full tests | | Mitigation | reduce risk to an acceptable level | instructions say one test file suffices | | Acceptance | accept the risk, do nothing more | user says this is the final version |

Key insight: the four treatments are mutually exclusive and exhaustive. Given the evidence, any risk has exactly one correct treatment. Any extra work beyond that is over-defense. This unifies previously scattered concepts—action bias, over-editing, redundant steps, over-engineering—under one framework.

200 Task Pairs: Single-Fact Differences

ParanoiaEval builds 200 task pairs where each pair differs by exactly one fact.

E+ (with evidence): the repo declares python_requires >= 3.10; all test targets run on Python 3.10+ E- (without evidence): the repo adds a comment: these modules are copied verbatim into a tool still on Python 3.8

The task is identical: replace bin(o.subboxBitmap).count("1") with int.bit_count(). In E+, adding an AttributeError fallback is over-defense; in E-, it is justified. Both variants share the same oracle, reference patch, and repo version—the only difference is that one fact. If the agent still defends in E+, it either failed to read the evidence or chose to ignore it.

The 200 pairs span 50 open-source repos (34 Python, 16 Go), each pair independently reviewed by two experts.

Four Key Findings

1. Over-defense is universal and varies widely

All 8 tested configurations show over-defense. Violation rates (VR) range from 11.2% to 58.7%; evidence-response rates (ER) from 25.4% to 65.5%. Notably, Sonnet-4.6's low VR comes from rarely defending at all—even when it should—while Haiku-4.5 responds most strongly to evidence. Not defending and stopping when evidence says so are two different capabilities.

2. Task ability ≠ risk-handling ability

TSR and VR correlate at only Spearman 0.55 (p=0.17)—not significant. A better coder is not necessarily better at knowing when not to code. Risk handling is an independent capability dimension.

3. 92.7% of violating runs still pass functional tests

Functional metrics hide the problem. But humans notice: developer satisfaction drops by 1.27 points (5-point scale) for violating runs; direct acceptance is only 38% versus 78% for clean runs. Mitigation-type over-defense fares worst at 28% acceptance—developers most resent agents unilaterally expanding verification scope.

4. Agent failure modes mirror human risk management

Evidence-response rates differ by treatment: Mitigation and Acceptance reach up to 93.9%, while Avoidance and Transfer lag—because the former have explicit stopping points, while the latter's evidence is scattered across the repo (pyproject.toml, .github/workflows/). Within Mitigation, when instructions give an explicit magnitude boundary, agents stop; with vague boundaries, over-defense rises by up to 68.7 percentage points. Humans face the same dilemma: without explicit boundaries, "a little more" always feels safer.

Judge Design: Memory-Augmented Agent Reviewer

The evaluator is not simple LLM scoring but a memory-augmented agent judge:

1. The judge is a coding agent inspecting run trajectories in a read-only sandbox 2. It carries 64 human-annotated exemplar memories with task descriptions, condition roles, minimal sufficient actions, consensus labels, and rationale 3. At evaluation, 4 exemplars are retrieved by cosine similarity—including contrast pairs showing the boundary between necessary and excessive defense

On 200 held-out consensus labels, judge accuracy is 0.965 (Cohen's κ 0.93). Crucially, exemplar memory was frozen before validation, avoiding test-set contamination.

Engineering Takeaways

1. Paired-difference evaluation is reusable: any question of whether agents adjust behavior to evidence (user preferences, tool availability, verification depth) can use this paradigm—two variants sharing an oracle, differing in one fact. 2. No natural stopping point is a systemic weakness: give explicit magnitude boundaries in instructions ("run this one test file" beats "run tests"); grant agents an explicit "license to stop"; detect stop-point-missing scenarios in evaluation. 3. Functional correctness masks behavioral problems: add a behavioral-efficiency dimension to evaluation; VR and ER are directly reusable metrics. 4. ATMA is a reusable diagnostic framework: classify production anomalies as Avoidance failure (missed repo evidence), Transfer failure (unaware of CI), Mitigation failure (no stopping point), or Acceptance failure (disrespecting user decisions)—each needs a different fix.

Open Source

GitHub: https://github.com/ZhuoningXu/ParanoiaEval_release

Contents: 200 evidence-controlled task pairs, 50 repos, condition-specific instructions, answer cards, executable oracles, reference solutions, container configs, agent runners for Codex and Claude Code, and judge code. Full run trajectories are not included due to GitHub size limits.

Paper Info

Title: ParanoiaEval: Benchmarking Unnecessary Defensive Work in Agentic Coding

arXiv: 2610.08662

Code: https://github.com/ZhuoningXu/ParanoiaEval_release

Framework: ATMA (Avoidance-Transfer-Mitigation-Acceptance), from NIST IR 8286

Models tested: Claude Code (Opus-5, Sonnet-5, Sonnet-4.6, Haiku-4.5) + Codex (GPT 5.6-Sol, 5.6-Terra, 5.6-Luna, 5.5)

Scale: 9,600 runs + a 20-developer human study

---

One-line takeaway**: ParanoiaEval proves via 200 single-fact-difference task pairs that over-defense in coding agents is a capability dimension independent of task ability, masked by functional tests in 92.7% of violating runs. The fix is teaching agents to read evidence and respect boundaries—not simply making them more cautious or more aggressive.