On 29 October 2026, developers who used the Cursor editor received what looked like a routine update to Anthropic’s official Claude Code extension. For about eleven hours, the version served through the Cursor Marketplace carried a loader that added an attacker’s SSH key to each machine and sent host details to an outside server. Nobody had approved a new vendor. The tool was already trusted, and so was the store it came from. An AI vendor risk assessment gives the risk team a way to see who and what sits behind an AI tool, and decide what it means before an incident decides for them.
What is an AI vendor risk assessment?
An AI vendor risk assessment is the part of third-party due diligence that examines how a supplier builds, uses, and governs artificial intelligence inside the service you buy. Data use, model sourcing, output reliability, and AI-specific controls all fall inside its scope, alongside the standard security assessment. Vendors that sell an AI product qualify, and so do vendors that quietly added AI features to one you already use.
Your existing vendor risk assessment still matters, since encryption and incident response stay relevant when a product gains a model. What changes is the set of questions those controls leave open, such as whether your data trains anything and who else processes it.
Why does AI vendor risk need its own review?
AI adds three exposures a traditional questionnaire rarely reaches. Your data may be retained or used to train models, the vendor may depend on model and platform providers you never assessed, and the output itself can be inaccurate or manipulated. The incidents tracked by the Panorays Threat Center in October 2026 show the second exposure clearly.
The Claude Code extension compromise reached users through the Cursor Marketplace, a distribution channel most vendor reviews never list. Cursor’s security notice confirmed that the malicious version was limited to its marketplace and affected at most 5,000 installs, and Panorays’ own analysis of the Cursor Marketplace attack covers what it means for supplier programs. Days earlier, the hosting platform Railway disclosed that an intruder may have obtained decrypted environment variables, the API keys and credentials its customers store there, and described the intrusion as part of a campaign against platforms that serve AI inference providers. Neither was a breach of the AI vendor itself. Both sat one step behind it.
Governance has not caught up. In IBM’s 2025 Cost of a Data Breach research, 13% of organizations reported a breach involving an AI model or application, and 97% of those lacked proper AI access controls. High levels of shadow AI added USD 670,000 to the average breach cost.
NIST’s Generative AI Profile (AI 600-1), published in July 2024, lists value chain and component integration as its own risk category, covering third-party models and data that are hard to inspect. For a risk team, the vendor’s model provider is a fourth party in everything but the contract.
Which vendors need the full AI review?
Start with the relationship, then the technology. A vendor needs the full AI review when its AI processes regulated or confidential data, influences decisions about customers, patients, or employees, or runs inside a critical business process. Vendors whose AI touches none of those can take a shorter set of questions and a lighter evidence bar.
A transcription tool used by marketing and a credit-decisioning platform both “use AI,” and only one of them can produce a regulatory finding if its model drifts. Inherent risk tiering already sorts vendors by data access and criticality. So adding AI exposure as a factor in that tiering sends the deep review where the impact is.
What questions should you ask an AI vendor?
Ask questions that reveal four things about the vendor’s AI. What it does with your data, which outside models it relies on, how the vendor tests and monitors output, and who is accountable when something goes wrong. Each answer should come with evidence, such as a policy, a contract clause, or a test report, and a plain yes or no should not close the item.
These eight requests cover most reviews:
- Data use. Confirm in the contract whether your data trains or fine-tunes any model, and how long prompts and outputs are retained.
- Model sourcing. Get the list of foundation models and AI providers behind the feature, where they are hosted, which marketplaces deliver its updates, and a commitment to notify you before any of these change.
- Access control. Ask how AI service accounts and API keys are scoped and logged, and who can query the model with your data.
- Output reliability. Request evidence of testing for inaccurate output, prompt injection, and data leakage between customers.
- Human oversight. Find out where a person reviews AI output before it affects a decision about your customers.
- Governance. Ask for the written AI policy and any ISO/IEC 42001 certification or mapping to the NIST AI RMF.
- Regulation. For EU-facing vendors, ask how they classify the system under the EU AI Act, in force since 1 August 2024 with obligations phasing in over several years.
- Incidents. Agree how and how fast the vendor will report an AI-related incident.
FS-ISAC publishes a free generative AI vendor evaluation tool that many financial institutions use as a starting template. Panorays’ guide to vendor assessment questionnaires shows how to fit AI questions into the frameworks you already send.
Where do AI vendor reviews go wrong?
The most common miss is timing. Teams assess AI at onboarding and never again, while vendors add generative features through ordinary product updates. A supplier approved in 2024 as a plain workflow tool may now send document content to an external model, and the vendor record still describes the old product.
The second miss is treating a certificate as the whole answer. An ISO/IEC 42001 certification shows the vendor runs an AI management system, which is useful evidence. But it says little about how that system treats your data under your contract, so read the certificate’s scope and keep asking the data-use questions.
The third is sending every AI vendor the same long questionnaire. Uniform depth produces slow responses, thin answers, and reviewers who skim. Matching depth to the relationship gets better evidence from the vendors that matter, and the NIST AI Risk Management Framework gives you a shared vocabulary with your governance team.
How do you keep the assessment current?
Set two triggers alongside the annual review. One fires when a vendor announces a new AI capability and the other when it changes a model provider. Either should reopen the AI section of the assessment and, where the data flow changed, the contract. Ask vendors to commit to that notice in writing.
Between triggers, continuous monitoring covers what questionnaires cannot. External signals such as new AI integrations or a cyber event at a model provider can show that a vendor’s AI footprint moved before the vendor tells you.
The third-party cyber risk lens on AI vendors
AI risk is one more dimension of the question third-party cyber risk management always asks, namely what a specific relationship exposes and how much attention it deserves. The answer depends on the data the vendor touches and the decisions its output shapes. Two vendors running the same model can carry very different risk for your business, which is why contextual risk scoring matters here.
Panorays treats AI exposure as one input to that picture. Its third-party AI risk assessment identifies which suppliers use AI, applies questionnaires aligned to ISO 42001, the NIST AI RMF and the EU AI Act, and factors AI exposure into vendor tiering alongside the cyber assessment.
To see how AI exposure fits into vendor tiering, visit panorays.com.
AI Vendor Risk Assessment FAQs
Which frameworks apply to an AI vendor risk assessment?
Most teams anchor on three. The NIST AI Risk Management Framework and its Generative AI Profile give a common risk vocabulary. ISO/IEC 42001 sets the requirements for an AI management system that a vendor can be certified against. The EU AI Act applies to vendors placing AI systems on the EU market, with obligations phasing in over several years.
What if an AI vendor will not share model details?
Ask for the outcome instead of the internals. A vendor may decline to name a model, but it should still state whether your data trains anything, where processing happens, how output is tested, and how it will notify you of changes. If it cannot answer those in writing, record the gap and tier the vendor higher until it can.
Does ISO 42001 certification replace the AI vendor review?
No. ISO/IEC 42001 certification is strong evidence that a vendor runs a managed AI program, and it can shorten the governance section of your review. It does not describe how the vendor handles your specific data under your contract, so the data-use, model-sourcing, and incident questions still need direct answers.
How often should you reassess an AI vendor?
Reassess on a schedule set by the vendor’s tier, often annually for the highest tier, and also whenever the vendor adds an AI capability or changes a model provider. Those event triggers matter more than the calendar, because AI features usually arrive through routine product releases and seldom through contract renewals.
Do you need a separate questionnaire for AI vendors?
Usually a separate AI section works better than a separate questionnaire. Keep the standard security questions, and add an AI module that only goes to vendors whose products use AI. That keeps response times reasonable for low-risk vendors while giving high-risk relationships the depth they need.
