AI-washing in AppSec is a governance problem, not a marketing one

At a glance

What this is: This is Semgrep’s analysis of AI-washing in application security, arguing that “AI-native” only means something if AI changes detection, triage, or coverage rather than just the user interface.

Why it matters: It matters because security teams buying AppSec tooling need to distinguish genuine architectural change from marketing language, especially as AI-assisted coding increases the pressure on scanners and review workflows.

Context

AI-washing is a governance problem when vendors describe legacy security functions as AI-native without changing the control logic underneath. In application security, that distinction matters because teams are not buying language, they are buying detection quality, triage fidelity, and coverage for modern codebases.

The practical risk is a control mismatch: organisations assume they have gained new analytical capability when they may only have gained a new explanation layer. That creates procurement drift, weak assurance, and a false sense that AI-assisted development is being governed by tools that were never rebuilt for it.

Key questions

Q: How do teams know whether AI-assisted AppSec is actually helping?

A: Look for findings that can be traced back to named components, repeated across assessments, and mapped to concrete remediation actions. If the system produces faster output but reviewers still cannot understand why a requirement exists, the programme has improved throughput without improving governance.

Q: Why do AI-washed security tools create governance risk for practitioners?

A: Because procurement decisions become detached from actual control behaviour. A tool that only repackages legacy output can still look modern while leaving false positives, coverage gaps, and manual workload unchanged. That creates assurance risk, wasted budget, and a false sense of maturity across AppSec and broader security governance.

Q: What are the signs that an AppSec tool’s AI is only cosmetic?

A: The strongest sign is when the vendor can only demo a chat interface, summary text, or explain-this-finding panel. Another clue is when the underlying scanner, rule set, and false-positive behaviour look unchanged. Cosmetic AI improves the presentation layer, not the security outcome.

Q: Should security teams compare AI-native and legacy AppSec tools differently?

A: Yes. The comparison should focus on whether AI changes coverage, triage quality, and scale of rule creation rather than on branding. Teams should ask whether the tool can handle AI-assisted code, support more languages, and reduce analyst effort without sacrificing precision.

Technical breakdown

Detection path versus narration layer

In AppSec, the key architectural question is whether AI participates in the detection path or only in the narration layer. If AI is only summarising findings produced by a legacy scanner, it is cosmetic. If it changes which findings are surfaced, suppressed, or prioritised, then it is part of the control logic. That distinction matters because a polished explanation can make a false positive feel credible without improving precision. Real AI-native analysis changes the triage loop, not just the dashboard copy.

Practical implication: Test whether AI changes verdicts and prioritisation, not just report text.

Why AI-generated code changes the scanning problem

AI-assisted development changes the shape of codebases, not just their volume. Code generated by models tends to repeat certain insecure patterns, omit context, and introduce issues at different rates from human-written code. A scanner that was tuned for pre-AI development may still function, but it can develop blind spots if it assumes older failure patterns dominate. The governance challenge is to validate whether the tool has adapted its rules, signals, and coverage to the new coding profile rather than merely reusing the old one.

Practical implication: Assess whether your AppSec controls are tuned for AI-assisted code patterns, not just traditional defects.

Architectural change versus feature wrapping

Many products add AI at the edges, such as a chat assistant or finding explainer, while leaving the underlying engine unchanged. That is feature wrapping, not architectural change. A genuine shift shows up where the product’s core mechanics change, such as new detection logic, materially broader language coverage, or a different way of generating and prioritising rules. The question is whether AI reduced specialist labour inside the system or only reduced the effort needed to present the same output. Governance should treat that as a control integrity check.

Practical implication: Demand evidence that AI changed the product architecture before accepting AI-native claims.

NHI Mgmt Group analysis

AI-washing in AppSec is a control integrity issue, not a branding nuisance. If AI only explains findings that a legacy scanner already produced, the product has not changed in the way buyers care about. That matters because governance depends on whether a control actually improves detection, triage, or coverage. Teams should treat the AI claim as an architectural assertion and verify it accordingly.

