TL;DR: As organisations embed third-party AI into core operations, traditional vendor risk questionnaires no longer capture model lineage, autonomy, data provenance, and oversight requirements, according to OneTrust. The shift turns AI vendor review into a governance and accountability problem, not just a privacy or security checklist.
At a glance
What this is: OneTrust argues that third-party AI risk now spans model data, autonomy, governance, and vendor oversight rather than fitting inside traditional third-party questionnaires.
Why it matters: IAM, NHI, and AI governance teams need a shared way to assess delegated systems because third-party AI changes who controls data, decisions, and accountability.
Context
Third-party AI risk is what happens when an organisation consumes AI capabilities from a supplier but still carries the governance burden for how those capabilities process data, make decisions, and operate inside business workflows. Traditional third-party risk management was built around privacy, security, continuity, and contract review, but those controls do not fully capture model behaviour, data lineage, or the level of human oversight required.
The governance gap is especially clear when a vendor’s AI component is embedded inside an internal workflow. In that situation, the buyer is not just evaluating a tool, but also the decision logic and operating constraints behind it. For IAM and NHI programmes, the same problem appears whenever delegated access, machine credentials, or autonomous actions are introduced without clear ownership and oversight.
Key questions
Q: When does AI model governance usually fail in practice?
A: It usually fails when documentation begins after deployment. At that point, model inventories are already stale, relationships to use cases are missing, and engineering teams have moved on to newer versions. Governance is weakest when it depends on manual follow-up instead of capturing model details at the moment the asset is created.
Q: Why do AI vendors create more third-party risk than traditional software vendors?
A: AI vendors create more risk because their behavior can change after contract signing, especially when models are retrained or data sources shift. The same tool may produce different outputs over time, and those outputs can influence business decisions. That makes static due diligence insufficient. Security teams need continuous oversight of data flow, model changes, and downstream use.
Q: What are the signs that third-party AI oversight is too weak?
A: Common warning signs are unclear model ownership, no traceability for training data or versions, vague descriptions of human review, and vendor answers that stay at policy level only. If a supplier cannot explain how its AI changes, who approves those changes, and what it can do inside your environment, the oversight model is too weak for operational use.
Q: Should organisations treat vendor AI risk as part of IAM and NHI governance?
A: Yes. When a vendor AI system uses machine credentials, API access, or delegated permissions to perform work, it becomes an identity governance issue as well as an AI governance issue. The practical test is simple: if the system can act on your behalf, it needs the same ownership, scope, and review discipline as other high-risk delegated access.
Technical breakdown
Why vendor questionnaires do not capture AI operating risk
Traditional vendor assessments are built to answer whether a supplier is trustworthy, compliant, and resilient. AI systems add new questions: what data trained the model, how often the model changes, what decisions it influences, and how much human supervision remains in the loop. Those are operational questions, not just legal or procurement questions. If the assessment stops at policy attestations, it misses the control points that actually determine whether the AI behaves safely in production.
Practical implication: Treat AI vendor review as an operating model assessment, not just a document check.
Model attributes and data lineage are now governance inputs
A third-party AI system cannot be governed properly unless the buyer understands its dataset provenance, data quality, versioning, traceability, learning method, and bias profile. These attributes are material because they shape explainability, performance drift, and compliance exposure. In identity terms, this is similar to insisting on lifecycle visibility for credentials or workloads: you cannot govern what you cannot inventory or trace. The same logic applies to AI components embedded in external services.
Practical implication: Require vendors to disclose enough lineage and model detail to support review, monitoring, and accountability.
Human oversight must be explicit when AI is deployed through vendors
The article’s most important technical point is that autonomy level matters. If a third-party system can recommend, trigger, or execute actions with limited review, then oversight controls need to be defined before deployment, not after an issue occurs. This is where AI governance intersects with IAM and NHI. A vendor workflow that can act through API tokens, service accounts, or delegated permissions creates an identity governance problem as well as an AI risk problem.
Practical implication: Map every vendor AI workflow to the human approval, delegation, and access controls it depends on.
Threat narrative
Attacker objective: The objective is to exploit the trust placed in a third-party AI workflow so that unsafe decisions, data exposure, or governance failure occur inside the customer environment.
- Entry occurs when a third-party AI component is integrated into business operations with incomplete visibility into its data sources, model behaviour, or delegated permissions.
- Credential or access abuse emerges when the AI workflow acts through enterprise integrations, APIs, or machine credentials that were granted for convenience rather than governed scope.
- Impact follows when opaque model behaviour, weak oversight, or poor vendor governance turns the AI system into a source of compliance, data, or decision-risk inside the buyer’s environment.
Breaches seen in the wild
- Klue OAuth Supply Chain Breach: OAuth tokens compromised in Klue integration breach affecting 700+ organisations via Salesforce data access chain.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Third-party AI risk is fundamentally an identity governance problem: once a vendor’s AI can act through enterprise integrations, the question is no longer only whether the supplier is secure. The buyer must govern who or what is allowed to make decisions, access data, and trigger actions on its behalf. That is the same governance challenge IAM and NHI teams face whenever delegated authority is hidden inside a business workflow. Practitioners should treat vendor AI as an extension of access governance, not a separate procurement checklist.
Model lineage is becoming part of third-party assurance: organisations that cannot trace training data, versioning, and operational changes cannot credibly assess risk. AI governance fails when teams focus on contracts and policies while ignoring the model artefacts that determine real-world behaviour. In practice, this means the assurance model must cover data provenance, model change control, and oversight thresholds. Practitioners should require traceability before trust, not after rollout.
Delegated AI authority is the named concept that matters here: it describes the point at which a vendor’s AI system is permitted to act on enterprise data or processes with limited human review. Once that boundary is crossed, the organisation inherits both AI governance obligations and identity governance responsibilities. This is why the old separation between third-party risk and AI governance no longer holds. Practitioners should inventory every delegated AI workflow as a governed access relationship.
Holistic vendor assessment is now the only defensible operating model: privacy, security, resilience, ethics, and AI governance cannot be assessed in separate silos when the same supplier system influences all of them. The article is right to push toward a unified review process, but the practical lesson is broader: the control owner must be explicit, the oversight model must be documented, and exceptions must be visible. Practitioners should align third-party AI oversight with the same discipline used for high-risk identity and access decisions.
From our research library:
- 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
- 52% of respondents see AI security decision-making power shifting toward platform and infrastructure teams rather than the executive suite, according to the 2026 Infrastructure Identity Survey.
- Read next: Third-Party, B2B and Contractor Access Guide
What this signals
Delegated AI authority: vendor AI becomes a governance problem the moment it is allowed to act on enterprise data or processes with limited human review. That shifts oversight from procurement into identity, access, and accountability design, because the organisation now has to govern the system as an actor in its own right.
Third-party AI assessments should converge with the organisation’s access governance model, not sit beside it. If a vendor workflow can trigger actions through machine credentials or API permissions, the review has to address scope, approval, monitoring, and offboarding in the same control plane.
For practitioners
- Expand third-party questionnaires for AI-specific controls Add questions on model ownership, training data sources, versioning, traceability, autonomy level, and required human oversight.
- Map vendor AI workflows to delegated access paths Identify whether the vendor AI uses API keys, service accounts, tokens, or other machine credentials to operate inside your environment.
- Require evidence of model lineage and change control Ask vendors for documented dataset provenance, model update processes, and a clear process for notifying customers about material changes.
- Integrate AI governance into TPRM reviews Treat AI risk as part of the existing third-party review cycle so privacy, security, resilience, and oversight decisions are made together.
Key takeaways
- Third-party AI risk is no longer limited to privacy or security questionnaires, because model behaviour, data lineage, and autonomy now affect operational governance.
- The critical assurance gap is visibility into how a vendor’s AI was built, changed, and authorised to act inside the customer environment.
- Organisations need one review model that connects third-party risk, AI governance, and identity governance whenever a supplier system can act on their behalf.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST AI RMF, NIST SP 800-63 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST AI RMF | GOVERN — AI Governance and Accountability | The article centres on third-party AI oversight and responsibility allocation. |
| MAP — AI Context and Risk Mapping | Vendor AI assessments depend on mapping data sources, model behaviour, and deployment context. | |
| MANAGE — Risk Management | The article argues for operational controls that continuously manage AI vendor risk. | |
| Recommendation — Establish governance ownership for third-party AI use before deploying vendor systems into business workflows. Map each vendor AI use case to its data, decision, and oversight dependencies. Build continuous risk controls for third-party AI rather than relying on one-time assessments. | ||
| NIST SP 800-63 | SP 800-63C — Federation | Vendor AI often acts through delegated access and federated trust relationships. |
| Recommendation — Review federated trust paths so delegated AI actions stay within approved authority. | ||
| NIST CSF 2.0 | GV.SC-02 — Supply Chain Risk Management | The piece is specifically about managing AI risk in third-party relationships. |
| Recommendation — Extend supply chain governance to cover vendor AI behaviour, not only contractual security assurances. | ||
Key terms
- Third-party AI risk: Third-party AI risk is the exposure created when external vendors embed AI into products, services, or workflows that an organisation relies on. The risk includes hidden model changes, unclear data handling, training use, and shifting control boundaries that can invalidate earlier assessments.
- Model Lineage: Model lineage is the traceable record of what data, code, training runs, evaluations, and approvals produced a deployed AI model. It is the trust chain for machine learning operations, because it lets security and risk teams verify provenance, investigate changes, and support rollback or audit requirements.
- Delegated AI Authority: Delegated AI authority is the permission a person gives an assistant to act inside business systems on their behalf. It turns a conversational tool into an execution layer, which means security teams must govern scope, auditability, and revocation with the same seriousness they apply to privileged access.
- Holistic Vendor Assessment: Holistic vendor assessment is a review approach that combines privacy, security, resilience, legal, and AI-specific checks into one governance process. It is used when separate questionnaires fail to capture how a vendor’s AI behaves in production and how its risks interact across domains.
Deepen your knowledge
The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, and secrets management in the context of real access decisions. It helps practitioners align identity controls with the governance demands of delegated systems and machine actors.
Published by the NHIMG editorial team on July 11, 2026.
Updated on October 11, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org