Vendor Risk Assessments for AI Tools: What to Ask

Why Your Standard Vendor Checklist Fails AI Tools

Your vendor passed every check on the standard questionnaire — SOC 2 clean, SIG complete, CAIQ signed off. Yet none of those documents tell you where your data actually goes once it enters an AI tool, and that gap is costing companies millions.

Traditional third-party risk frameworks assume data stays inside the vendor's app, the product only does what users click, and the software is stable week to week. AI vendors break all three assumptions: data flows onward to model providers, products execute multi-step autonomous actions, and models and features change constantly. A vendor can hold a clean SOC 2, encrypt everything at rest, and still route customer records to a third-party model, retain embeddings indefinitely, and let any employee build automations on top of your CRM, as Reco's security team documents.

The consequences show up in the breach data. According to the IBM Cost of a Data Breach Report, 13% of organizations reported breaches involving AI models or applications — and 97% of those breached organizations lacked proper AI access controls. Meanwhile, 1 in 5 organizations reported a breach caused by shadow AI, and Gartner projects that by 2027, more than 40% of AI-related data breaches will stem from improper cross-border use of generative AI. Supply chain compromises now average $4.91 million per incident.

The verification gaps are where standard checklists fail hardest. Reco documented real cases: a vendor claimed a "proprietary model" that inventory revealed was actually GPT-3.5 Turbo, and a "read-only" CRM integration turned out to be connected to Salesforce, Slack, and GitHub. As Reco puts it, questionnaire answers are claims made on one day about a product that changes weekly — and "the fix is not a longer questionnaire" but verifying claims against your own environment.

What a clean SOC 2 tells you:

• Whether the vendor's controls are audited — not whether your data trains someone's model
• That the product was secure at audit time — not what an autonomous agent can do today
• That the vendor follows security practices — not where your data actually flows downstream

AI-specific risks need AI-specific questions — training-data provenance, data leakage, agent permissions, and model governance — categories that traditional TPRM programs "often miss," per GRF CPAs & Advisors. The same principle applies to the agent skills and tools your teams bolt onto AI coding agents: published research found roughly 26% carry at least one vulnerability. SkillzBench is being built to close exactly this verification gap — pinning every skill version to a commit SHA, security-scanning, and re-benchmarking on upstream changes — so the claims on the label match the code you actually run.

The Questions That Actually Expose AI Risk

A clean SOC 2 report tells you how a vendor handled data last year, not how their AI behaves today. Traditional assessments miss the dynamic, autonomous nature of modern AI tools, leaving critical gaps in your risk profile.

You need questions that expose how models learn, what agents can touch, and what happens when things break. Reco’s framework, for instance, uses 40 questions across six domains to score vendor responses on a strict 0-to-2 scale. This approach moves beyond simple yes-or-no answers to demand specific evidence of control.

Consider the risk of data leakage. Vendors might claim they never train on your data, but security researchers warn that these claims often exclude sub-processors and feedback loops. Without verifying these exclusions, your company information could be learned and shared with other users by the vendor’s AI.

Training data provenance is a critical knock-out zone. If a vendor cannot confirm the source of their training data, the risk is unmanageable. Reco’s scoring rubric dictates that any zero score in training-data domains triggers an automatic decline. You cannot contractually guarantee what you cannot verify.

Agent permissions represent another major exposure. For autonomous tools, permission management matters more than prompt-injection defense because an injected instruction can only do what the agent’s permissions allow. You must ask for per-tool allow-lists and least-privilege configurations to limit the blast radius of a compromised agent.

Vague answers are themselves a risk signal. A vendor that cannot explain when their model is likely to fail isn't ready for production use. Treat missing or evasive responses as high-risk indicators that require immediate follow-up or escalation.

To score these answers effectively, use a defined rubric. VDF AI recommends a 0-to-3 scale where 3 indicates independently verified evidence. Proceed with a vendor only if the weighted average is above 2.0 and no knock-out questions failed.

< ul class="blog-list">

The ultimate test is contractual commitment. A vendor that answers well but refuses to put those answers in the contract has told you what they're worth. Require clauses that restrict client data use for training and include bias mitigation obligations.

Independent verification is essential because AI products change weekly. This is the principle behind SkillzBench, which is building a directory to pin agent skills to specific commit SHAs and security-scan them. By verifying that a skill actually does what it claims, you mitigate the risk of third-party components that lack proper oversight.

