CLAUDE CODE AGENTS: ADVANCED ORCHESTRATION - Chapter 5, Exercise 1
Why Edit Access Matters Even More for a Security Reviewer
====================================================================================

QUESTION:
Explain why a security review agent is denied Edit access with even more
emphasis placed on this than for a general code-review agent, using this
chapter's own reasoning.

SOLUTION / EXPLANATION:

Fundamentals' Chapter 6 already established the general reasoning for
denying a review agent Edit access: keeping the act of finding a problem
separate from the act of fixing it, so the review stays honest and
complete, and so the reviewer can't quietly patch something instead of
reporting it.

This chapter states that isolation matters even more specifically for a
security review agent, and the reason follows directly from what's at
stake: security-sensitive code (authentication logic, authorization checks,
handling of secrets or personal data) is exactly the code where an
unreviewed, unintended change carries the highest possible cost. If a
security review agent had Edit access and quietly modified security-
sensitive code while reviewing it - even with good intentions, attempting
to fix what it found - that change would itself be an unreviewed
modification to precisely the part of the codebase where mistakes are most
dangerous, with nobody having explicitly reviewed or approved it as its own
step.

General code review already benefits from the fixing/finding separation,
but a mistake in, say, a documentation fix carries far less risk than a
mistake in an authentication check. Because security-sensitive code is
disproportionately dangerous to get subtly wrong, guaranteeing - by
construction, through the lack of Edit access - that the review agent
cannot make any change to it at all is a stronger, more important
guarantee here than it is for general-purpose review, even though the
underlying reasoning (separating finding from fixing) is exactly the same
principle in both cases.

--------------------------------------------------------------------------
WHY THIS WORKS AS AN ANSWER:
It starts from the shared general-review reasoning (Chapter 6) and explains
specifically why the stakes are higher for security-sensitive code
particularly, making the same isolation guarantee more consequential here
rather than treating it as an unrelated, separate rule.