AI-native should mean load-bearing AI, not decorative AI. Semgrep’s framing is useful because it separates real operational dependence from interface polish. If removing the AI leaves the product functionally intact, the AI is not doing security work. Practitioners should evaluate whether AI changes the detection path, coverage model, or triage decisioning before they trust the label.

Modern AppSec tooling now has to account for AI-assisted code generation as a governance input. The growth of model-assisted coding changes what good detection looks like, because insecure patterns are arriving in different shapes and at different rates. A scanner that cannot adapt to those patterns is not necessarily broken, but it is out of alignment with the development system it is supposed to govern. Security teams should validate that the tool adapts to the codebase they actually have, not the one they had three years ago.

Procurement teams need a better test than vendor vocabulary. The question is not whether a product says “AI-powered”, but whether it can demonstrate lower noise, broader coverage, or faster rule creation without equivalent manual effort. That makes AI assurance part of security governance, not just marketing review. Practitioners should demand concrete architectural evidence before they count AI as a control improvement.

AI-washing creates assurance debt across the AppSec programme. When tooling claims outrun technical substance, teams build policies, dashboards, and buying decisions on assumptions that may not hold. The result is not only wasted budget but also weaker confidence in the security signal itself. Security leaders should reset evaluation criteria so the product has to prove its contribution to control effectiveness.

What this signals

AI-washing in security tooling is now a programme governance issue. Teams should assume that vendor language, demos, and product labels are insufficient until the control path is tested against the code they actually ship. The practical shift is to make AI claims subject to the same scrutiny as any other control assertion.

AI-assisted development raises the stakes for detection quality. As code generation changes what reaches the repository, AppSec buyers need assurance that their tooling adapts to the new defect profile rather than merely renaming old capabilities. A scanner that cannot keep pace may still run, but it will govern the wrong baseline.

For practitioners

• Test whether AI is in the detection path Ask vendors to show exactly where AI changes a finding, a ranking, or a suppression decision. If the AI only rewrites output after the scanner has already decided, treat it as a presentation layer.
• Validate support for AI-generated code patterns Use representative code produced with AI assistance and check whether the tool recognises the insecure patterns that appear more often in that workflow, including prompt-related and context-loss errors.
• Demand an architectural explanation Require the vendor to identify what changed in the analysis engine, rule pipeline, or coverage model when AI was introduced, not just what new screens or assistants were added.
• Measure noise reduction directly Compare false-positive rates and triage effort before and after the AI capability is enabled. If the numbers do not move, the AI claim is not materially improving the control.
• Benchmark coverage on long-tail languages Test whether obscure frameworks or low-volume languages are supported through repeatable analysis logic rather than a thin ruleset that only looks broad on paper.

Key takeaways

• AI-washing in AppSec creates assurance debt because teams may think they have bought new analytical capability when they have only bought a new explanation layer.
• The material test is whether AI changes detection, triage, or coverage, especially for AI-assisted code and long-tail language support.
• Security teams should demand architectural evidence, not vocabulary, before treating AI claims as a control improvement.

Key terms

• AI Washing: AI washing is the practice of describing ordinary automation or limited AI features as if they were autonomous or agentic. In security operations, it creates procurement risk because buyers may pay for capabilities that do not actually improve investigation quality, decision transparency, or operational resilience.
• Detection path: The detection path is the sequence of logic that determines whether an issue becomes a security finding. In AppSec, this includes parsing, analysis, scoring, and prioritisation, not just the final explanation shown to users.
• Triage loop: The triage loop is the part of the security workflow where findings are filtered, prioritised, and assigned for action. If AI meaningfully reduces noise here, it changes analyst workload; if it only explains results, it does not improve operations.
• AI-native development: AI-native development is the practice of building software with AI capabilities and AI-assisted workflows built in from the start. It treats models, prompts, agents, and data access as core design elements, so architecture, testing, governance, and security are shaped around machine-driven behavior, not added later as an afterthought.

Deepen your knowledge

NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. It is designed for practitioners who need to assess control integrity across identity, access, and emerging AI-driven systems.