Notifications
Clear all
Topic starter
02/08/2026 12:31 pm
TL;DR: Its private beta data showed Assistant marked 230 findings as likely false positives, with 95% of recorded responses agreeing and true positives 1.5x more likely to be fixed, while false positives were 2.2x more likely to be ignored, according to Semgrep. The real shift is not AI novelty but faster triage, tighter prompts, and better confidence handling for security workflows.
NHIMG editorial — based on content published by Semgrep: AI-assisted triage and autofix confidence in Semgrep Assistant
By the numbers:
- Semgrep Assistant marked 230 findings as likely false positives, and 95% of recorded ratings were "Agree".
- The assistant generated 35 agree and 2 disagree ratings from the 230 cases, showing how limited feedback volume can shape interpretation.
Questions worth separating out
Q: How should security teams let AI triage SAST findings without losing control?
A: Use AI to filter and annotate findings only within tightly scoped boundaries.
Q: What breaks when AI triage is applied to weakly classified findings?
A: The model can apply the wrong reasoning to the wrong issue class, such as treating a security problem like a code-quality issue or dismissing an exploitable pattern as irrelevant.
Q: How do teams know whether AI autofix suggestions are safe enough to use?
A: They should verify whether the proposed change compiles, requires updates elsewhere, and preserves the intended security behaviour.
Practitioner guidance
- Define AI triage boundaries Limit assistant-generated decisions to clearly scoped finding categories, and require human approval for any finding that could affect secrets, authentication, or access control logic.
- Improve rule metadata before automation Add consistent category, severity, and context fields to detection rules so AI prompts receive structured inputs rather than mixed signal.
- Validate autofix output independently Run syntax, dependency, and policy checks on every AI-generated fix before allowing it into a pull request path.
What's in the full article
Semgrep's full post covers the operational detail this post intentionally leaves for the source:
- How Assistant threads its output into GitHub pull request comments and Slack notifications for workflow integration.
- The beta feedback mechanics behind Agree and Disagree ratings, including how the team interpreted low response volume.
- The prompt strategies used to separate security, performance, and code quality guidance into different triage paths.
- The autofix confidence method that evaluates likely failure modes after a proposed code change is generated.
👉 Read Semgrep's analysis of AI-assisted code triage and autofix confidence →
AI-assisted triage for code findings: are your controls keeping up?
Explore further
02/08/2026 1:28 pm
AI-assisted triage introduces a governance problem before it creates a productivity gain. Once a model starts filtering findings, the organisation is no longer only managing static analysis output. It is managing an additional decision layer whose errors can suppress real risk or amplify noise, which makes traceability and review policy part of the control surface. The right question is not whether AI can read alerts, but whether the organisation can justify the decisions it makes on the model's behalf.
A question worth separating out:
Q: How should security teams govern AI use in developer tooling?
A: Security teams should govern AI use as a data and access problem, not only a productivity feature. Define what information can be sent to models, require human review of generated code, and apply least privilege to connected repositories and tools. Approved use cases should be explicit, monitored, and revisited as model capabilities expand.
👉 Read our full editorial: AI-assisted code triage changes how security teams handle finding noise
