Product1 distinct publisher3 min readPublished
Sonar's Hunter Agent goes after broken access control, business-logic and session-management flaws that the company says used to need manual testing. It reports through CI/CD, where gates have only held rule matches.
The Product Desk · Product desk
Compiled by The Product DeskSomething wrong?How this is made
Picture the first failing build. The pipeline stops on an account settings endpoint because a member role can change another member's email address: the role check runs after the write instead of before it. No rule fired on a dangerous function, because nothing in that code looks wrong on its own. The reviewer's first job is not fixing code, it is finding out whether anyone ever wrote down what that endpoint was supposed to allow.
Sonar's own framing draws the line honestly. Khasriya told devops.com that deterministic scanners are good at injection, unsafe data flows and insecure patterns, and that some vulnerabilities simply are not detectable in code [7]; a privilege escalation, he said, becomes visible only once you understand how the code is meant to function [8]. Hold the two lists side by side and none of the three categories Hunter targets is one the deterministic list covers [1]. That is a real coverage gap. It is also a gap most teams already had a line item for, because the same categories are the ones a penetration test was booked to cover [3].
The delta worth planning around is cadence and the cost of being wrong. A false positive from a rule engine is a suppression comment with a rule ID next to it. A false positive about intent is a conversation between a security engineer and the service owner about what the product is supposed to do, and the devops.com writeup carries no false-positive rate, no benchmark and no pricing to size that load with [11]. Attribution sharpens it further: the agent can name the developer who wrote the code [5], so a probabilistic finding arrives on a pipeline with somebody's name attached to it.
Two questions decide whether this belongs on a gate in your repo, and they make a serviceable grid. First axis: is the intended behaviour written down anywhere, in a role matrix or an authorization spec? Second axis: does a finding come with something a human can reproduce, a request that demonstrably does the thing it should not?
Written intent plus reproduction is the only cell where blocking a build is fair, because the argument is settled before the developer sees it. Reproduction without written intent belongs in an advisory queue routed to the service owner, and the useful output is a specification, not a patch. Written intent without reproduction is a design review on a weekly rhythm, not a pipeline event. Neither one, and a gate makes the security team the arbiter of undocumented behaviour, which is a slow way to lose the pipeline's credibility.
The urgency case rests on Khasriya's claim that exploitation windows have collapsed to hours [9], set against the older rhythm devops.com describes, where a team spent a few hours a month producing a patch that might not deploy for months [10]. Both can be true and still leave a team in the bottom-left cell of that grid. Where the answer to the first question is "nowhere", the honest early value of an agent like this one is a written account of what the application actually permits, and the gate comes later.
Ranked by verification strength, evidence, and original report placement.
Satinder Khasriya, a technical product marketing manager for Sonar, said that historically, discovering these issues would have required manual testing or a penetration test.
Sonar says the agent automates those investigations by tracing how code and data move through a system, and that investigations can be run on demand.
Khasriya said deterministic scanning tools are good for catching flaws that look wrong in the code, such as injection vulnerabilities, unsafe data flows and insecure patterns, but some vulnerabilities are not detectable in code.
Khasriya said a privilege escalation issue only becomes visible when there is an understanding of how the code is supposed to function.
Sonar made available SonarQube Hunter Agent, an AI agent designed to discover vulnerabilities and business logic flaws that pose the greatest risk to an organization if exploited.
SonarQube Hunter Agent first analyzes an entire codebase to find three categories of flaws: broken access control, business-logic vulnerabilities, and authentication or session-management issues.
Distinct publishers with included, body-backed reporting in this cluster.
1 article · August 27, 2026
Follow any of these and your For You feed starts watching them — no settings page required.
product
Half the incident clock goes to search, and telemetry tools cannot read the answer1 distinct publisher
product
OpenTelemetry is free; the collector fleet, the retention policy and the on-call rota are not1 distinct publisher
product
An agent gets risky at the moment its recommendation becomes an outbound call1 distinct publisher
product
AI writes the Dockerfile, and the pipeline is still checking the app code1 distinct publisher
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
Single-source vendor launch, no measurements
The only source is one trade article whose substantive claims all come from a Sonar product marketing manager. The launch itself and the described feature set are firsthand and credible, but there is no benchmark, no false-positive rate, no price, no named customer and no independent or adversarial testing, so detection efficacy is unverifiable from the supplied material.
Availability announcement only
The single observable adoption event is the product being made available. No deployments, design partners, customers, usage disclosures or pipeline integrations in production are evidenced, so adoption is at the floor of what a launch can establish.
Pen-test replacement framing outruns disclosed proof
The framing — an agent automating work that previously required manual testing or a penetration test, at machine speed against attackers who exploit within hours — is a strong efficacy and urgency claim, while the disclosed record contains no detection rate, no false-positive rate and no third-party evaluation. The threat-timing and legacy-patch-cadence assertions are uncited. The gap is moderate rather than extreme because the concrete capability description is specific and the vendor openly scopes the categories it targets as ones deterministic scanners do not cover.
Vendor launch narrated by vendor marketing
Every capability and urgency claim originates with a technical product marketing manager at the company selling the product, published in trade press on the day of availability, and the article closes with an argument that organizations must allocate more appsec resources — commercially aligned with the launch. No independent or opposing voice is present.
Launch facts firm, efficacy unresolved
Confidence is high that the product exists, targets the three named categories, attributes code to developers and reports through CI/CD, because those are directly reported. Confidence is low on everything that matters operationally — accuracy, noise, latency, cost, real deployments — because the cluster has one publisher, one vendor voice and zero measurements.