AI triage accuracy changes AppSec governance more than noise reduction

At a glance

What this is: This is an AppSec analysis of AI-assisted finding triage, showing that Semgrep’s Assistant can align with researcher decisions on true positives at a high rate while remaining deliberately conservative on false positives.

Why it matters: It matters because AI triage is starting to shape which findings developers see, which findings AppSec reviews, and how trust, accountability, and review boundaries are defined across identity and security programmes.

By the numbers:

• Semgrep says Assistant agreed with security research triage decisions on true positives 96% of the time.
• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.
• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes, and as quickly as 9 minutes in some cases.

👉 Read Semgrep's analysis of AI-assisted triage accuracy for AppSec findings

Context

AI-assisted triage is becoming part of AppSec operating models, which means the core question is no longer whether an LLM can read code, but whether its verdicts are reliable enough to shape developer interruption and backlog prioritisation. In practice, this is a governance problem around trust, escalation thresholds, and the boundaries between automation and human review.

Semgrep’s article frames the issue through one specific control point: whether an assistant should suppress a finding, surface it to developers, or hand it to AppSec for review. That intersects with identity governance because the same control logic increasingly governs machine decisions, service access, and non-human workflows across development and security operations.

Key questions

Q: How should security teams govern AI agents that triage code vulnerabilities?

A: Security teams should treat code-triaging AI agents as governed production services, not prompts with a UI. That means binding each decision to exact repository state, separating suggestion from approval, and limiting read and write access to the minimum scope needed for the task. Without those controls, the agent can be accurate in appearance while being unreliable in practice.

Q: How do you know if AI triage is actually improving security outcomes?

A: Measure whether the triage decision can be reviewed, reversed, and tied back to concrete evidence. If false positives disappear but responders cannot explain why, the process has reduced noise without improving trust. Effective triage should shorten time to decision while preserving the ability to validate critical findings.

Q: What do security teams get wrong about low false positive rates?

A: They often assume a lower false positive rate means better security, but it may just mean the scanner is missing more issues. A cleaner queue is not helpful if real vulnerabilities never reach the analyst. Teams should judge whether the tool improves decision quality, not whether it makes the dashboard look calmer.

Q: Who remains accountable when an AI assistant filters a security finding?

A: The organisation remains accountable, not the model. AppSec and security leadership must own the policy, the thresholds, and the review process that permit suppression. If the assistant hides a real issue, that is a governance failure in control design, not an excuse to defer responsibility to automation.

Technical breakdown

How LLM-based autotriage evaluates true and false positives

LLM-based autotriage combines a code finding with surrounding context, rule metadata, prior decisions, and retrieval-augmented instructions so the model can judge exploitability. The system is not simply classifying code syntax. It is estimating whether the evidence indicates a security-relevant issue or a finding that can be safely suppressed. That design works best when the model is given enough local context to understand data flow, but not so much that it becomes noisy or expensive. The key technical challenge is balancing recall for real issues against over-classification of harmless code patterns.

Practical implication: teams should treat autotriage as a decision-support layer that still needs benchmarked guardrails and human override paths.

Why conservative false-positive handling changes developer trust

Semgrep describes a system that is more conservative in marking false positives than its researchers, which is a common pattern in AI-assisted review. This matters because false-positive suppression can improve developer attention, but only if the system remains credible. If the model over-filters, it risks missing important findings. If it under-filters, developers tune out alerts. In AppSec, the architecture is effectively a signal-processing problem: the model is not just deciding correctness, it is shaping the usefulness of the whole feedback loop.

Practical implication: measure false-positive suppression separately from true-positive recall before letting AI decide which findings interrupt developers.

What autonomous triage requires from the review workflow

An autonomous or semi-autonomous triage system needs explainability, retention of the original backlog, and a review path for exceptions. Semgrep’s model does not simply close findings. It routes outcomes differently based on confidence, then preserves visibility for AppSec engineers. That architecture matters because security teams still need auditability, especially where AI decisions affect developer workflow or remediation priority. Once AI is allowed to filter findings, the control objective shifts from perfect accuracy to controlled delegation with evidence and reviewability.

Practical implication: design the workflow so AppSec can audit AI decisions, challenge them, and re-triage edge cases without rebuilding the backlog.

NHI Mgmt Group analysis

AI triage is becoming a governance control, not just an efficiency feature. Once an assistant decides which findings developers see, it is operating inside the security decision chain, not outside it. That means accuracy thresholds, confidence scoring, and override rights are governance issues as much as technical ones. For practitioners, the question is whether AI can reduce noise without becoming an unreviewed policy engine.

The real control problem is not triage automation, it is false-negative tolerance. Semgrep’s own framing shows that the critical trade-off is between filtering noise and missing real findings. In identity and security programmes, the same pattern appears whenever machine decisions are allowed to suppress escalation. The practical lesson is to define where the acceptable error lives before assigning authority to the model.

