July 9, 2026 · 14 min read
The 20 AI security review questions enterprises ask vendors, and how to answer each
Enterprise vendor security reviews grew an AI section in 2026. If you sell an AI agent product to a bank, a hospital, an insurer, or any large company, this block of questions now sits between your signed champion and your signature. The industry standardized it fast: CSA's AI-CAIQ carries 320 such questions, and procurement teams copy from it.
Below are the 20 questions AI vendors actually report seeing, grouped the way reviewers group them, with what the reviewer wants behind each one. The pattern that carries the whole section: answer from your real stack, name mechanisms instead of policies, and state gaps honestly with a remediation date. Reviewers accept roadmaps. They do not accept discovering an overstatement later. (Companion piece: what evidence buyers actually accept.)
Inventory and provenance (questions 1–3)
Every AI section opens with inventory. The reviewer is testing whether you can enumerate your own AI surface: which models, which agents, where hosted, who owns the weights. A vendor with no inventory reads as a vendor with no governance, and everything after this block gets read skeptically. The good news is that this is the cheapest part to fix. Write the inventory card once (model, version, hosting, provider, data-flow) and every later question inherits from it. Map it to NIST AI RMF's MAP function so the reviewer sees a framework, not a spreadsheet.
1. Provide an inventory of all AI models and autonomous agents in your product, including base model, version, hosting location, and provider.
Answer with a table, not prose: model, version, host (own VPC or provider), region, purpose. Include embedded models people forget (embeddings, OCR, rerankers). If you cannot produce this in a day, build it before answering anything else.
2. For each model: is it third-party hosted, self-hosted open-weight, or fine-tuned by you? Who owns the weights and the fine-tuning data?
This determines whose terms govern the customer's data. State ownership explicitly per model, and if you fine-tune, name the data source and the rights you hold over it. 'Provider terms apply' without naming the terms fails.
3. Describe how model and prompt changes are versioned, tested, and approved before production.
Change management, restated for models. Point at the same mechanics you use for code: version control for prompts, an eval step, a named approver. If prompts live in a dashboard nobody reviews, say what you are changing and when.
Customer data protection (questions 4–7)
This is the block that stalls deals. The reviewer wants to know exactly when their data leaves your boundary, where it lands, and what stops it from becoming someone's training set. Policy answers fail here; mechanisms pass. The strongest answers name a component: a redaction step that strips PII before any model call, a contractual zero-retention clause with each provider, tenant isolation that extends to vector stores and caches. If you run sensitive tiers fully inside the customer's or your own perimeter, say so plainly. It is the single most differentiating answer in the section.
4. Can our data reach a third-party or foreign-hosted model? Under what controls?
The sharpest question in the section. Draw the boundary: which calls leave, to whom, in which region, with what stripped. 'We trust the API terms' fails it. A data-flow one-pager attached here saves three rounds of follow-up.
5. Is customer data used to train or fine-tune any model, yours or a provider's? Show the contractual commitment.
Reviewers want the zero-retention/no-training clause quoted or attached, per provider. A policy statement without the contract behind it scores as unverified.
6. How is PII detected and handled before data leaves your boundary to any model?
Name the mechanism and its coverage: what it detects (SSN, cards, names), where it sits in the path, and what happens on detection (redact, block, log). A promise without a component is the most common failed answer.
7. How is one customer's data isolated from another's across agent sessions, embeddings, caches, and logs?
Multi-tenant isolation, extended to the places AI systems actually leak: vector stores, context windows, semantic caches. Answer per layer. If your embeddings share an index with tenant tags, say so and describe the enforcement.
Agent runtime and audit (questions 8–12)
The 2026 upgrade to 'do you have logs' is 'prove your logs were not edited.' For agent products the reviewer wants runtime evidence: what the agent can call, what it did, and whether the record survives a bad actor with database access. Tamper-evident logging (a hash chain where each entry commits to the previous one) turns this block from a weakness into the strongest part of your pack, because almost no vendor has it. Runtime enforcement beats convention: an allowlist the code enforces scores; a wiki page listing approved tools does not. Replayability is the bar for 'audit trail': for a given past action, show exactly what the agent saw and did.
8. Describe how agent actions are logged. Can the logs be altered after the fact, and how would we know?
If your logs are ordinary database rows, the honest answer is 'yes, an admin could alter them.' The passing answer is a tamper-evident chain (hash-linked entries, signatures) plus, ideally, a WORM copy the customer can hold.
9. What tools, APIs, and data sources can your agents call? How is that list enforced at runtime rather than by convention?
Capability overprovisioning is the reviewer's favorite agent risk. Enumerate the tool surface and name the enforcement point: default-deny allowlist at the proxy or runtime, not 'the prompt tells it not to.'
10. How do you defend against prompt injection causing an agent to take an unintended action or exfiltrate data?
They want layered controls, not 'the model refuses.' Layers that score: input scanning, tool allowlists, output scanning for secrets or echo-back, human gates on consequential actions, and credentials the agent never sees.
11. Which agent actions are irreversible or consequential, and what extra controls gate them?
Most vendors have never written this classification down. Do it: list the actions that move money, write to systems of record, or touch the outside world, and the gate on each (approval, dual control, rate limit).
12. Can you reproduce, for a given past decision or action, exactly what the agent saw and did?
Replayability is what 'audit trail' means to an examiner. The answer is a per-action record: inputs (or their hashes), tool calls, outputs, approvals, timestamps, chained so the sequence is provable.
Oversight and incidents (questions 13–16)
The reviewer knows models degrade and agents misbehave. This block tests whether you noticed that too. Human oversight must exist as a mechanism with records, not as a diagram: which actions pause for a person, where the approval is stored, how an override is logged. Incident response must name AI-specific failures, because your generic IR plan almost certainly does not mention a hallucinated output acted upon or a data leak via prompt. Silent degradation needs a detection story and a rollback path. And change notification turns your roadmap into their contractual right, so answer it with the clause you are willing to sign.
13. Describe human oversight for consequential agent actions. How are overrides recorded?
Human-in-the-loop with evidence: name the actions that gate on a person, where the decision is recorded, and show that the approval lands in the same tamper-evident trail as the action itself.
14. How do you detect a model or agent that degrades silently, and what is your rollback procedure?
A monitoring question in agent clothing. Name the signals you watch (eval scores, refusal rates, downstream corrections) and the rollback: pinned versions, canary, and who pulls the lever.
15. What is your incident response process for an AI-specific failure: hallucinated output acted upon, data leak via prompt, agent misuse?
Extend your IR plan with an AI annex that names these scenarios, their severity, and their notification path. Reviewers ask because almost nobody has written it. Having two pages here reads as maturity.
16. Will you notify us when you materially change models, providers, or agent capabilities?
Answer with the commitment you will sign: what counts as material, notice period, and channel. Vague 'we communicate changes' invites a redline; a concrete clause closes the thread.
Third parties and accountability (questions 17–20)
The closing block moves from engineering to accountability. Your model providers are subprocessors now, and most subprocessor lists have not caught up: the reviewer will check yours for the LLM vendors your architecture obviously uses. Governance framework questions score on ownership, not certification: a named owner operating under NIST AI RMF or ISO 42001 beats an aspirational certificate claim. Regulatory exposure (EU AI Act role, state AI laws) is a test of self-awareness. And the liability question ends the section on purpose: it is answered by your contract and defended by your evidence, which is why the audit trail you described in question 8 decides how this negotiation goes.
17. List all AI subprocessors, their locations, retention terms, and training-use commitments.
Update the subprocessor list to include every model provider, with region, retention, and the no-training commitment per provider. An out-of-date list contradicting your architecture is an instant credibility hit.
18. What framework do you operate AI governance under (NIST AI RMF, ISO 42001), and who owns it?
A named owner scores better than a certification claim. 'Our CTO owns AI risk under NIST AI RMF; here is the mapping' is a passing answer even at seed stage.
19. Which regulatory regimes reach your AI features in our deployment (EU AI Act role, state AI laws), and what is your position on each?
They are asking whether you know your own exposure. State your EU AI Act role (provider vs deployer), the risk tier of the use case, and any US state laws that touch the deployment. A short honest position beats silence.
20. If your AI causes us a loss, where does liability sit? Walk us through the clause.
The section's closing move. Answer from your MSA: the cap, the carve-outs, and what your insurance covers. Then note what makes the clause defensible in practice: the per-action evidence trail that shows what actually happened.
Answer once, before the questionnaire arrives
Every one of these questions is answerable in advance. Vendors who show up with a prepared pack (inventory card, data-flow one-pager, subprocessor list, evidence checklist) report review cycles of days. Vendors who draft answers after the questionnaire lands report six to eight weeks. If you want to see where you stand first, run the free 2-minute readiness checker (no email wall), or keep the free reference version of these 20 questions next to your draft.
And if you would rather not spend the next two weeks writing it yourself: the AI Security Review Kit turns a 30-minute intake into the full answer pack, written from your actual stack, for $490. Weighing that against a consultant or an automation tool? We compared all five ways to get the AI section answered, including the ones we do not sell.
FAQ
What is the AI section of an enterprise security review?
A block of AI-specific questions enterprises added to vendor security questionnaires in 2026, covering model inventory, training-data rights, agent action logging, PII handling, and prompt-injection defenses. CSA's AI-CAIQ standardized it with 320 questions, and procurement teams use it as the template.
Does SOC 2 cover the AI section?
No. SOC 2 attests your organization's controls. The AI section asks about your models and agents: where weights live, what your agents can touch, whether their logs are tamper-evident. Buyers send it precisely because SOC 2 does not answer those questions.
What is the hardest question in the AI section?
Vendors most often stall on data-boundary questions: can customer data reach a third-party model, and is it used for training. Reviewers reject policy language here. They want the mechanism (redaction, blocking) and the contractual zero-retention commitment.
What does tamper-evident logging mean in a security review?
Logs written so that alteration or deletion is detectable, typically via a cryptographic hash chain where each entry commits to the previous one. The 2026 upgrade to 'do you have logs' is 'prove the logs were not edited after the fact.'
How long does the AI section delay a deal?
Vendors answering ad hoc report six to eight weeks of review back-and-forth. Vendors who arrive with a prepared answer pack report days. The delay is mostly the vendor drafting answers, not the reviewer reading them.
Can we just say 'we use OpenAI, their security covers it'?
No. The reviewer's question is about your boundary, not your provider's. Passing customer data to a provider makes that provider your subprocessor, and you own the controls at the handoff: redaction, retention terms, and the audit trail of what crossed.
Compiled from vendor security reviews and public frameworks (CSA AI-CAIQ v1.1, NIST AI RMF, ISO 42001, OWASP AISVS, NIST SP 800-53). Reference only, not legal advice.