Why your AI coding agent keeps shipping code that technically works (but shouldn't)

A regular user ends up with admin rights. Nobody touched the database directly, nobody exploited a buffer overflow, nobody did anything a scanner would flag as "wrong." The code just... let it happen, because it ran exactly the way it was written.

That's the uncomfortable truth about most AI coding agent failures. It's rarely a syntax error or an obvious security hole. It's code that compiles, passes tests, and does precisely what the agent thought you wanted — except what you wanted and what got built were two different things. A checkout flow that can be skipped. A session that never expires. A permission check that's technically there but checks the wrong thing.

Traditional static analysis tools were never built to catch this category of problem, and that gap is exactly what Sonar's new Hunter Agent is designed to close.

Why can't your existing scanner catch these bugs?

Static analysis tools like SAST scanners are pattern matchers at heart. They're excellent at finding flaws that look wrong in the code itself — SQL injection, unsafe data flows, insecure patterns, the kind of thing where the vulnerable line of code has a recognizable shape. What they can't do is evaluate whether a piece of logic matches a business rule that exists nowhere in the codebase, only in someone's head or a product spec.

As Sonar puts it plainly: deterministic scanning is excellent at catching flaws that look wrong in the code, including injection vulnerabilities, unsafe data flows, and insecure patterns. However, some vulnerabilities aren't detectable in the code itself; they're visible only when you understand what the code is supposed to do. That's the whole problem in one sentence.

The examples Sonar uses to illustrate this are painfully familiar to anyone who's shipped a real product: a user who can view another customer's records, a checkout flow that can be skipped, or a session that doesn't expire the way it should — in these examples, the code technically runs exactly as written, but it permits something it was never meant to allow. No exception gets thrown. No test fails. The only way to catch it is knowing what the rule was supposed to be in the first place.

What actually goes wrong with agent-written code?

Ask around any engineering team using AI coding agents at scale, and the pattern is consistent. It's almost never "the model hallucinated garbage code." It's that the agent solved the literal problem it was given without the full context a human engineer would have picked up from three years of tribal knowledge about how the business actually works.

Sonar groups the recurring failure modes into three buckets, and they map almost perfectly onto what teams keep running into:

• Broken access control — IDOR bugs, missing or incorrect authorization checks, privilege escalation, sensitive data exposure, CSRF
• Business logic vulnerabilities — skipping required workflow steps, abusing repeatable actions, missing rate limits
• Authentication and session management flaws — broken auth, session fixation, sessions that never expire, weak password recovery, missing MFA, brute-force gaps

A single Playbook covers these three classes of vulnerabilities, and it does not ask a model a single question and wait for an answer. That distinction matters more than it sounds like it should.

How is Sonar's Hunter Agent different from a regular code review?

Here's where it gets interesting. Instead of turning an LLM loose on your repo and hoping it stumbles onto the right issues — which is basically what happens when you ask ChatGPT or Claude to "review this codebase for security issues" — Sonar built a structured process around it.

Hunter Agent works through structured multi-step analysis flows called Playbooks. A playbook, in Sonar's own words, is a curated, multi-step sequence of specialized security prompts that encodes Sonar's application security expertise. It's not freeform reasoning. It's a defined sequence: discovering endpoints, mapping the access control and authentication logic, reasoning about behavioral intent, verifying whether enforcement matches that intent, and finally confirming the issue.

That verification step is what separates this from a chatbot guessing at vulnerabilities. According to Sonar, every candidate issue is investigated and confirmed before a developer sees it, and no second tool is involved. The agent traces how data and identity actually move through your application rather than just pattern-matching against known bad code shapes. The agent works the way a human security researcher would, by tracing how code, data, and identity move through a system, then investigating and confirming each candidate issue before it ever reaches a developer.

That last part is the practical payoff: every finding is confirmed before it surfaces, so teams spend their time on real risk instead of sorting through noise. Anyone who's dealt with a pile of unverified SAST warnings knows how much time that alone can save.

Where do the findings actually show up?

This is the detail that makes it usable day-to-day instead of another tool nobody opens. Findings surface in your existing SonarQube workflow, tagged with "hunter-agent" for easy triage, with no new tool to learn. Broken access control, business logic gaps, and auth issues land as regular issues inside SonarQube Cloud, in the same queue your team already triages, assigns, and closes out.

The agent doesn't need to interrupt anyone's flow to do its job either. Because it runs in the background, on a set schedule or on demand, SonarQube Hunter Agent never blocks a pull request or slows down CI/CD. It's a standing capability rather than a one-time audit — turning what used to be a periodic audit into a standing capability rather than something you schedule a pentest for once a quarter and hope nothing changed in between.

How do you get access to it right now?

Sonar announced the general availability of SonarQube Hunter Agent, an AI-powered security agent built to catch high-impact vulnerabilities that traditional pattern-based scanning was never designed to find. The catch, for now: SonarQube Hunter Agent is generally available today for SonarQube Cloud, with support for SonarQube Server coming soon. And it's gated behind the top tier — the Hunter Agent is generally available today on SonarQube Cloud for Enterprise Plan, with support for SonarQube Server coming soon.

To get started:

1. Head to the SonarQube Hunter Agent product page to see what it covers and confirm your plan qualifies.
2. Check your current SonarQube Cloud plan — you'll need the Enterprise tier, since for critical, high-scale, or enterprise use cases, SonarQube Cloud also has an Enterprise plan with advanced features and annual pricing tailored to organizational needs.
3. Log into your SonarQube Cloud organization. Since the agent is now GA, enrollment happens directly in-product rather than through a waitlist.
4. Once enabled, let it run against a project with recent scan history — findings tagged hunter-agent will start showing up in your normal issues list.
5. Triage those findings exactly like any other SonarQube issue: assign, track, and resolve in the workflow your team already uses.

If you want to see how Sonar is thinking about the broader agentic development pipeline — not just after-the-fact detection but catching issues while the AI is still writing — it's worth also looking at SonarQube Agentic Analysis, which verifies code written by AI agents against your team's quality and security standards while the AI is still writing, so bugs get fixed in seconds — not hours later in code review. The Sonar Community announcement thread is also a good place to watch for Server support updates and real user feedback as more teams turn it on.

Should this change how you think about AI-generated code?

Probably. The uncomfortable part of all this isn't that AI agents write bad code — it's that they write code that's internally consistent and still wrong at the business level, and that's a category of bug your test suite was never designed to catch either. Sonar frames it well: the vulnerability classes that are hardest to catch automatically are exactly the ones that AI-generated code tends to get wrong, not because of a flaw in the AI, but because business logic correctness requires context that no code generator fully has.

That's not a reason to slow down on agentic coding. It's a reason to stop treating "the tests pass" as proof that the code is actually right. The next wave of AI tooling isn't just about writing code faster — it's about verifying that faster code still does what your business actually needs it to do. Worth checking whether your current review process is even looking for that kind of bug at all.