Every team now has an AI tool it loves: an app builder that turns a prompt into an internal website, an assistant connected to the company drive, a plugin that summarizes customer calls. Most arrived without a security review. AI third-party risk management is how you say yes to these tools without handing your data, your customers or your codebase to a vendor you have never assessed.
The good news is that you do not need a new discipline. You need your existing vendor risk process plus a short list of questions that AI tools make urgent.
The short version
- Classify the data the tool will see, and send it the minimum.
- Read the model terms: retention, training use and sub-processors.
- Require enterprise identity: single sign-on, provisioning and role-based access.
- Own and scan generated code like any other code.
- Test for LLM-specific risks such as prompt injection and data leakage.
- Plan the exit before you sign.
Why AI tools change third-party risk
Traditional software stores and processes your data in predictable ways. AI tools add new paths: prompts and files flow to model providers, outputs may be cached or used for training, assistants act with the permissions of whoever connected them, and app builders generate code that runs inside your environment. Frameworks such as the OWASP Top 10 for LLM Applications and the NIST AI Risk Management Framework describe these risks in depth; the checklist below turns them into vendor questions.
The AI third-party risk checklist
1. Data classification and minimization
- Which data classes will users put into the tool, and which are prohibited (customer records, health data, credentials, source code)?
- Can sensitive fields be masked or kept out entirely?
- Where is data stored and processed, and does that meet your regulatory obligations?
2. Model and data terms
- Is your data used to train or improve models? Is that the default, and can it be turned off contractually?
- How long are prompts, files and outputs retained? Is zero data retention available?
- Which model providers and sub-processors receive your data?
3. Identity and access
- Does the tool support single sign-on and automated user provisioning and deprovisioning?
- Can access be restricted by team or group, or can every user see every project?
- What can connected assistants reach on a user’s behalf, and can that be scoped down?
A common finding with AI app builders is that every project is visible to every user in the company workspace. When the internal tool someone built holds sensitive data, that is a data exposure. The fix is either the vendor adding per-project permissions and single sign-on, or your team keeping sensitive data out of the tool until it does.
4. Generated code and integrations
- Who owns code and content the tool generates, and can you export it?
- Is generated code scanned for vulnerabilities before it reaches production?
- Which credentials and API keys does the tool hold, and how are they stored and rotated?
5. LLM-specific risks
- Has the vendor tested for prompt injection, including instructions hidden in documents and web pages?
- Can the tool be tricked into revealing data from other users or other projects?
- Are risky actions, such as sending messages or changing records, gated by human approval?
6. Monitoring, incidents and exit
- Are audit logs available, and can they flow into your monitoring?
- What are the vendor’s breach notification commitments?
- If you leave, how do you export your data and confirm it has been deleted?
When the vendor cannot fix the problem
- Ask the vendor to fix it. Enterprise customers have leverage, especially early in a contract.
- Mitigate on your side. Restrict which teams can use the tool, block sensitive data classes, wrap integrations behind your own controls.
- Accept the risk formally. If neither is possible, document it and have an accountable leader sign off.
Start this week
- List every AI tool in use, including the ones nobody approved.
- Rank them by the sensitivity of data they touch.
- Send the checklist above to the top five vendors.
- Publish a short acceptable-use policy that says which data never goes into AI tools.
Frequently asked questions
What is AI third-party risk management?
AI third-party risk management is the process of assessing and controlling the risks of AI tools and vendors your organization uses, including how they handle data, train models, control access and protect against LLM-specific attacks.
What questions should I ask an AI vendor?
Ask whether your data trains their models, how long it is retained, which sub-processors receive it, whether they support single sign-on and role-based access, how they test for prompt injection, and how you can export and delete your data.
What is shadow AI?
Shadow AI is the use of AI tools inside an organization without approval or security review, often through personal accounts or free plans.
Does zero data retention matter for AI tools?
Yes. Zero data retention means the provider does not store prompts or outputs after processing, which reduces exposure if the vendor is breached and protects intellectual property such as source code.
Need a fast, practical review of the AI tools your teams already use? Explore our AI-ready security services or start a conversation.