Sonar made SonarQube Hunter Agent generally available for SonarQube Cloud on August 27, 2026. The company describes it as an AI security agent that analyzes a full codebase for broken access control, business-logic errors, and authentication or session weaknesses that pattern-based static analysis may miss. SonarQube Server support is planned but was not generally available at launch.
The release matters because it moves an agent into a security-verification role. Hunter Agent does not merely generate code. It forms a theory about intended application behavior, investigates candidate flaws, and returns findings to the normal SonarQube issue workflow. That creates a second governance question alongside detection quality: how should a team validate, authorize, and audit an agent that judges whether software behavior is safe?
What Sonar released
Sonar says Hunter Agent can run on demand or on a schedule in the background. It examines how code, data, and identity move across a project, then focuses on three flaw classes:
- broken access control, such as one user reaching another user's records;
- business-logic defects, such as bypassing a required checkout step; and
- authentication or session problems, such as a session remaining valid too long.
Confirmed findings appear as SonarQube issues so development and security teams can triage and assign them with existing processes. The launch materials say the agent complements static application security testing rather than replacing it.
Sonar reports average precision of 80 to 90 percent after an internal validation stage. That figure is a vendor measurement. The cited materials do not provide a public independent benchmark, a full dataset, recall, false-negative rates, or a comparative evaluation across representative customer codebases. SiliconANGLE independently confirms the launch and the product's intended flaw classes, but it does not independently test the claimed precision.
The supplemental terms add an important deployment fact: Hunter Agent is an add-on for eligible SonarQube Cloud enterprise projects, with separate Server editions named for later support. Availability, supported repositories, commercial terms, and data handling should therefore be checked against current documentation.
Why an AI security reviewer needs its own controls
A security agent can improve coverage while also introducing a new decision path. It receives source code, infers intended behavior, chooses what to investigate, and decides which candidates deserve attention. A weak result may create two different consequences. A false positive consumes engineering time. A false negative may create unjustified confidence that a logic path is safe.
Teams should avoid treating an AI finding as either automatically correct or automatically untrustworthy. The useful model is evidence-assisted review:
- The agent proposes a finding with affected code and reasoning.
- A deterministic or human check confirms exploitability and scope.
- The owner records disposition, severity, and remediation.
- A later scan verifies that the intended effect was achieved.
That chain also needs a negative-result policy. "No issues surfaced" is not equivalent to "no issue exists." The evidence record should identify the version, repository scope, excluded files, supported languages, run configuration, and the control families still covered by other methods.
A practical deployment checklist
Before enabling a security agent across production repositories, teams can apply these controls:
- Inventory scope. Record repositories, branches, languages, integrations, permissions, scan cadence, and accountable owners.
- Classify source data. Determine whether code, configuration, secrets, customer logic, or regulated material can enter the service, then apply contractual and technical restrictions.
- Set identity boundaries. Give the agent only the repository access needed for analysis. Separate read access from any remediation or pull-request capability.
- Define evidence requirements. Require an exact file and line, an explanation of the violated behavior, a reproducible path, and a confidence or validation state.
- Route by consequence. High-impact access-control or authentication findings need named security review. Low-risk candidates can follow the normal backlog.
- Measure both directions. Sample surfaced findings for precision and seed or retain known flaws to test recall. Track misses, not just accepted issues.
- Verify remediation. Re-run the relevant check and preserve the result rather than closing an issue solely because code changed.
- Review product change. Reassess the control when the agent, model, supported language, terms, or repository integration changes.
Maetra's guide to monitoring AI agents for risky behavior describes runtime evidence and ownership. The AI agent inventory checklist helps record the new security agent and its connected capabilities.
What remains uncertain
The launch establishes general availability for SonarQube Cloud, not effectiveness in every environment. Public sources do not establish how performance changes by language, architecture, repository size, code quality, or application domain. They also do not show how often a logic flaw requires business context that is absent from the repository.
Sonar says every surfaced finding is independently validated before it reaches a developer. The public material does not fully describe whether that validation is deterministic, model-based, human-assisted, or a combination for every finding. Buyers should verify that process and the evidence exposed to reviewers.
Maetra analysis
Hunter Agent illustrates a broader shift: agents are becoming participants in the software assurance process, not only producers of software. That can be valuable, but assurance cannot rest on a single agent's conclusion. Teams need an inventory of the reviewer, bounded access, traceable findings, independent confirmation for material defects, and effect verification after remediation.
The right question is not whether AI can find logic flaws. The launch shows that vendors are productizing that task. The governance question is whether a team can explain what the agent examined, what it missed, why a finding was accepted, and whether the repair actually changed the intended security outcome.