How should organisations assess third-party AI risk in vendor contracts?

Organisations should assess third-party AI risk by combining standard vendor checks with AI-specific review of model lineage, training data provenance, autonomy, human oversight, and change control. The contract should not be the only control. The real question is whether the supplier can prove how the AI behaves, what it can access, and who is accountable when that behaviour changes.

Why This Matters for Security Teams

Third-party AI risk is not just a procurement issue. When a vendor supplies a model, agent, or AI-enabled service, the organisation inherits decisions it did not make about training data, tool access, update cadence, logging, and human override. That makes standard supplier due diligence necessary but insufficient. Current guidance suggests assessing the AI itself as part of the supply chain, not merely the company that sells it, because behaviour can change after deployment without any contract text changing.

Security teams should treat vendor contracts as evidence of control, not as the control. A supplier can be compliant on paper while still exposing an organisation to prompt injection, insecure plug-ins, secret leakage, or unreviewed model updates. NHIMG research on supply chain abuse shows how fast AI-adjacent compromise can spread, including the Mastra npm Supply Chain Attack, Sapphire Sleet, which illustrates how quickly trust in an AI dependency can be weaponised. In practice, many security teams discover vendor AI risk only after the service has already been integrated into business workflows.

How It Works in Practice

Effective third-party AI review starts with asking what the vendor’s system actually does, what it can reach, and how much autonomy it has. The contract should require a clear inventory of models, sub-processors, tools, plugins, and external services, plus a description of whether the system is a passive API, an interactive assistant, or an agent that can take actions. That distinction matters because an autonomous agent can create material risk even when the underlying model is not especially sensitive.

For procurement and security review, the most useful questions are operational:

• What training data, fine-tuning data, and retrieval sources were used, and can the vendor evidence provenance?
• What secrets, tokens, and customer data can the AI access at runtime?
• What human approval is required before the system sends, purchases, deletes, or changes anything?
• How are model updates, safety changes, and tool permissions approved and rolled back?
• What logging exists for prompts, tool calls, outputs, and override events?

Contract language should also bind the vendor to notify buyers of material changes in model lineage, hosting location, sub-processors, and control posture. This aligns with the direction of NIST AI Risk Management Framework and NIST Cybersecurity Framework 2.0, which both emphasise governance, measurement, and continuous monitoring rather than one-time approval. For NHI-specific supply chain issues, NHIMG’s 52 NHI Breaches Analysis is a useful reminder that compromised machine identities and tokens often become the path from vendor trust to downstream exposure.

These controls tend to break down when the vendor embeds opaque third-party models or dynamically changes toolchains in production without customer-visible approval gates.

Common Variations and Edge Cases

Tighter AI contract controls often increase procurement friction, requiring organisations to balance speed of adoption against verifiability and ongoing oversight. That tradeoff is unavoidable, especially where business units want rapid rollout of copilots, customer-facing chat, or workflow agents. There is no universal standard for this yet, so current guidance suggests weighting controls by the degree of autonomy and data sensitivity rather than applying one rigid template to every vendor.

For low-risk, read-only AI features, a lighter contract may be acceptable if the vendor has strong logging, clear retention limits, and no access to secrets or privileged APIs. For higher-risk cases, the agreement should be more explicit about breach notification, model change notice, audit rights, data usage restrictions, subprocessors, and the right to disable AI functions that drift outside agreed behaviour. Where the service is agentic, the buyer should also insist on clear human escalation paths and the ability to revoke tool access quickly.

Be cautious with “confidential AI” or “safe by design” claims that are not backed by testable artefacts. If the vendor cannot show lineage, access boundaries, or change control, the contract should not be treated as a substitute for technical validation. The practical lesson is consistent with OWASP’s OWASP Non-Human Identity Top 10: identity, credential, and supply chain weaknesses are often the real failure point, not the headline AI feature.

Related resources from NHI Mgmt Group

• What breaks when organisations rely on static questionnaires to assess third-party script and AI risk?
• How should organisations govern third-party access in a vendor risk policy?
• How should organisations assess third-party risk when vendors touch sensitive workflows?
• How should organisations expand third-party risk management beyond periodic vendor reviews in complex ecosystems?