Yes. If an AI service processes company data, it belongs in third-party risk review because retention, training reuse, subcontracting, and incident handling all affect exposure. Security, privacy, and IAM should evaluate the service together before access is granted.
Why AI Vendors Belong in Third-Party Risk Review
AI vendors are not exempt from the same risk logic applied to any other supplier. If a service can read company data, retain prompts, subcontract processing, or change incident handling terms, it creates exposure that belongs in vendor due diligence. The control question is not whether the service is “AI” or “software,” but whether it can access, store, infer from, or redistribute sensitive information. That is exactly why NHI and IAM teams should review it alongside privacy and security.
This is especially important because AI services often blend application access with hidden identities such as API keys, service accounts, and delegated tokens. Attacks against those identities are already a known pattern in the wild, as seen in LiteLLM PyPI package breach and Reviewdog GitHub Action supply chain attack. The practical lesson is simple: vendor risk is identity risk when the vendor can touch data paths and credentials. In practice, many security teams encounter AI exposure only after a prompt, token, or integration has already been reused in a way that was never approved.
How to Assess an AI Vendor as a Supplier
Start with the same supplier questions used for other third parties, then add AI-specific controls. Confirm what data enters the service, whether prompts or outputs are stored, whether customer content is used for training or fine-tuning, where processing occurs, and which subprocessors are involved. Then ask how access is granted and revoked, because AI platforms often rely on long-lived secrets that outlast the business need. Current guidance suggests that static credentials and broad workspace permissions create unnecessary exposure, especially when tools can call external systems on behalf of users.
A practical review usually includes:
- Data retention and reuse terms, including whether prompts, files, and outputs are logged.
- Secret handling, including rotation, scope, and whether JIT credentials are supported.
- Identity model, including service accounts, workload identity, and privilege boundaries.
- Incident handling, including breach notification, log access, and revocation paths.
- Subprocessor and model-provider transparency, especially for cross-border processing.
For identity design, the current direction of travel is toward short-lived, task-scoped access rather than standing privileges. That is consistent with the broader NHI problem space described in the 52 NHI breaches Report and the OWASP Non-Human Identity Top 10, both of which reinforce that unmanaged machine identities become a supply-chain issue fast. When an AI vendor can connect to internal systems, security should treat its access like any other privileged integration and verify that the contract, architecture, and runtime controls all match the intended use. These controls tend to break down when the vendor allows broad delegation into production SaaS tenants because privilege scoping becomes too coarse to enforce safely.
Common Variations, Exceptions, and Contract Gaps
Tighter vendor controls often increase onboarding time and integration overhead, so organisations have to balance speed against data exposure. That tradeoff matters most when teams want to trial an AI tool quickly but the service can ingest customer records, source code, or regulated content. Best practice is evolving, and there is no universal standard for this yet, but the default should be to assume that any vendor with content access is in scope for third-party review.
Edge cases usually appear in one of three forms. First, consumer-grade AI tools adopted by employees without procurement approval still create supplier risk if company data is entered. Second, “bring your own key” or “bring your own model” setups can mask who actually controls retention, logging, and revocation. Third, agents and automation layers can make the vendor look harmless while the underlying workload quietly gains tool access and persistent secrets. That is why the DeepSeek breach and Shai Hulud npm malware campaign matter here: both show how quickly exposed secrets and software dependencies can become a vendor-led blast radius. Organisations should also check whether an AI vendor’s AI usage policy conflicts with their own retention or residency rules, because contract language does not fix an unsafe integration pattern. In practice, the weakest point is usually not the model itself but the credential path that lets it reach other systems.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Covers secret rotation and exposure risk in vendor integrations. |
| NIST CSF 2.0 | GV.SC | Supplier governance maps directly to third-party AI risk review. |
| NIST AI RMF | GOVERN | AI governance requires accountability for vendor-driven model and data use. |
Classify AI vendors in supplier governance and verify data, incident, and access obligations before onboarding.
