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

At a glance

What this is: This is a Semgrep analysis arguing that many “AI-native” AppSec claims are AI-washing unless AI changes the detection path, coverage model, or triage logic.

Why it matters: It matters because IAM, AppSec, and governance teams increasingly need to distinguish genuine AI capability from wrappers when evaluating risk, controls, and operating models.

By the numbers:

• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.

👉 Read Semgrep's analysis of AI-washing in application security

Context

AI-washing in application security is a control and governance problem, not just a branding problem. When a product says it is AI-native, practitioners need to know whether AI actually affects detection, triage, rule generation, or coverage, or whether it only explains a result produced by an unchanged engine. That distinction matters because security teams make budget, assurance, and operating decisions on the basis of these claims.

For identity and security programmes, the practical issue is evidence. If a tool cannot show where AI sits in the workflow, teams should treat the claim as unproven until it is tied to measurable changes in analysis quality, false-positive handling, or language coverage. The same scrutiny applies to AI agents and NHI-like service identities in software pipelines, where automation without governance can create blind spots rather than reduce them.

Key questions

Q: How should security teams test whether an AI security tool is genuinely AI-native?

A: Test where AI operates in the workflow. If it only summarizes results, writes explanations, or adds a chat interface, it is a wrapper. If it changes detection, prioritisation, or coverage, it is structural. Ask vendors to demonstrate the product with AI disabled, then compare outputs, noise levels, and language support to see whether the AI actually changes control behaviour.

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 do teams get wrong when they evaluate AI support in AppSec tools?

A: They often confuse usability features with security capability. A polished explanation layer does not improve detection, and a co-pilot function does not prove architectural change. Teams should ask where AI sits in the pipeline, how it changes findings, and whether it expands or merely restyles the legacy scanner.

Q: When should organisations re-evaluate their AppSec tooling after introducing AI coding assistants?

A: They should re-evaluate as soon as AI-generated code becomes a material part of delivery. That shift changes defect patterns, coverage expectations, and the cost of manual triage. A tool tuned only to pre-AI code can miss recurring mistakes or over-treat harmless patterns, so validation should happen against current development reality.

Technical breakdown

What makes an application security tool genuinely AI-native?

An AI-native AppSec tool uses AI in the analysis pipeline, not only in the user interface. That means the model influences what becomes a finding, how findings are prioritised, or how new coverage is built. A wrapper tool leaves the underlying static engine intact and adds summaries, chat prompts, or explanation layers on top. The technical test is architectural: remove the AI and ask whether the product still behaves the same. If it does, AI is decorative rather than structural.

Practical implication: require vendors to show where AI changes detection or triage, not just where it changes presentation.

Why static analysis alone struggles with AI-generated code

AI-assisted code generation changes the shape of codebases. It can amplify repetitive insecure patterns, omit context that a developer would normally carry mentally, and introduce defects faster than legacy review processes can absorb. Static analysis still matters, but tools tuned only for pre-AI development often miss the new pattern distribution. The strongest approach combines deterministic program analysis with AI-assisted prioritisation so each compensates for the other's weakness.

Practical implication: evaluate whether the scanner adapts to AI-generated code patterns instead of assuming old rule sets remain sufficient.

How do AI and program analysis complement each other in detection?

Pure LLM-based detection can infer relationships that are not actually present, which raises precision risk. Pure static analysis can miss contextual issues that depend on intent, flow, or development patterns. A credible modern AppSec architecture blends both, using deterministic analysis for guarantees and AI for scale, context, or rule expansion. The question is not whether AI is present, but whether the two layers are technically integrated into the detection path.

Practical implication: insist on a concrete explanation of how the AI layer and the program analysis engine exchange findings and suppress false positives.

Threat narrative

Attacker objective: The objective is to sell or adopt misleading security capability claims that do not improve real control outcomes.

1. Entry begins when a vendor rebrands a legacy capability as AI-native, creating a trust gap between marketing and actual control behaviour.
2. Escalation follows when buyers rely on the claim without validating whether AI changes detection, triage, or coverage.
3. Impact is programme-level misallocation of spend, weak assurance, and blind spots that persist because the underlying engine never changed.

NHI Mgmt Group analysis

