A software development agent uses Claude to autonomously write, test, and commit code changes. During a session, the agent writes a new authentication module, runs tests (all passing), and commits to the main branch. A security researcher later discovers the module contains a subtle timing attack vulnerability that passed all tests. The agent's action log shows it made 23 tool calls across 45 minutes before committing. What architectural safeguard should have prevented the autonomous commit to main?

Branch restriction is the correct architectural safeguard. Making direct commits to main architecturally impossible — by restricting the commit tool to feature branches only — creates a mandatory process gate: every code change must go through pull request, CI/CD, and code review before reaching main. This is not about the agent's capability to detect vulnerabilities; it's about enforcing the same process gates that human developers use. A timing attack vulnerability that evades automated testing is exactly the type of issue that needs human code review or specialized security tooling in a PR gate. Option A (pre-commit hooks) is a good defense layer but the claim that 'the scanner would have detected' a subtle timing attack is not reliable — timing attack detection in static analysis is notoriously difficult. Pre-commit hooks are also bypassable in some git configurations. Option C (security review agent) adds an AI security reviewer, but an AI reviewer of AI-generated code has the same blind spots — Claude reviewing Claude's timing attack vulnerability may miss it. Option D (human confirmation for all commits) is overly restrictive for an autonomous development agent — it defeats the autonomy purpose for low-risk changes and creates a bottleneck. Branch restriction with proper PR process is the industry-standard balance.