# Securing AI-Generated Code: Why Deterministic Gates Beat Agent Review > Source: > Published: 2026-09-10 00:00:00+00:00 # Securing AI-Generated Code: Why Deterministic Gates Beat Agent Review AI coding agents miss security flaws constantly. Here's how deterministic gates using tools like SonarQube catch vulnerabilities before pull requests open. ## Why does AI-generated code have so many security problems? AI coding agents introduce vulnerabilities in two main ways: they write insecure code directly (think SQL injection patterns), or they pull in third-party dependencies that carry known vulnerabilities. Neither problem is rare. Agents rarely check whether a package they just installed has a documented CVE (Common Vulnerabilities and Exposures), and they almost never trace the dependency chain far enough to catch a vulnerability buried two or three layers deep in a sub-dependency. The core issue is scale. The list of known vulnerability patterns is enormous, far too large for any model to hold in context and check against on every task. Add to that the fact that training data includes plenty of human-written code that already cut security corners, and you get agents that reproduce the same bad habits. Sometimes an agent even notices a problem and mentions it in a pull request description as a “follow-up,” but the fix never actually happens and the vulnerability ships anyway. ## TL;DR - **Coding agents introduce vulnerabilities two ways** : writing insecure code directly, or installing third-party packages that already contain known CVEs, often buried in sub-dependencies the agent never inspects. - **Using a second AI agent as a security reviewer feels like a fix but isn’t reliable** , because it’s still a probabilistic process that can miss exactly what the first agent missed. - **A deterministic gate means running an actual scanning tool, not an agent’s judgment, as the pass/fail check** before a pull request is allowed to open. - **SonarQube can be called directly inside a coding workflow** to scan a pull request’s changes against known vulnerability patterns and return a structured report. - **The workflow pattern is: classify the issue, plan or investigate, implement, scan, force the agent to fix anything flagged, scan again, and only then open the PR.** - **The scan step should run as a script call, not an agent call** , so the check itself is guaranteed to happen the same way every time, even though fixing the issues still involves an agent. - **This approach doesn’t promise zero vulnerabilities** , it promises that a consistent, repeatable check happens before code reaches review, which is a meaningfully different guarantee than hoping an agent remembers to be careful. ## Seven tools to build an app. Or just Remy. Editor, preview, AI agents, deploy — all in one tab. Nothing to install. ## Why doesn’t just adding a “review agent” solve this? The obvious fix, once you notice your AI-generated code has security gaps, is to add another agent whose job is to review the pull request for vulnerabilities before merging. This is a reasonable starting point and worth doing. It is not, however, a solution on its own. The problem is structural. If the agent that implemented the feature glossed over a security issue, whatever caused that gap (missing context, a training bias toward speed, an incomplete mental model of the codebase) doesn’t disappear when a second agent looks at the same code. You’ve just added another probabilistic pass on top of the first one. It’s entirely possible to end up with a pull request that “looks green” after an AI review while the underlying vulnerability is still sitting there untouched. Non-deterministic review can catch things. It’s useful as a layer. But it cannot be the only layer, because nothing about it guarantees consistent detection against the actual universe of known vulnerability patterns. ## What is a deterministic gate in an AI coding workflow? A deterministic gate is a checkpoint in the pipeline that runs the same way every single time, using a tool built specifically for vulnerability detection rather than an agent’s own judgment. Instead of asking an agent “does this code look secure to you,” the workflow calls an actual scanning engine, gets a structured pass/fail result back, and only allows the process to continue once the scan comes back clean. The distinction matters. An agent reviewing code is inference: it’s guessing, pattern-matching, and subject to the same blind spots as the agent that wrote the code. A scanning tool checking against a known list of CVEs and vulnerability signatures is verification: it either finds a hardcoded password or it doesn’t, it either flags an outdated dependency with a known exploit or it doesn’t. That result doesn’t vary based on how the prompt was worded or what the model happened to focus on that session. The gate doesn’t replace the agent. It constrains it. If the scan comes back with issues, the workflow routes that report back into the agent and forces another iteration. Only when the scan comes back clean does the workflow allow a pull request to open. ## How does this look in practice with a tool like SonarQube? One concrete implementation pairs an orchestration layer (in this case, an open-source workflow builder called Archon) with SonarQube, a platform built for static code analysis and vulnerability detection. The workflow structure looks like this: 1. A GitHub issue comes in and gets classified as a bug or a feature. 2. The agent plans (for a feature) or investigates (for a bug). 3. The agent implements the change and opens a draft pull request. 4. A script, not an agent, calls the SonarQube API to scan the pull request’s changes against known vulnerability patterns. 5. The scan report gets fed to an agent, which is instructed to address anything flagged as a problem. 6. The workflow scans again to verify the fixes actually resolved the flagged issues. 7. Only when the scan comes back green does the pull request get marked ready and control return to a human reviewer. ## Other agents start typing. Remy starts asking. Scoping, trade-offs, edge cases — the real work. Before a line of code. The key design choice is step 4: the scan runs as a script call using the SonarQube API, not as another agent task. That’s what makes it deterministic. The report that comes back includes specifics, for example flagging a potentially hardcoded password and linking that pattern to its associated CVE history, so the agent iterating on the fix has concrete detail to work with rather than a vague “check for security issues” instruction. This can also run inside standard CI pipelines rather than inside an agent workflow. The advantage of wiring it directly into the coding workflow is that the scan report gets automatically routed back to the agent for iteration, instead of just failing a CI check that a human then has to interpret and hand back to the agent manually. ## Is this approach guaranteed to catch every vulnerability? No, and it’s worth being direct about that. A deterministic gate guarantees that a consistent check happens, using a defined list of known vulnerability patterns, every single time a pull request is prepared. It does not guarantee that every possible security flaw gets caught. Scanning tools work against known CVEs and established vulnerability signatures. Novel issues or logic-level security flaws outside that scope can still slip through. What changes is the reliability of the baseline. Instead of hoping an agent (or a second review agent) happens to catch a hardcoded credential or an outdated dependency, you know that specific class of check ran and passed before the code reached a human. That’s a meaningfully stronger floor than relying entirely on agent judgment, even if it isn’t a ceiling. ## Do you need Archon and SonarQube specifically to do this? No. The pattern matters more than the specific tools. Any coding pipeline can add a deterministic gate as long as there’s a way to call a real scanning tool as a script or API step, feed its output back to the agent doing the fixing, and block the pull request from opening until the scan passes. SonarQube is one option for the scanning layer because it’s built specifically for vulnerability and code quality detection. Archon is one option for the orchestration layer because it lets you wire scanning steps directly into an agent pipeline as reusable nodes. Teams using different tools can apply the same structure: classify, plan, implement, scan with a real tool, force iteration on anything flagged, re-scan, then open the PR. ## Frequently Asked Questions ### What is a CVE and why does it matter for AI-generated code? CVE stands for Common Vulnerabilities and Exposures, a documented list of known security flaw patterns. It matters because AI coding agents frequently install third-party packages without checking whether those packages, or their sub-dependencies, have documented CVEs against them. ### Why isn’t using an AI agent to review another agent’s code enough? Because it’s still a probabilistic process. If the implementing agent missed a security issue due to a blind spot or context gap, a second reviewing agent is prone to the same kind of miss. It adds value as a layer but can’t serve as the only vulnerability check. ### What makes a security check “deterministic” instead of just another AI step? A deterministic check calls an actual scanning tool via script or API rather than asking an agent to use judgment. The tool checks code against defined vulnerability patterns and returns a consistent, structured result every time, rather than a result that varies with prompting or model behavior. ### Does adding a deterministic gate slow down the coding workflow? It adds iteration cycles when vulnerabilities are found, since the agent has to fix flagged issues and the scan has to run again before the pull request opens. That tradeoff is generally worth it compared to merging code with undetected vulnerabilities. ### Can this workflow be built without a dedicated orchestration tool? Yes. The same pattern, scan after implementation, feed results to the agent, force fixes, re-scan, then open the PR, can be run manually between coding agent sessions or wired into standard CI pipelines using a scanning tool’s existing API.