Notifications
Clear all
Topic starter
02/08/2026 11:22 am
TL;DR: FTC enforcement against misleading AI claims and the persistence of AI-washing in AppSec show that “AI-native” now needs technical proof, not branding, according to Semgrep. The deciding issue is whether AI changes detection, triage, and coverage, or merely narrates legacy output after the fact.
NHIMG editorial — based on content published by Semgrep: AI-washing in AppSec and the questions practitioners should ask before buying
Questions worth separating out
Q: How should security teams test whether an AI security tool is genuinely AI-native?
A: Test where AI operates in the workflow.
Q: Why do AI-washed security tools create governance risk for practitioners?
A: Because procurement decisions become detached from actual control behaviour.
Q: What do teams get wrong when they evaluate AI support in AppSec tools?
A: They often confuse usability features with security capability.
Practitioner guidance
- Test whether AI changes control behaviour Ask vendors to demonstrate where AI alters detection, triage, or coverage, and compare the product with AI disabled.
- 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.
- 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.
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.
👉 Read Semgrep's analysis of AI-washing in application security →
AI-washing in application security: what should teams actually test?
Explore further
02/08/2026 12:40 pm
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.
A question worth separating out:
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.
👉 Read our full editorial: AI-washing in AppSec is a governance problem, not a marketing one
