TL;DR: Most AI security products are too new for buyers to ask a peer, so you have to ask the vendor for evidence instead. Score every vendor against the same seven categories, split table stakes from paid extras, insist on a proof of value, and keep the contract short. This came up on eight client calls in 2026.
Key takeaways:
Eight IANS client calls between January 30 and August 31, 2026 raised vendor-trust questions: no peers to ask, and too much vendor noise to sort alone.
One evaluation covers seven categories: business outcomes, performance, architecture fit, security and data control, governance and risk, vendor maturity, and cost at scale.
A short list of features is table stakes now (six of them). Another short list (five) is worth paying extra for.
CISA and the FBI published the Secure by Demand Guide in August 2024. Its buyer questions carry over to AI vendors with a few additions.
Buy against one named missing control and get a proof of value first. Then sign the shortest contract you can, because vendors get acquired mid-evaluation.
Why can't you just ask peers about an AI security vendor?
Because the peers who'd vouch for these products haven't finished their own first rollout. A buyer can't call a reference who's been through a bad day with the product, since almost nobody has been through one yet. So the usual shortcut is gone, and the evaluation has to do the work.
On February 5, 2026, a security leader at a cancer center told me a vendor had pitched him an "AI firewall." He said he wouldn't run any product like it until he'd talked to peers who already did. As my notes read, the peers he wanted to call weren't there yet. That's a fair position, and it's the one most buyers are in.
The same doubt showed up on January 30, 2026, on a call with a large hospital system. That team sent vendors coverage grids to fill in, and it took the answers with a grain of salt. One line from my notes that day: a vendor who says it does everything is lying, because no single product does.
The book Michelle Savage and I wrote, Agentic AI + Zero Trust, has the same scene in Chapter 6. A retail CISO sits through her fifth vendor demo, where someone has stuck "AI-ready" on a traditional product. Her question is the one every buyer asks now: how do we know who's real?
I counted the calls. This exact worry came up on eight client calls between January 30 and August 31, 2026. A cancer center, a hospital system, a medical device maker, a healthcare data company, a credit union, a large bank, a national hospital operator, and a law firm all touched it in some form. That's a pattern.
What should you ask an AI security vendor before you buy?
Ask every vendor the same questions, so the answers line up side by side. Cover seven categories: business outcomes, capability and performance, architecture fit, security and data control, governance and risk, vendor maturity, and cost at scale. Then read the answers against a written baseline, not against the sales deck.
On March 30, 2026, a global healthcare data company asked me for exactly this. The buyer wanted a standard set of questions, so he'd know he wasn't missing one and could feel good about the security. I walked him through seven categories and 15 questions. It's the shape that counts, and it works because it forces vendors to answer the same things in the same order.
The baseline underneath it comes from the enterprise agreements the big model providers already sell. Think of it as the floor. Below it, don't keep talking. It has five parts:
Compliance APIs, so you can pull your own audit records.
Customer-managed keys, so you hold the encryption keys, not the vendor.
Data isolation, so your data stays apart from every other customer's.
No-training clauses, so the vendor can't train models on what you send.
Dedicated tenants, so you get your own private copy of the service.
Add one more question, because it keeps catching people. What model is underneath? On that same March call, a buyer noted that an approved product doesn't mean approved AI, since a wrapper can sit on top of a model nobody reviewed. His words about one coding product were, roughly, what model are they using behind the scenes? If the vendor can't say, that's your answer.
Which features are table stakes, and which are worth paying extra for?
Six features are close to table stakes now, so don't pay a premium for them. Five are still worth paying for. Sorting them before the demo stops a vendor from selling you a commodity feature at a specialist price. It also tells you fast whether you already own the basics.
On May 26, 2026, I walked a credit union through this split. The table stakes were AI app discovery, prompt-layer data loss prevention (a filter on what people type into AI), prompt-boundary screening, AI security posture management (a scan for risky AI settings), Microsoft Purview labeling, and a governance registry, which is the list of every AI system and who owns it.
The five worth paying for were harder to find:
Visibility into what people do inside AI sessions on unmanaged devices and coding environments.
Runtime context for agents and MCP servers that's tied to a real identity.
Analysis of intent across several turns of a conversation.
Governance that's wired straight to enforcement, so a rule can actually stop something.
Red teaming (attack testing) across the whole life of the agent.
One warning from that call. Check whether you're buying a product or a feature. A single feature can get bought and folded into a bigger platform, and then your contract covers something that no longer exists. That's why I told the same credit union to look at what it already owned first. Its network, identity, data, and cloud-access tools already sat in the AI traffic path. The post on checking what you own before you buy an AI security product goes deeper.
What evidence should a vendor hand you?
Ask for the same evidence you'd ask any software maker for, then add the AI-specific parts. CISA and the FBI published the Secure by Demand Guide in August 2024 for exactly this job. It covers the whole purchase, from the questions you ask before you buy to the checks you run after you sign, with contract requirements in between.
The guide was written for software in general, not for AI agents. Say that plainly. The parts that carry over cleanly are a machine-readable software bill of materials (a parts list for the code), a check on open-source code, security logs in the base product, and a published policy for how the vendor handles reported flaws. CISA's Secure by Demand Guide lists the full question set.
Here are my additions for an AI vendor. Ask which models sit underneath and who supplies them. Ask who owns the data you send. Ask whether you can send its logs to your own watching tools. Ask which of the five questions in the Agentic Trust Framework the product answers (identity, behavioral monitoring, data governance, segmentation, incident response), and which it leaves to you. A vendor that maps its product to those five questions has done real homework. One that can't has told you something.
Then insist on a proof of value. That's my standing line to any buyer. Pick one specific control you don't have today. Run the product against it on your own data, then decide from what you saw. A vendor that won't allow one has answered for you.
How do you handle a vendor that's too new to trust?
Treat maturity as its own test, and judge a young vendor on what it can prove, not on how good the demo looks. Some of the best products are young. A gate on maturity doesn't ban them. It sets the terms they have to meet.
On August 31, 2026, the information security director at a large law firm told me he'd scanned the market a couple of months earlier. Every emerging AI security vendor he found still read like a demo. He wasn't going to bring a five-person startup into a firm of that size. I also had a counterweight for him. One vendor in that scan was performing well, trade-offs and all, so the answer wasn't a blanket no.
Contracts are where that caution turns into action. On July 31 and August 31, 2026, the guidance on both calls was the same: buy against a specific missing control, and take the shortest contract you can get. A fast-moving market punishes long commitments. On an August 3, 2026 call, a vendor a hospital operator was evaluating got acquired halfway through the evaluation. That risk now sits inside the buying decision.
Incumbents aren't a free pass either. On that same August 31 call, the law firm's move off its current network security vendor was set by a renewal date in April 2027. The reason wasn't features. It was a slow decay in the relationship and in support. Old vendors and new ones both need an exit plan. The post on how to spot agent washing covers the fake-agent side of the same problem.
Frequently asked questions
Do I need a formal scoring model to compare AI security vendors?
No, but you do need the same questions for every vendor. A simple table with the seven categories as rows and each vendor as a column is enough. Weights are optional. What breaks comparisons is asking one vendor about data isolation and forgetting to ask the next.
Is an incumbent vendor always the safer choice?
Not always. Your existing network, identity, data, and cloud-access tools often sit in the AI traffic path already, so they're the right first look. But incumbents decay too. One law firm's plan to leave its current vendor came from slipping support, dated by an April 2027 renewal, and had nothing to do with features.
How long should the contract be?
As short as the vendor will accept. I don't have a magic number, and I won't invent one. On two of the eight calls (July 31 and August 31, 2026) the advice was the shortest feasible term, because vendors in this market get acquired or folded into a bigger product.
Does the CISA Secure by Demand Guide cover AI agents?
No. CISA and the FBI wrote it in August 2024 for software customers in general. Use it as your base list, since its questions on logs, parts lists, flaw disclosure, and open-source checks all apply, then add AI-specific questions on models, data use, agent identity, and log export.
What if a vendor refuses a proof of value?
Treat the refusal as data. A vendor that trusts its product will usually agree to a limited test against one named control. A vendor that won't is asking you to buy on a slide deck, which is the exact thing you're trying to avoid.
How do I tell a real agent product from agent washing?
Ask what the product does without a person clicking. If the answer is a chatbot with a new label, it's agent washing. Then ask for the same evidence you'd ask from anyone else: named customers of your size, logs you can export, a written answer on which models sit underneath, and a test on your own data.
Peer references will come, in time. Until they do, the evidence has to come from the vendor, in writing, before you sign.