The SonarQube Remediation Agent now fixes Hunter Agent findings

In August, SonarQube Hunter Agent became generally available on SonarQube Cloud, giving teams a way to find the security flaws that pattern-based analysis misses. Broken access control, business logic flaws, and gaps in authentication and session handling now show up as SonarQube issues, and each one is checked before it is raised.

Finding them was half the job. Each finding still waited for someone to write the fix.

The SonarQube Remediation Agent now takes on that second half. On SonarQube Cloud, you can send Hunter Agent findings from your main branch to the agent and get each fix back as a pull request. Hunter Agent finds the flaw. The Remediation Agent proposes the change. Your team decides what merges.

Why are logic flaws harder to fix than other issues?

A logic flaw is not a broken line of code. The code runs exactly as written. The problem is what it lets someone do.

Take a classic case. An endpoint returns an invoice by its ID and never checks that the invoice belongs to the caller’s organization. Any signed-in user can read another customer’s invoice by changing a number in the URL. There is no injection and no unsafe call. Nothing in the code matches a known bad pattern.

The fix is rarely long, but it is hard to get right. You need to know how your application identifies the caller, where ownership lives in your data model, and how the rest of the codebase already enforces it. Get that wrong and you either leave the hole open or break a legitimate workflow. So these findings often wait for whoever knows the access model best.

How does the Remediation Agent fix a Hunter Agent finding?

It starts from a finding that has already been checked. Hunter Agent tests each candidate to rule out false positives. It then raises the finding as a vulnerability with a severity, an exact location in the code, and an explanation in two parts: why it is an issue, and how to fix it. The Remediation Agent works from that finding and from your full repository, not just the lines that were flagged.

The workflow is the one your team may already use for backlog fixes:

1. Open your project’s Issues page and select the main branch.
2. Turn on the Fixable by Agent filter. Eligible Hunter Agent findings appear alongside your other fixable issues. To see only Hunter Agent findings, add the hunter-agent tag, or a category tag such as hunter-broken-access-control.
3. Select the findings you want fixed, up to 20 at a time, and choose Fix with Agent.
4. Follow the run on the Remediation Agent page.
5. When a fix is available, open the linked pull request, review it, and merge it.

The agent generates each change through your organization’s own OpenAI or Anthropic key, and verifies the proposed change before it opens a pull request.

Why does each finding get its own pull request?

For rule-based issues, the agent groups the fixes you assign by rule key and file type. Hunter Agent findings are handled differently. Each finding gets its own pull request, or merge request on Github, when a fix is available.

That fits security work. One pull request maps to one finding. As with other backlog fixes from the agent, the pull request summary describes the issue it addresses in the same format you see in SonarQube. A reviewer can judge an access control change on its own, without untangling it from five others. If one fix needs a longer conversation, it does not hold the rest back.

What does a fix for a logic flaw look like?

Here is the invoice example from earlier, simplified:

@GetMapping("/invoices/{id}")
public Invoice get(@PathVariable Long id) {
    // Returns any invoice by ID. Nothing checks the caller's tenant.
    return invoiceRepo.findById(id).orElseThrow();
}

Hunter Agent flags this kind of code as an authorization bypass through a user-controlled key (CWE-639). A good fix scopes the lookup to the caller, so the endpoint can only return invoices the caller is allowed to see. In a Spring application, it could look like this:

@GetMapping("/invoices/{id}")
public Invoice get(@PathVariable Long id,
                   @AuthenticationPrincipal AppUser user) {
    // Only returns the invoice if it belongs to the caller's tenant.
    return invoiceRepo.findByIdAndTenantId(id, user.getTenantId())
        .orElseThrow(() -> new ResponseStatusException(HttpStatus.NOT_FOUND));
}

Illustrative example. Not output from the agent.

What the example shows is what any fix depends on: how your application identifies the caller, and where tenant ownership lives. That knowledge is spread across your codebase, which is why the agent works from the full repository and not just the flagged method. Returning 404 rather than 403 also avoids confirming that the invoice exists.

What happens after the pull request opens?

From here, it is a normal pull request. Your branch protection rules, required reviewers and status checks all apply. The agent never merges anything itself.

If you use GitHub Actions, the agent also follows up on CI. When CI fails on one of its pull requests, it reads the build logs, pushes a new commit to address the failure, and waits for CI to run again. It tries up to three times and records each attempt in the pull request description. If CI still fails, it stops and leaves the pull request open for a developer.

Which programming languages are covered?

For rule-based issues, the Remediation Agent covers maintainability, reliability and a select set of security issues in C#, Java, JavaScript, TypeScript and Python, and it can also fix detected secrets. That language list does not apply to Hunter Agent findings. Hunter Agent works with any language SonarQube Cloud supports, and its findings are eligible for a fix whatever the language, as long as they meet the requirements below.

What do I need to get started?

On SonarQube Cloud, you need:

• A Hunter Agent subscription on the Enterprise plan, to generate findings.
• Sonar Agent Essentials, to request fixes.
• An organization admin to enable Manual backlog remediation and add an OpenAI or Anthropic API key. The agent runs on that key, so model usage is billed to your provider account.
• A private project bound to GitHub, GitLab.com or Azure DevOps.
• The agent connected to your repositories. On GitHub, an administrator installs the SonarQube Agent app. GitLab.com and Azure DevOps reuse your existing platform token, and on GitLab.com that token needs the api scope and at least the Maintainer role.
• Findings on the main branch, with a status of Open, Confirmed or Accepted.

To generate a fix, Sonar sends the affected code to your model provider under your own account, so your provider’s terms govern how that data is handled.

Three things to note:

• The agent might not find a fix for every finding. A run without a fix does not by itself mean setup failed, and the finding stays in your issue list for a developer.
• CI follow-up works with GitHub Actions only. With other CI providers, SonarQube Cloud detects the failure but cannot read the logs it needs.
• Backlog fixes, including fixes for Hunter Agent findings, run on the main branch only.

Is this available on SonarQube Server?

Yes. SonarQube Server 2026.5 also lets you hand Hunter Agent findings to the Remediation Agent, with both agents running on infrastructure you deploy.

Find it and fix it in the same loop

Hunter Agent and the Remediation Agent sit at two ends of the same cycle. Hunter Agent verifies: it finds flaws that never showed up as patterns. The Remediation Agent solves: it turns those findings into changes your team can review. Without a link between them, a person has to carry every logic flaw from one end to the other. With it, the agent drafts the fix, and your team keeps the decision that matters, which is what ships.

To get started, see Fixing Hunter Agent findings in the SonarQube Cloud documentation, or talk to your Sonar account team about Hunter Agent and SonarQube Remediation Agent.