Why your AI coding agent keeps shipping security holes (and the fix that actually works)

Ask an AI coding assistant to build a login form and it will hand you something that works in under a minute. Ask it whether that login form is safe from a SQL injection attack, a broken access control flaw, or a leaked secret sitting in a config file, and things get a lot less certain. The code runs. It looks clean. It passes every manual glance-over. And it can still be dangerously insecure.

That gap between "the code works" and "the code is safe" is where most AI coding workflows fall apart right now. Almost nobody is building a system that actually catches this before it ships — they're just trusting the agent, or worse, asking a second agent to "review" the first one's work and calling that security.

This guide breaks down why AI-generated code keeps introducing vulnerabilities, and lays out a workflow that treats security scanning as a mandatory gate instead of an optional opinion.

Why does AI generated code keep shipping with security holes?

Two things make this worse than most developers expect. First, coding agents pull in third-party packages constantly, and they don't always vet what they're pulling. A dependency that looks legitimate can carry a vulnerability, an outdated version with a known CVE, or in rarer cases a package that doesn't even exist and gets hallucinated into the code entirely.

Second, agents are optimized to produce something that looks finished — code that compiles, passes the obvious test, and satisfies the prompt. They are not optimized to think like an attacker. An agent asked to build a file upload feature will build one that accepts files. It usually will not stop and ask whether an attacker could upload an executable disguised as an image, or whether the endpoint needs rate limiting to prevent abuse. That kind of thinking has to be forced into the process, because it doesn't show up on its own.

What's wrong with having one AI agent review another agent's code?

This is the trap a lot of teams fall into. It feels like a solution — spin up a second agent, tell it to "review this for security issues," and treat its approval as a green light. But an LLM reviewing another LLM's output is still just an opinion. It's non-deterministic. Run the same review twice and you can get two different answers. There's no guarantee it catches a specific vulnerability class, and there's no audit trail that satisfies a compliance requirement.

What you actually need is a step in the pipeline that can't be talked past — a deterministic check that either passes or fails based on fixed rules, not a chat response that sounds confident.

What does a security-first AI coding workflow actually look like?

The setup that works combines two very different tools, each doing a job the other can't. One tool runs the workflow itself — the planning, the implementation, the pull request. The other tool acts purely as the gatekeeper that decides whether the work is actually safe to ship.

Archon is the workflow engine. Archon is an AI workflow engine for coding agents that lets you define your development processes as YAML workflows — planning, implementation, validation, code review, PR creation — and run them deterministically across all your projects. Think of it like what a Dockerfile does for infrastructure or what GitHub Actions does for CI/CD, except applied to how your AI agent actually does its job. It's the first open-source harness builder for AI coding, doing for AI coding workflows what Dockerfiles did for infrastructure and GitHub Actions did for CI/CD.

The security gate is SonarQube. AI assistants can be inconsistent, but static code analysis is deterministic — SonarQube provides independent verification of AI-generated code, flagging defects, security vulnerabilities, and correctness issues early in pull requests. That determinism is the entire point. It doesn't matter how confident the agent sounds about its own code. Sonar runs the same rules every time and returns the same verdict every time.

How does Sonar actually decide if the code passes?

SonarQube runs static application security testing against a defined rule set, and it doesn't budge on that rule set no matter how the code was written. It runs advanced SAST and taint analysis for AI code, with automated scanning that highlights vulnerabilities, risky data flows, and defects early in pull requests. That includes things like SQL injection, insecure deserialization, and cross-site scripting patterns that agents tend to reproduce without noticing. SonarQube detects vulnerabilities like SQL injection, deserialization, and XSS so code meets your security standards.