From Answers to Evidence: Contracts, Verification and Reassessment

A questionnaire filled out on a Tuesday tells you what a vendor believed on that day — nothing about what ships next week. Three controls turn those answers into something you can actually rely on: contractual commitment, independent verification, and disciplined reassessment.

The contract is the ultimate test. As practitioner guidance on AI vendor due diligence puts it, a vendor that answers 39 questions well but refuses to put those answers in the contract has told you exactly what they're worth. Contract language should restrict client data use for training external models, include bias mitigation obligations, a right to audit, and clean termination clauses, per analysis from GRF CPAs & Advisors.

Marketing claims deserve the same skepticism. "We never train on your data" only means something if the clause covers sub-processors, feedback loops, and abuse-monitoring logs. Reco documented real verification gaps: one vendor claimed a proprietary model while environment inventory showed GPT-3.5 Turbo, and another described as "CRM read-only" was actually connected to Salesforce, Slack, and GitHub. The fix isn't a longer questionnaire — it's checking claims against your own environment, the one source a vendor cannot edit.

• Put the questionnaire answers in the contract, not just the email thread.
• Verify claims against live telemetry in your own environment.
• Reassess annually at minimum, with trigger-based reviews for model swaps, new sub-processors, or new AI features.
• Re-classify tools approved pre-AI — quietly shipped AI features are the most commonly skipped risk.

Reassessment matters because AI systems change faster than traditional software. Annual review is the floor; a model swap or new sub-processor should trigger an early look. This is a legal necessity, not best practice: employers can be held accountable for the effects of third-party AI tools even if they didn't develop the algorithm, and a federal judge on May 16, 2025 allowed a class action against Workday under the Age Discrimination in Employment Act — one of the first major tests of anti-discrimination law applied to automated decision-making. On the regulatory side, the EU AI Act introduces role-specific obligations for deployers as well as providers, so knowing what your vendor's model does is part of your own compliance posture.

The same verification-over-claims principle applies to smaller third-party components like agent skills. SkillzBench is building exactly this discipline for skills: pinning every version to a commit SHA, security-scanning, and re-scanning on upstream changes — so browse and test free ones on SkillzBench when you want evidence rather than promises.

Agent Tools: Judge Permissions, Not Prompt-Injection Promises

An injected instruction inside a poisoned document can only do what the agent's permissions already allow. That single sentence explains why the smartest vendor assessments now treat permission scoping as the primary control for AI agents, not prompt-injection filtering.

For agent-based tools, current security guidance is blunt: permission management matters more than prompt-injection defense, because least privilege and per-tool allow-lists cap the blast radius of any hijacked instruction. OWASP's 2026 list reflects that shift — Excessive Agency climbed to LLM03, and a separate Top 10 for Agentic Applications now covers Tool Misuse (ASI02) and Identity/Privilege Abuse (ASI03).

The stakes are measurable. According to IBM's 2025 Cost of a Data Breach findings, 13% of organizations reported breaches involving AI models or applications, and 97% of those breached organizations lacked proper AI access controls. Meanwhile, 1 in 5 reported a breach tied to shadow AI — tools nobody formally approved.

When you assess an agent vendor, ask permission questions that demand evidence:

• What exactly can this agent read, write, send, and delete — and is that scope enforced per tool?
• Does the vendor support per-agent allow-lists, so an agent only sees the tools you explicitly enable?
• Can permissions be revoked or narrowed without disabling the whole agent?
• Who can create new automations on top of your data, and what limits apply?
• Will the vendor commit these permission boundaries in the contract, not just the questionnaire?

That last point matters most. Questionnaire answers are claims made on one day about a product that changes weekly — verification against your own environment is the only test a vendor cannot edit. If a vendor answers well but refuses to put those answers in writing, you have learned what the answers are worth.

The same logic applies to the agent skills and third-party components your agents load. SkillzBench is building independent verification for exactly this: pinning every skill version to a commit SHA, security-scanning each one, re-scanning when upstream changes, and publishing trust scores with benchmarked Lift shown separately from ratings. Permissions decide what an agent can do; verified components decide what it should.

Skills, proven — join the waitlist to evaluate agent skills with evidence, not vendor claims.