Pushback Your Vendor Should Survive
The Hallucination Question
"What is your hallucination rate?" is a question every AI security vendor should expect, and few answer well. A good answer sounds like engineering: outputs are grounded in retrieved evidence with citations you can click through, formats are constrained and validated, the rate of unsupported claims is measured against a labelled set, and here is the number with its methodology. An evasive answer sounds like reassurance: "our model is highly accurate", "we use the latest models", "we have guardrails" — with no measurement behind any of it. Note the difference in kind: the good answer describes a system that assumes the model will fabricate and contains it; the evasive answer hopes it will not. In a SOC, hoping is not a control.
- Good answers cite grounding, constrained outputs, and a measured rate with methodology
- Evasive answers offer adjectives — "accurate", "cutting-edge", "guardrails" — without numbers
- Click through the citations in a live output: do they actually support the claim?
- The architecture should assume fabrication and contain it, not deny it
Who Answers for a Wrong Autonomous Action?
The moment a product can act — close an alert, disable an account, isolate a host — the question becomes liability. Ask directly: when your agent takes a wrong autonomous action and it causes damage, what does the contract say? Good answers exist in the mechanics even where liability caps are standard: every autonomous action is attributable and reversible, destructive actions default to approval-gated, action scopes are configurable by you, and there is an incident process with the vendor on the hook for root cause. Evasive answers relocate all responsibility to your configuration choices while marketing autonomy as the headline feature. If the pitch is autonomy and the contract says it is your fault, the two documents describe different products. Believe the contract.
- Ask what the contract, not the datasheet, says about wrong autonomous actions
- Reversibility and attribution are the minimum bar for any action-taking feature
- "You configured it" as a liability position contradicts an autonomy-led pitch — surface that tension
- Get the incident process in writing: who investigates, who discloses, on what clock
Residency, Keys, and the Subprocessor Chain
Data residency questions have moved from checkbox to architecture. Ask where inference runs — not where data is stored, but where the model actually processes it, which is frequently a different region and sometimes a different company. Ask for the full subprocessor chain: many AI security products are a thin layer over a third-party model API, and your alert data transits infrastructure that never appears in the vendor's own diagrams. Ask who holds the encryption keys and what revocation actually severs. Good answers name regions, name subprocessors, and offer real key control. Evasive answers say "we are compliant" — but compliance frameworks lag AI data flows by years, and "compliant" is not an architecture.
- Storage residency and inference residency are different questions — ask both
- Demand the subprocessor list: the model API behind the product is part of your data flow
- Key control is only real if revocation provably severs access
- "We are compliant" answers an audit question, not the architecture question you asked
Who Controls Model Changes?
The product you evaluate is not the product you will be running in a year — the vendor will swap models, update prompts, and retune thresholds, and each change can shift detection behaviour under your feet. The pushback: what is your model-change control process? Good answers include advance notice for material changes, published regression testing against detection benchmarks, per-tenant version pinning or staged rollout, and changelogs specific enough to audit. Evasive answers frame silent continuous change as pure upside — "you always get our latest improvements" — with no mechanism for you to test, defer, or even know a change happened. Your detection stack is change-managed; a vendor whose AI layer is not is asking you to accept an unmanaged dependency in the middle of it.
- Model swaps change detection behaviour — treat them as changes requiring notice and testing
- Ask for regression results across model versions, not just release notes
- Version pinning or staged rollout shows the vendor engineered for enterprise change control
- "Always the latest model" without notice means your baseline shifts silently
Prefer slides, quizzes, and saved progress? Read this lesson in the library — free, no sign-up.