At a glance
- A generic SaaS security questionnaire misses what's specific to an AI build: training-data use, credential handoff, prompt injection, and model-version change control.
- The procurement checklist below covers eleven questions, each with why it matters, a good answer, and a red flag — usable on its own in a vendor review.
- Agents that read untrusted content (email, tickets, documents) carry a distinct risk: indirect prompt injection, where hidden instructions try to redirect the agent.
- Score answers against the stated red flag, not against confidence or polish; a vague answer to a specific question is itself the finding.
Why AI changes the security review
A security review for a standard SaaS vendor covers hosting, access, and contract end. An AI implementation partner needs those same questions, plus a set no standard questionnaire covers.
The reason is architectural: an agent needs access to systems a SaaS tool never touches, and processes untrusted input as part of its job. NIST's generative AI profile frames the resulting risk directly: such systems face information-security risk because GAI "expands the available attack surface, as GAI itself is vulnerable to attacks like prompt injection or data poisoning"[1]. Add these questions to your existing vendor review.
The procurement checklist
Use this table as a standalone review document: eleven questions, why each matters, a good answer, and the answer that should stop the review. The "good answer" column describes what any competent partner should state, not one vendor's certifications.
| Question | Why it matters | A good answer | A red flag |
|---|---|---|---|
| Where does our data reside, and how long is it retained? | Prompts and outputs can pass through infrastructure — model-provider API calls, vector stores, logs — that the original contract may not name; check whether it's covered. | Names the specific systems and regions data passes through, including model-provider API calls, and states a retention period with a deletion mechanism. | "It's all handled securely" with no named systems, regions, or retention period. |
| Will our data be used to train any model? | Ask whether data sent to the model provider's API is retained or used for training by default — don't assume either way. | States plainly whether prompts or documents train the model, names the applicable terms, and confirms an opt-out or zero-retention setting where available. | "We follow the model provider's standard policy" without saying what that policy is. |
| Who are the subprocessors and model providers, and how were they vetted? | NIST notes GAI value chains "involve many third-party components such as procured datasets, pre-trained models, and software libraries"[1], which "might be improperly obtained or not properly vetted, leading to diminished transparency or accountability for downstream users"[1] — risk the buyer inherits without selecting the component directly. | Provides a current list of subprocessors and model providers, including how each was reviewed. | A refusal to name the model provider or any subprocessor "for competitive reasons." |
| What credentials will the team hold, and when are they revoked? | If the build team gets elevated access to core systems, that access has to end on a known date. | Names each credential or account issued, its scope, and a specific revocation trigger (go-live, contract end, or a fixed date), confirmed in writing. | "We'll clean that up at the end," with no named account, scope, or confirmed revocation date. |
| How is least privilege enforced for the system itself, not just the build team? | An agent's own permissions should match its task, not the developer's convenience. OWASP recommends teams "limit the permissions that LLM extensions are granted to other systems to the minimum necessary in order to limit the scope of undesirable actions"[4]. | Describes scoped, task-specific permissions under the invoking user's own authorization — OWASP's own recommendation is to "track user authorization and security scope to ensure actions taken on behalf of a user are executed on downstream systems in the context of that specific user, and with the minimum privileges necessary"[4], not a shared elevated account. | Everything routes through one broad service account with standing write access. |
| How is prompt injection handled for agents that read untrusted content? | An agent reading email, tickets, or documents can encounter instructions an attacker planted in that content, not just in the user's own prompt. | Names specific controls: treating retrieved content as data rather than instructions, constraining what actions a single interaction can trigger, and logging attempts. | "Our model is trained to ignore bad instructions" as the entire answer, with no architectural control named. |
| What logging and audit trail exists for agent actions? | A reviewer needs a record of what an agent did, on what input, and under whose authorization. | Describes a log of actions, the input that triggered them, and the authorizing user, retained for a stated period. | "Logs exist" with no description of what's captured or how to access them. |
| What is the incident notification process and timeline? | You need a committed notification path before an incident happens, not one improvised during it. | States a specific notification window, the contact path, and what the first notice will contain. | No stated timeline, or a vague "we'll let you know if something happens." |
| How are model or version changes controlled and communicated? | A silent model or version swap can change the system's behavior without any code change on your side. | Describes testing before a model or version change goes live, plus advance notice to your team. | Model or version changes roll out automatically with no notice or re-testing. |
| What evaluation evidence exists before go-live? | Claims about accuracy or safety are only as good as the test that produced them. | Shares the test design, sample, and results from your own workflow or a representative one, not marketing figures. | Only vendor-wide benchmark numbers, with nothing specific to your workflow. |
| What happens to our data and access on exit? | A security review has to cover the end of the relationship, not just its start. | Commits to a data return or deletion process, a fixed timeline, and confirmation all credentials are revoked. | No defined exit process, or one that depends on you remembering to ask. |
Data handling questions
Three rows deserve more detail, because a vague answer to them is easy to miss. Sensitive information disclosure is a named risk category in OWASP's Top 10 for LLM Applications, covering "personal identifiable information (PII), financial details, health records, confidential business data, security credentials, and legal documents"[2] moving through an LLM application. The same guidance recommends that "LLM applications should perform adequate data sanitization to prevent user data from entering the training model"[2].
- Ask whether prompts or documents train the model, and for the specific policy, not just confirmation one exists.
- Ask for an opt-out or zero-retention setting; OWASP recommends that "Application owners should also provide clear Terms of Use policies, allowing users to opt out of having their data included in the training model"[2].
NIST makes a related point about training data generally: "most model developers do not disclose specific data sources on which models were trained, limiting user awareness of whether personally identifiably [sic] information (PII) was trained on and, if so, how it was collected"[1]. Don't accept "industry standard" as the answer.
Subprocessors and model providers carry the same risk one step removed. OWASP's supply-chain category notes that "LLM supply chains are susceptible to various vulnerabilities, which can affect the integrity of training data, models, and deployment platforms"[3]. A partner who won't name the provider touching your data may not have mapped their own supply chain.
Agent-specific risks
On credentials: treat the build team's elevated, temporary access to core systems like any other privileged access grant — a named scope and a revocation trigger, not a promise to "clean up" access later (see the checklist row above).
On prompt injection: the risk depends on where a prompt comes from. NIST distinguishes direct attacks, where "attackers might craft malicious prompts and input them directly to a GAI system,"[1] from indirect ones, which "occur when adversaries remotely (i.e., without a direct interface) exploit LLM-integrated applications by injecting prompts into data likely to be retrieved"[1]. An agent reading email or documents faces the indirect kind.
Change control and evidence
The last checklist rows cover after go-live: whether the system keeps running as tested, whether you'd hear about a problem, and what you get back at the end.
NIST's suggested action for AI governance (GV-1.6-003) asks organizations to consider specific items in GAI system inventory entries, including "data provenance information (e.g., source, signatures, versioning, watermarks) ... [and] underlying foundation models, versions of underlying models, and access modes"[1]. Ask your partner to commit to notifying you before a change, not just to keeping their own internal inventory of it.
- On incident response, NIST suggests organizations "establish organizational policies and procedures for after action reviews of GAI system incident response and incident disclosures, to identify gaps"[1].
- The Guidelines for Secure AI System Development, jointly published by the UK's National Cyber Security Centre (NCSC) and the US Cybersecurity and Infrastructure Security Agency (CISA) with international partners, cover deployment as "protecting infrastructure and models from compromise, threat or loss, developing incident management processes, and responsible release"[6], and live operation as "logging and monitoring, update management and information sharing"[6]. A vendor without a named incident process and a live logging practice hasn't covered these stages.
Scoring the answers, and the red flags that matter most
Score each answer against its stated red flag, not how confident or polished it sounds.
- A named answer beats a general one: a specific access scope and revocation date is a good answer; "we follow least-privilege principles" is not.
- A refusal to name a subprocessor, model provider, or specific control is itself a finding, whatever reason is given.
- An answer describing what the model is trained to do, instead of what the system enforces, is incomplete on injection, access, or output questions.
Treat any red-flag answer as a stop condition, not a point to negotiate down. An experienced partner should answer all eleven without hesitation.
When this checklist doesn't apply
- A deterministic automation with no model in the loop and no untrusted-content access — these questions target model- and agent-specific risk, not scripting or RPA.
- Your organization already runs an equivalent AI-specific review; use this checklist to check for gaps, not to replace it.
- A pilot on synthetic or public data with no production access — apply the full review before the system touches real credentials or data.
Frequently asked questions
What security questions should you ask an AI vendor?
Ask where data resides, whether it trains any model, who the subprocessors and model providers are, what credentials the build team holds and when they're revoked, how prompt injection is handled, and what logging, incident-notification, and exit processes exist. The checklist above turns all eleven into a single table you can hand to a vendor.
Will our data train models?
Ask directly, rather than assuming: whether data sent to the model provider's API is retained or used for training depends on the provider's terms and your account settings; ask for both. A good answer states the policy plainly and confirms an opt-out or zero-retention setting where one exists; "we follow standard policy" without naming it is a red flag.
What credentials will the team hold, and when are they revoked?
Any temporary, elevated access a build team gets to integrate with your core systems should end on a known date. Ask for each account or credential issued, its specific scope, and a concrete revocation trigger — go-live, contract end, or a fixed date — confirmed in writing, not a general promise to "clean up" access later.
How is prompt injection handled for agents reading email?
An agent that reads email or other untrusted content can encounter attacker-planted instructions inside that content, not just in the user's own prompt — this is indirect prompt injection. A good answer names specific controls: treating retrieved content as data rather than instructions, limiting what one interaction can trigger, and logging flagged attempts.
What are red-flag answers?
A red flag is the answer named in the checklist's red-flag column: often a vague answer like "we take security seriously," but sometimes a concrete bad practice — a shared service account with standing write access, or model changes that roll out with no notice. Treat any red-flag answer as a reason to stop the review, not negotiate it.
Related reading
- This checklist is security-specific. For the broader commercial and ownership questions to ask before signing, see 10 Questions to Ask an AI Consulting Firm Before You Sign.
- AI agent implementation describes how a system like the ones this checklist reviews is scoped, integrated, and handed over, with human-in-the-loop controls built in from the start.
- For how audit trails and human checkpoints work once the system is live, see Human-in-the-Loop AI Governance: Where People Must Stay in the Decision.
Sources
- National Institute of Standards and Technology, Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile (NIST AI 600-1, 2024) (accessed 2026-09-30)
- OWASP Foundation, LLM02:2025 Sensitive Information Disclosure — OWASP Top 10 for LLM Applications (accessed 2026-09-30)
- OWASP Foundation, LLM03:2025 Supply Chain — OWASP Top 10 for LLM Applications (accessed 2026-09-30)
- OWASP Foundation, LLM06:2025 Excessive Agency — OWASP Top 10 for LLM Applications (accessed 2026-09-30)
- OWASP Foundation, LLM01:2025 Prompt Injection — OWASP Top 10 for LLM Applications (accessed 2026-09-30)
- UK National Cyber Security Centre, Guidelines for Secure AI System Development (accessed 2026-09-30)
More in Agent governance
Build vs. Buy AI E-Commerce Back Office Automation: Point Tools vs. an AI Implementation Partner
Build vs buy AI e-commerce back office automation: a six-factor decision table comparing packaged tools with an AI-agent layer, plus how to scope one workflow.
Ecommerce OperationsBuild vs. Buy AI for the Energy and Utilities Back Office: AI Agents vs. Entrenched Land, JIB and Billing Software
Build vs buy AI for the energy and utilities back office: a five-factor decision table comparing land, JIB and billing software with an AI-agent layer.
Utilities and Energy CompaniesAI Agent Approval Gates for Finance: A Role and Action Matrix
AI agent approval gates for finance: which actions an agent may do, suggest, or never touch, who approves each one, and what evidence to keep.