A security vendor's AI feature is real if it works on your own code or data, shows the evidence behind each output, has a documented failure mode, and can be switched off. If a demo only runs on the vendor's sample project, treat the claim as unproven until you test it yourself.
What "real" means in a buying decision
"AI" on a datasheet can mean a large language model, a classic machine learning classifier, a rules engine with a friendly name, or a chat box in front of an existing report. None of these is automatically bad. The question is whether the feature does a specific job better than the alternative, and whether you can prove it.
Define the job first. Examples: rank vulnerabilities, explain a finding, propose a fix, write a policy, answer questions about an inventory. A feature without a named job cannot be tested.
Five tests you can run in one afternoon
| Test | What you do | Real looks like |
|---|---|---|
| Your data | Run it on a repository you know well | Results match what your engineers already know, plus something new |
| Evidence | Ask why for three outputs | A traceable reason, not a confident paragraph |
| Repeat | Run the same input twice | Stable outputs, or variation the vendor can explain |
| Failure | Feed it an edge case | A refusal, a low confidence flag, or a clear limit |
| Off switch | Look for the setting | You can disable it per project or per team |
Run the tests with someone who knows the codebase. A feature that surprises you with a correct finding is a good sign. One that surprises you with a confident wrong answer tells you more.
Questions that expose a label
- Which part of the pipeline uses a model, and which part is deterministic?
- What happens to the output when the model is wrong? Who sees it first?
- Can you show a case where the feature failed and what changed afterward?
- Is the feature generally available today, in early access, or on a roadmap?
That last question matters. Regulators have already acted on exaggerated AI claims. In March 2024 the SEC announced settled actions against two investment advisers for misleading statements about their use of AI, and called the practice "AI washing". That case involved financial advice, not security tools, but the lesson carries over: a claim about AI should match what the product actually does.
Use a framework for the follow up
The NIST AI Risk Management Framework is voluntary and organizes AI risk work into four functions: Govern, Map, Measure, and Manage. You do not need to adopt it to borrow the idea. Ask the vendor how they measure feature quality, who owns that number, and how often it is reviewed. A vendor with a real answer usually has one ready.
Try it yourself
Click through it at your own pace, or open it full screen.
Click through the exploitability check and notice that each verdict comes with a reason you can inspect. That is the standard to hold any AI feature to.
Where Safeguard fits
Safeguard publishes what is generally available, including reachability analysis, SBOM and dependency scanning, and a free scan at gold.safeguard.sh/scan you can point at your own project before any conversation.
Quick check
Is a chat interface proof of AI capability?
No. A chat box can sit in front of any report. Test whether the answers come from your data and cite evidence.
Should I ask for a proof of concept?
Yes, with success criteria written before it starts. See the scorecard approach in related posts.
Sources
- SEC press release 2024-36, "SEC Charges Two Investment Advisers with Making False and Misleading Statements About Their Use of Artificial Intelligence", 18 March 2024: https://www.sec.gov/newsroom/press-releases/2024-36
- NIST, AI Risk Management Framework: https://www.nist.gov/itl/ai-risk-management-framework
Last reviewed: 19 October 2026.