There's a specific feature worth setting up if you're running an AI-heavy pipeline: AI Code Assurance. SonarQube Cloud's AI Code Assurance features help you set appropriate standards for projects containing AI-generated code, using a combination of tools including project labels, a default quality gate, and externally published project badges. The logic behind it is straightforward — Sonar recognizes that AI-generated code should be monitored with additional quality standards, with recommended checks including high standards to reduce code complexity, remove bugs, and eliminate injection vulnerabilities. In other words, code coming out of an agent gets held to a stricter bar than code a human wrote by hand, not a looser one.

You can find the setup details in Sonar's AI Code Assurance documentation, which walks through configuring the quality gate and quality profile for AI-flagged projects.

How do you connect the agent to the scanner directly?

The cleanest integration doesn't route security feedback through a chat window — it wires the scanner straight into the agent's tool access. Connect SonarQube MCP Server directly to AI agents like Cursor, Claude, and Windsurf via the Model Context Protocol to provide real-time, governed feedback inside the AI's conversational flow. That means the coding agent can query real scan results as part of its own loop, rather than waiting for a human to paste in a report.

This also works well inside a scripted pipeline rather than an interactive chat. Connect the SonarQube MCP Server if you're using an AI assistant that supports Model Context Protocol, and you can ask the agent to scan code against your project rules or fix a specific complexity issue, with the agent pulling findings from your hardened profile.

What happens when the scan finds something?

This is where the workflow earns its keep. The agent doesn't get to decide for itself that the code is "probably fine." When Sonar's quality gate comes back red, the workflow routes straight back into a fix step — the agent reads the specific findings, addresses each flagged issue, and the code gets rescanned. Only when every check comes back green does the pull request actually get created. Nothing moves to human review while red items are still open.

That structure matters because it removes the option to skip the step. An agent working solo can talk itself into shipping something. A workflow engine enforcing a hard gate cannot be talked into anything — it either sees green or it doesn't, and Archon's model of encoding development processes as YAML workflows with planning, implementation, validation, review, and pull request phases means agent runs follow a deterministic structure rather than an improvised one.

Can you run this across multiple issues at once?

Yes, and this is one of the more useful parts of running workflows through Archon instead of a single chat session. Git worktree isolation means every workflow run gets its own worktree, so you can run five fixes in parallel without one agent's changes stepping on another's. Practically, that means you can point the same secure workflow at issue 79, issue 82, and a new feature branch simultaneously, and each one goes through planning, implementation, the Sonar gate, and PR creation independently.

The coding agent handles workflow selection, branch naming, and worktree isolation for you, and projects are registered automatically the first time they're used, so scaling this up across a repo doesn't require rebuilding the pipeline for every new task.

How do you actually get started?

1. Install Archon from the official GitHub repo and follow the setup wizard rather than improvising an install path — official getting started guidance recommends cloning the GitHub repository and using the guided setup wizard rather than undocumented install paths.
2. Define your workflow as YAML under .archon/workflows/, covering planning, implementation, validation, review, and PR creation as separate steps.
3. Set up a SonarQube project using SonarQube Cloud or SonarQube Server depending on whether you want a hosted or self-managed setup, and enable AI Code Assurance following Sonar's documentation.
4. Connect the SonarQube MCP Server to your coding agent so scan results feed directly into its tool calls instead of a manual copy-paste loop.
5. Wire the quality gate into the workflow as a required step — configure it so a red gate routes back to a fix step automatically, and a green gate is the only path to PR creation.
6. Kick off a run by pointing the agent at a specific issue number and letting the workflow handle planning, implementation, scanning, and PR creation end to end.

What should you take away from this?

The uncomfortable truth is that speed and safety were never the same problem, and AI coding agents only solved the first one. Adding a second AI agent to "review" the first doesn't close that gap — it just adds another opinion to a system that already has too many. What actually closes it is a deterministic gate that doesn't care how confident the agent sounds, doesn't skip steps under pressure, and doesn't let a pull request through until the code is provably clean.

Every team shipping AI-generated code at any real volume is going to need something like this eventually. The only question is whether it gets built in now, or after the first breach forces the issue.