Enterprise buyers increasingly send AI-specific security questionnaires before they approve an AI product. The questions vary, but the pattern is consistent: they want to know what your AI can see, what it can do, how it was tested, what failed, what was fixed, and what risk remains.
This guide is a practical way to answer those questionnaires without overclaiming. It is written for founder-CTOs, security owners, and product teams that need to turn an AI security review into buyer-ready evidence.
The buyer is really asking six things
Most AI questionnaire sections reduce to six questions:
- What AI surfaces are in scope?
- What data can the AI see or retrieve?
- Can the AI take actions, call tools, or affect records?
- How do you test prompt injection, leakage, RAG, agents, and unsafe output?
- What evidence proves the controls and fixes?
- What risk remains after testing?
If your answers do not include scope and evidence, the buyer has to guess. If they have to guess, the questionnaire tends to stall.
The answer format that works
Use this structure for each material AI risk:
| Field | What to write |
|---|---|
| Scope | The product surface, model path, retrieval source, agent workflow, tool, tenant boundary, or environment covered. |
| Control | The actual control: authorization before retrieval, least-privilege tool, eval gate, rate limit, logging, approval step, or output validation. |
| Evidence | Request traces, eval results, test cases, finding IDs, screenshots only where useful, and retest status. |
| Limit | What was not tested or what still requires operational judgment. |
| Owner | Who owns the control or remediation internally. |
This turns a questionnaire answer from marketing copy into a small assurance record.
Questions buyers ask about model behavior
Typical questions:
- How do you test prompt injection and jailbreaks?
- Can users extract the system prompt or hidden instructions?
- How do you prevent sensitive information disclosure?
- How do you validate model outputs before users or workflows trust them?
- How do you detect model behavior regressions?
Weak answer:
We rely on the model provider’s safety systems and prompt guardrails.
Stronger answer:
We test direct and indirect prompt injection against the product workflow, including retrieved content and tool outputs. Confirmed findings are recorded with request traces and retested after fixes. Regression cases are added to an eval set for release gating.
The stronger answer is bounded. It says what was tested and how evidence is kept. It does not claim the model cannot be manipulated.
Questions buyers ask about RAG and data access
Typical questions:
- What documents or data sources can the AI retrieve?
- Are tenant, user, role, and document permissions enforced before retrieval?
- Can one customer retrieve another customer’s content?
- Are citations verified against authorized sources?
- Can retrieved documents inject instructions into the model?
Good answers name the retrieval boundary. For example:
Retrieval is scoped server-side by tenant, user, role, and document permissions before content enters the model context. We test cross-tenant retrieval, missing metadata filters, fallback retrieval, cache behavior, citation integrity, and indirect prompt injection through retrieved documents.
If you cannot say where authorization happens, the buyer will assume it is not enforceable.
Questions buyers ask about agents and tools
Typical questions:
- Can the AI call tools or take actions?
- What tools can it reach?
- Do tools authorize against the user or against a broad service account?
- Which actions require human approval?
- Are tool calls logged with enough context to reconstruct an incident?
The safest answer separates model instruction from server-side authorization:
The model can request a tool call, but the tool service enforces user, tenant, role, object, and business-policy checks outside the prompt. Sensitive and state-changing operations require external confirmation or policy gates. Tool-call traces include the initiating user, model turn, arguments, authorization decision, result, and final response.
This is the difference between “the prompt tells it not to” and “the system will not let it.”
Questions buyers ask about MCP
For MCP-connected systems, buyers increasingly ask:
- Which MCP servers are in scope?
- What tools, resources, and prompts are exposed?
- Are secrets visible to the model?
- Are resources scoped before they enter context?
- Do local and remote MCP deployments have different trust assumptions?
Answer with an inventory, not a general claim:
We maintain a server, tool, resource, prompt, and credential inventory for MCP-connected workflows. Sensitive reads and writes require server-side authorization, resources are scoped before model context assembly, and destructive operations require external confirmation or policy checks.
Then attach evidence from a focused MCP review if the buyer needs it.
Questions buyers ask about evals
Typical questions:
- Do you evaluate model outputs before release?
- What happens when a prompt or model changes?
- Can a failed eval be waived?
- Do you test security regressions after a fix?
A credible answer does not need a huge benchmark. It needs targeted cases tied to real risk:
We maintain eval cases for the behaviors that matter to the product: refusal boundaries, grounding, structured output validity, prompt-injection regressions, RAG leakage, and tool-use safety. Confirmed findings are added as regression cases before closure, and retest status is recorded in the assessment report.
If there is no eval set yet, say that and make it part of the fix plan.
Questions buyers ask about evidence
Buyers often ask for “proof” without specifying the artifact. The strongest package is usually:
- Scope and system map.
- Threat model and framework mapping.
- Findings with reproduction steps and traces.
- Fix plan with owners and priority.
- Retest status.
- Residual risk statement.
This is exactly what an AI security assessment report should contain. The sample AI assessment report shows the shape of that artifact.
What not to write
Avoid answers like:
- “Our AI is safe.”
- “We use OpenAI/Anthropic/AWS, so model security is handled.”
- “Prompt injection is impossible because our system prompt forbids it.”
- “We have guardrails” without test evidence.
- “No findings” without scope, dates, and tested surfaces.
- “SOC 2 covers this” when the question is about AI product behavior.
Those answers may be true in spirit, but they do not help a buyer evaluate risk.
When to get an assessment
Get an assessment when the questionnaire asks for evidence you do not already have:
- AI red-team evidence.
- Prompt-injection testing.
- RAG leakage testing.
- Agent tool-permission review.
- MCP server/tool/resource review.
- Eval baseline and regression gates.
- Retest status after fixes.
For a buyer deadline, use the AI Security Review Before Enterprise Procurement. For a startup-specific entry point, use the AI Security Assessment for Startups. If the buyer calls it a pentest, clarify the scope with AI penetration test vs AI red team.