AI-washing in AppSec creates governance debt: when buyers cannot tell whether AI is part of the detection path or just the presentation layer, they inherit unmanaged assurance risk. Security leaders then approve spend on claims instead of controls, and that weakens both procurement discipline and operational trust. The practical conclusion is that AI capability must be evidenced as a control property, not accepted as branding.

Detection-path integrity is the real differentiator: the meaningful question is not whether a product uses AI, but whether AI changes what the system detects, prioritises, or suppresses. That distinction separates structural capability from a legacy workflow with a chat front end. Practitioners should evaluate AppSec tools the same way they evaluate identity controls: by where decisions are made, not by how polished the interface looks.

AI-generated code has created a new coverage problem: scanners built for pre-AI development are being asked to cover a code shape they were never designed around. That shifts the burden onto vendors to show how rule generation, triage logic, and language support changed architecturally. For security teams, the practical conclusion is to revalidate coverage assumptions whenever development workflows shift materially.

AppSec teams need evidence-based procurement, not label-based trust: if a vendor cannot explain what changed under the hood, the “AI-native” label is not useful for risk decisions. This is especially relevant where AI features touch identity-adjacent workflows, including developer access, code generation, and automated triage, because those are control points, not just convenience features. The practical conclusion is to demand proof of control behaviour before treating AI claims as procurement criteria.

What this signals

AI-native claims will increasingly be judged as control claims, not product claims. Security teams should expect procurement scrutiny to move from interface language to evidence of how a tool changes detection quality, false-positive rates, and coverage breadth. The practical signal is simple: if the AI layer cannot be tied to measurable control outcomes, the claim will not survive mature review.

Coverage debt is becoming a hidden AppSec risk: as AI-assisted development expands, tooling that cannot adapt to new code patterns will accumulate blind spots faster than teams can review them. That is especially relevant where code security overlaps with identity and secrets governance, because leaked credentials and weak application controls often emerge together. Teams should validate coverage against current delivery workflows, not last year’s assumptions.

Programmes that treat AI as a feature will underinvest in assurance. The more useful framing is to assess whether AI changes the economics of triage, rule creation, and language support. Where it does, teams can scale without proportional analyst growth. Where it does not, the organisation has bought a better explanation layer, not a better security model.

For practitioners

• Test whether AI changes control behaviour Ask vendors to demonstrate where AI alters detection, triage, or coverage, and compare the product with AI disabled. If results are materially unchanged, treat the AI claim as presentation, not control logic.
• Validate AI-generated code coverage separately Run a dedicated evaluation on code produced by AI assistants and check whether the tool identifies the same insecure patterns at the same rates as in human-written code. Use representative repositories, not toy examples.
• Measure false-positive reduction in the triage loop Require evidence that AI reduces noise before findings reach engineers, rather than generating explanations after the verdict. Track the percentage of findings dismissed without remediation to see whether the tool is changing the workload.
• Demand architectural explanations for new language support When a vendor claims broad coverage, ask what changed architecturally to enable it and how many rules versus models support that scope. A credible answer should describe the mechanism, not just the feature list.

Key takeaways

• AI-washing in AppSec is a control problem because the relevant question is whether AI changes detection, triage, or coverage.
• Legacy tools can look AI-native while leaving false positives, language gaps, and manual burden materially unchanged.
• Security teams should validate AI claims with architecture, pipeline position, and measurable outcomes before treating them as procurement criteria.

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 architecture: An AI-native architecture is designed with machine intelligence built into the operating model from the start, rather than added on later. In security, that usually means detection, triage, reporting, and response are all informed by the same data and can be automated under defined governance.

What's in the full article

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

• A structured vendor question set for distinguishing AI-washed tooling from AI-native AppSec capability.
• Examples of how AI can sit in the detection path, triage loop, or UX layer, and why that distinction matters.
• Further explanation of how AI-generated code changes AppSec evaluation criteria across languages and frameworks.
• The source article also walks through the practical difference between a legacy engine with a wrapper and a product whose architecture actually changed.

👉 Semgrep's full article covers the vendor questions, architectural tests, and AppSec evaluation criteria in more detail.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management for practitioners working across identity programmes. It helps security leaders connect identity control discipline to broader security architecture and operational risk.