AI-assisted AppSec creates a new trust boundary around non-human decision-making. The assistant is effectively a non-human actor making runtime judgments about code findings, which places it adjacent to NHI governance and agentic AI oversight. That intersection matters because the organisation now needs ownership, review rights, and evidence trails for machine-made decisions. Practitioners should treat this as an identity and accountability problem, not only an AppSec tuning exercise.

Signal-to-noise management is now a programme-level security objective. The article makes clear that too much alert noise causes developer disengagement, which weakens remediation regardless of model sophistication. That is not a tooling issue alone. It is a governance signal that teams must align detection fidelity, review capacity, and developer interruption policy. For practitioners, the implication is to manage AI triage as part of the operating model.

Autonomous triage will force security teams to define the minimum acceptable review standard. As AI systems take on more of the first-pass decision work, the organisation must decide what requires human confirmation, what can be auto-suppressed, and what must always escalate. That boundary will vary by risk class, but it cannot be left implicit. Practitioners should formalise decision rights before expanding machine authority.

What this signals

AI triage should now be measured as part of detection governance, not just AppSec throughput. When machine verdicts decide whether developers are interrupted, the programme’s control surface expands from finding volume to decision quality, reviewability, and drift. For identity-heavy environments, that same logic applies to non-human workflows that can quietly shape access or remediation outcomes without clear accountability.

Signal-to-noise pressure will push more teams toward delegated security decisions. The operational reason is simple: findings backlogs become unmanageable when every alert gets equal attention. The governance question is whether teams can assign machine review rights without losing the ability to prove why a verdict was made. That is where audit trails, confidence thresholds, and exception handling become essential.

Developer trust is the limiting factor, not model sophistication. If teams want AI to reduce AppSec friction, they need a process that keeps false suppression visible and contestable. Otherwise, the organisation risks replacing alert fatigue with blind trust fatigue, which is harder to recover from. Practitioners should align AI triage rollout with review capacity and clear accountability for model-driven decisions.

For practitioners

• Benchmark AI triage against real researcher decisions Use a labelled finding set that reflects your own languages, frameworks, and complexity profile, then measure true-positive and false-positive agreement separately. Do not rely on user sentiment alone, because developer feedback often overstates accuracy when the interface is noisy.
• Set explicit suppression thresholds for low-confidence findings Define which classes of findings an assistant may suppress, which require human review, and which must always surface to developers. Tie the threshold to business risk rather than assuming one global confidence score is sufficient.
• Preserve a human-auditable backlog for every AI verdict Keep suppressed findings visible to AppSec engineers with the model’s explanation, the original rule context, and the dataflow evidence used for the verdict. That allows review, challenge, and re-triage without losing the original security record.
• Track remediation impact, not just model accuracy Measure whether noise reduction increases fix rates, shortens time to remediation, and improves developer response quality. A triage model that is slightly less precise but materially increases remediation can still be the better security choice.

Key takeaways

• AI triage is no longer a prototype concern. It is now part of how security programmes decide what deserves human attention.
• Semgrep’s reported 96% true-positive agreement shows that the operational debate has shifted from whether AI can triage to how much error an organisation will tolerate.
• Teams should benchmark, threshold, and audit AI verdicts before delegating suppression decisions, or they risk turning noise reduction into hidden governance failure.

Key terms

• Autotriage: Autotriage is the use of software, often an AI model, to classify security findings as likely true positives or false positives before a human review step. In AppSec, it changes workload allocation, developer interruption, and remediation prioritisation, so its accuracy and explainability directly affect trust in the programme.
• False Positive: A false positive is a scanner result that looks like a secret but is not actually sensitive. In secret governance, false positives matter because they consume analyst time, weaken trust in alerts, and can delay response to the findings that truly change exposure and access risk.
• True Positive: A true positive is a finding that correctly identifies a real security issue. In triage systems, true-positive recall matters because missing a genuine issue can leave exploitable code in production. Security teams usually care about both recall and precision, but the acceptable trade-off depends on risk and workflow design.
• Retrieval-augmented Generation: Retrieval-augmented generation is a pattern where an AI model pulls external information before generating output. The security challenge is that access rules can weaken when data is chunked, embedded, cached, or reused, so source permissions may not automatically follow the content into the model's context.

What's in the full article

Semgrep's full analysis covers the operational detail this post intentionally leaves for the source:

• The benchmarking workflow used to compare assistant verdicts against security researchers across more than 2,000 findings
• Prompting and context design choices that changed model behaviour, including the role of rule confidence values
• The developer workflow mechanics for PR comments, Jira ticketing, and backlog tagging when findings are classified as true or false positives
• The trade-off analysis behind prioritising false-negative reduction over more aggressive false-positive suppression

👉 Semgrep's full post covers the benchmarking method, prompt tuning, and triage workflow details

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners connect identity control design to the broader security operating model.