AI coding tools have broken the old review pipeline. Across 22,000 developers, Faros AI found median PR review time up 441%, with 31% of PRs now merging with zero human review. The code ships faster, but the checkpoint that caught bad code is gone.
That leaves you in a bind. Ban the tools and you push people into shadow AI; let them run and you hand risk decisions to whoever merges fastest. Adding reviewers doesn’t help; the volume has outgrown the humans. The useful question: where does the fix belong, in the model, the tool, or the platform? Settle that and you have a governance model for this series on AI coding tools security that keeps velocity without trusting the model’s best guess.
Manual Code Review vs AI-Assisted Code Review: Where Does Human Judgment Still Win? #
Human judgment still wins on security-critical changes, business-logic intent, novel exploit patterns, and architectural calls, because only a person can reconstruct what the code was meant to do. AI-assisted review wins on scale: it triages high-volume, low-risk diffs and reliably flags injection, secrets, and known CVEs. That’s the division you should draw.
Both extremes fail right now. Developers rubber-stamp roughly 97% of permission prompts in Claude Code, yet 31% of PRs merge with no human review at all. So the human gate is either on autopilot or absent. Shipping speed and security outcomes have diverged, and the data points the same way: more code, bigger PRs, and a review queue that broke, not grew. Your most experienced engineers end up reconstructing intent rather than checking implementation.
AI review carries a blind spot too. Models sometimes hallucinate package names that don’t exist, and they can claim a fix is secure with false confidence. AI review should support a human, not replace one.
Before you adopt an AI review tool, benchmark it on your own codebase: precision and recall against real PRs, the false-positive rate, and language and stack coverage, not vendor benchmarks. Tools trade precision for recall, so measure them by delivery outcomes before you buy.
How Do You Evaluate an AI-Assisted Development Policy Between Banning Tools and Unrestricted Use? #
The workable policy is a risk-tiered spectrum with an allow-list, mandatory human review on security-sensitive paths, and blocked secrets and data egress. Start restrictive and expand only as telemetry proves safe use.
A ban forfeits productivity and drives developers to shadow AI, where unapproved tools run without oversight. Most organisations already lack visibility into how and where AI is used, so a ban makes that blindness worse. Unrestricted use hands those risk decisions to developers merging code without understanding the licensing or security implications.
A tiered policy covers three lines: an allow-list of approved tools, models, and versions; human review required on security-sensitive paths; and a clear boundary on what agents may read, send, and commit, with secrets and data/IP egress blocked in the pipeline.
The 97% approval rate shows the prompt gate already failing. Auto-mode removes it, so it deserves explicit treatment. Anthropic made Claude Code’s auto-mode the default for paid plans in August 2026. Anthropic’s testing shows auto-mode catches more dangerous commands than manual review, but the classifier still misses some. Supervision is only one control: agents exploit that trust, and slopsquatting and agentic supply-chain governance sits beyond any prompt-level guard.
A written policy is only as good as the layer that enforces it, which points to the model, the tool, and the platform.
How Do You Decide Whether the Security Fix Belongs in the Model, the Tool, or the Platform? #
Ask three questions in order. Can the model fix it through training or a safety classifier? Can the tool enforce it deterministically at the point of generation? Or can only the platform guarantee it as a pipeline gate? That’s the model-tool-platform security question: the answer is distributed, but enforceable only at the platform.
The model layer can improve but stays probabilistic. OpenAI’s GPT-5 series raised its security pass rate to around 70 to 72%, which still leaves roughly 30% of generated code flawed. Anthropic’s classifier still misses 11% of dangerous actions. You can layer them, but not lean on them alone.
The tool layer is where deterministic guardrails and reusable skills live. The principle: give the agent a fixed, repeatable step instead of improvising a check. Red Hat’s prodsec-skills packages more than 130 machine-readable security skills the model or tool can invoke, and open-source tools like Anti Slop and RapiDAST add pull-request grading and API red-teaming for free. In one Endor Labs benchmark, an agent with compact, deterministic context used 91.7% fewer tokens and 4.5x fewer tool calls than an LLM doing the same checks.
The platform is the enforceable backstop. It owns pipeline gates, CI/CD policy, containment, egress controls, and provenance. In Anthropic’s red-team testing of one scenario, a phished prompt exfiltrated credentials in 24 of 25 retries; the only defence that held was environment-level egress controls. Prefer deterministic tool and platform fixes for anything security-critical, and keep the model behind them.
Because the platform is where policy becomes enforcement, modernisation starts there: shore up security posture first, then layer DevOps and AI capability on top. Governance before acceleration.
Where this lands #
The two failure modes share one root cause: the human gate can’t scale to AI-assisted volume, so the gate has to move to where it can be enforced. Policy is the control surface; only the platform turns it into an enforceable pipeline gate. For every failure, ask which layer owns it and whether you can enforce it there. That question, repeated, is the governance model. The AI coding tools security hub holds the rest of the architecture.
Frequently Asked Questions #
Do we have to review every line of AI-generated code?
No. Line-by-line review of everything is exactly the checkpoint that has already collapsed, with 31% of PRs merging with zero human review. Use risk-tiered review instead. Let AI triage high-volume, low-risk diffs and flag common issues like injection and secrets, then route security-critical changes, business-logic intent, and architectural decisions through mandatory human review. The goal is a gate you can actually enforce, not total manual coverage.
What is shadow AI, and why does banning tools make it worse?
Shadow AI is the unsanctioned use of AI tools outside your approved policy, and a ban makes it worse because developers route around the restriction to keep their speed. The organisation then loses visibility into what tools are used, what they read, and what they commit. A restrictive, risk-tiered policy with an allow-list is safer than a ban because it keeps the activity visible and governable.
Can AI coding tools hallucinate a security fix?
Yes. An AI coding tool can hallucinate a dependency, invent a package or API that does not exist, and assert a fix is secure with false confidence. That is why the model’s own assurance is not an enforceable control. Validate generated dependencies against a registry and route security-critical changes through deterministic tool or platform checks rather than trusting the model’s word.
How do I stop AI coding tools from leaking secrets or source code?
Stop it at the platform, not the prompt. Block secrets and data/IP egress in CI/CD policy, define exactly what agents may read, send, and commit, and run deterministic secret scanning at the point of generation and again in the pipeline. Model-level training reduces leaks but is probabilistic, so egress controls and scanning in the platform are the enforceable backstop.
What should go in an allow-list for AI coding tools?
An allow-list should name approved tools, models, and versions, plus the repositories and data they may touch. Start restrictive: approve a small set of vetted tools whose language and stack coverage matches your codebase, block unapproved models, and pair the list with mandatory human review on security-sensitive paths. Expand it only when telemetry shows the approved set being used safely.
Which security fixes should never be left to the model layer?
Never leave fixes that need a guarantee to the model alone. The model layer is probabilistic: OpenAI’s GPT-5 series still leaves roughly 30% of output flawed, and Anthropic’s classifier still misses 11% of dangerous actions. Secrets, injection, egress, and pipeline enforcement belong in deterministic tool or platform controls, with the model sitting behind them as a probabilistic layer.
What is a security skill in an AI coding tool?
A security skill is a reusable, machine-readable capability that the model or tool can invoke at the IDE or CLI boundary, rather than a one-off prompt. Red Hat’s prodsec-skills, with more than 130 skills, packages security checks as repeatable steps. The value is determinism and reuse: the same security logic runs the same way every time instead of living inside a prompt.
How do I know our AI governance is actually working?
Measure the two failure modes, do not assume the policy is working. Your governance is effective when security-critical changes still get a human gate, secrets and egress are blocked deterministically, and telemetry shows approved tools used on the paths you intended. Watch for the 97% rubber-stamp rate and the 31% zero-review gap, and audit continuously, expanding permissions only as the data proves safe use.
What is slopsquatting, and why does it matter for AI coding governance?
Slopsquatting is an AI supply-chain attack where malicious or junk packages are built to be suggested by AI coding tools, tricking the model into recommending a dependency that compromises your code. It matters because the model layer cannot reliably distinguish these packages, so the fix belongs in the platform: registry allow-lists, provenance checks, and pipeline gates that block unvetted dependencies before they merge.
Can I just add more human reviewers instead of moving the gate to the platform?
No. Adding reviewers does not fix the root cause, which is that the human gate cannot scale to AI-assisted volume. More humans just get pushed into rubber-stamping, which is the 97% prompt approval problem. Move the gate to where it can be enforced: deterministic tool and platform checks for security-critical paths, with human judgment reserved for intent, context, and novel risk.