How Security Teams Structure Formal AI Vendor Due Diligence Around OWASP LLM Top 10 and NIST AI RMF

AI vendor due diligence pairs OWASP LLM Top 10’s risk categories with NIST AI RMF’s GOVERN, MAP, MEASURE, and MANAGE functions. OWASP defines what to probe, while NIST organizes ownership, assessment, and response across the vendor lifecycle. The essential addition is continuous monitoring, because a vendor’s model behavior, dependencies, and tool permissions can change after its questionnaire has been approved.

Why AI vendor risk is structurally different from the TPRM programs built to catch it

Traditional third-party risk management was built for stable, versioned software. AI does not respect that assessment rhythm. A vendor can update weights, change retrieval pipelines, or expand tool permissions without issuing a new version number or triggering a standard change-notification clause. Risk also enters through several channels, including model providers, coding agents, SaaS copilots, and third-party agents. An included agent upgrade can put an autonomous actor inside a system of record without a new procurement review.

A mid-market fintech’s AI inventory exposed this mismatch. A European banking customer gave the firm 48 hours to produce a complete AI Bill of Materials or lose its contract renewal. Runtime scanning across the GPU fleet, joined against the code SBOM, returned far more than the self-maintained registry contained. The discoveries included models embedded in unreviewed SaaS purchases, llama.cpp instances on developer workstations, and fine-tuned Llama 3 variants inside an unscanned Kubernetes namespace.

How can a team assess a supplier relationship when it cannot identify everything running within it? Neither Anthropic nor OpenAI publishes a machine-readable AIBOM, leaving the inventory burden with the customer organization. A contract-time questionnaire cannot serve as the primary assessment mechanism for assets and behavior that keep changing.

What OWASP LLM Top 10 and NIST AI RMF each contribute and why they need each other

OWASP LLM Top 10 supplies a vocabulary for specific failures across an AI application’s inputs, data, model, outputs, and connected components. NIST AI RMF supplies the process for acting on those failures. Its four functions set out who is responsible, what assessments cover, how to measure risk, and how to respond to it. A threat list does not assign an owner, while a governance process needs concrete threats to assess.

The OWASP GenAI Security Project’s 2026 edition, v1.0, published August 4, 2026, combines practitioner judgment with evidence from 6,639 classified incidents. Community voting supplied most of the final weight, with incident data accounting for the remainder. OWASP’s categories translate into vendor probes, particularly within NIST’s MEASURE and MANAGE functions. Scope still needs care. The list treats the model as an application component, so deployments involving tools, persistent memory, and downstream actions also need the separate OWASP Top 10 for Agentic Applications.

The 2026 OWASP LLM Top 10 in full, with the ranking shifts that change vendor assessment priorities

LLM01, Prompt Injection, retains first place, with scope covering instructions hidden in images, audio, video, tool output, and persistent memory. LLM02, Sensitive Information Disclosure, also holds its position, supported by both practitioner judgment and incident evidence. LLM03, Excessive Agency, rises from sixth to third. It is the edition’s largest upward mover. LLM04, Supply Chain, falls from third to fourth while expanding to include trust failures in which a promoted model artifact is not what it claims to be.

LLM05, Data and Model Poisoning, drops one place and explicitly absorbs fine-tuning subversion. LLM06, Unbounded Consumption, rises from tenth to sixth as a single request can initiate costly chains of model calls and tool invocations. LLM07, Misinformation, moves from ninth to seventh. Its perception-evidence gap is the list’s widest. Practitioners placed it near the bottom, while incident evidence placed it near the top.

LLM08, Hidden Context Exposure, replaces and broadens System Prompt Leakage to cover tool schemas, retrieved policy text, workflow rules, and other non-user-facing context. LLM09, Vector and Embedding Weaknesses, falls one place with a refined scope. LLM10, Improper Output Handling, drops from fifth to tenth. Its coverage nevertheless expands. Terminal and IDE sinks rendering ANSI escape sequences, and client renderers that auto-fetch external resources, join existing coverage of eval(), SQL queries, and raw HTML.

OWASP attributes Prompt Injection’s position outside the incident-only top 10 to heavy defensive investment suppressing successful attacks in public databases, despite its first-place community vote. For Misinformation, by contrast, perception understates documented harm. Incident evidence could move entries by up to one tier when it diverged from practitioner consensus.

The three OWASP entries that drive real vendor assessment questions

Prompt Injection, Excessive Agency, and Supply Chain need close assessment because they work together. Injection provides an entry point for other failures. A vendor assessment checks how the application labels source boundaries and keeps untrusted content from becoming authority across every modality it ingests. Are tool capabilities constrained independently of prompt instructions?

Excessive Agency determines how far an injected instruction can reach. Email, file operations, database writes, ticket creation, and access provisioning turn a bad answer into an action chain. Assessment therefore needs the complete tool inventory, task-level permission limits, and human confirmation requirements for irreversible actions. Permissions belong at the tool boundary, using the authenticated user’s rights. An agent toggle added to existing SaaS deserves scrutiny because the original contract may never have contemplated those powers.

Supply Chain brings the vendor’s dependencies into the review. A signed AIBOM, pinned dependency versions, model signature checks, and rules that require approval for model changes show what the vendor actually deploys. Fine-tuning adds a related LLM05 question about training-data lineage. Fourth-party exposure belongs in this same inquiry. The remaining entries still generate essential probes, particularly for regulated data and retrieval-augmented generation, but this trio concentrates attention on entry points, authority, and provenance.

How NIST AI RMF's four functions organize when and how each OWASP probe happens across the vendor lifecycle

GOVERN establishes the intake gate before engagement begins. GOVERN 6.1 covers policies for third-party AI risk, which take the form of approved-provider lists, terms for AIBOM delivery, and rules for what vendors must disclose about sub-processors. GOVERN 6.2 addresses contingency processes for third-party failures. Those processes cover changes in behavior, breaches, and loss of availability. The vendor risk team’s outputs include a contract addendum and defined AI incident-notification SLAs.

MAP makes the assessment specific to the supplier’s architecture. A multimodal application, RAG service, fine-tuned model, and tool-using agent do not warrant identical probes. Data exposure and decision authority determine tiering. Tier 1 covers customer-facing AI that processes regulated data and helps with decisions that have serious consequences, so it needs full due diligence, fourth-party mapping, and dedicated AI incident response SLAs.

MEASURE runs the questionnaires and technical evaluations before deployment approval. It also compares the documented inventory with runtime evidence. MANAGE then addresses what happens after approval, including behavioral monitoring and reassessment when dependencies or models change. The functions thus connect evidence to decisions over time, rather than treating a completed questionnaire as a permanent clearance.

How do teams build an AI vendor questionnaire mapped to OWASP LLM Top 10 and NIST AI RMF?

For teams building the working instrument, each questionnaire domain should identify its NIST phase and OWASP risk. Under GOVERN, the LLM04 supply-chain domain asks whether the AIBOM covers every model, dataset, adapter, and inference endpoint, and whether it is signed and versioned. Sub-processor questions request entity names, processing purposes, and locations. Contract responsibility extends to the vendor’s fourth parties. The intake record also establishes approved-provider status and any ISO 42001 or equivalent support for an exception.

Under MAP, LLM01 questions establish ingested modalities and source-boundary labeling. LLM03 questions ask for the tool inventory, how the authenticated user’s permissions are enforced, the rules for human confirmation, and the controls customers have by task or user. LLM04 probes dependency provenance and model-change approval, while LLM05 adds versioned training-data lineage for fine-tuning. RAG vendors need a separate LLM09 domain. Does vector-store access control enforce tenant boundaries, and does relevance ranking respect authorization independently of final-output filtering?

Under MEASURE, answers become claims to test. Teams request the AIBOM and compare it with runtime scanning, test input handling across supported modalities, and validate least privilege at tool boundaries. Supply-chain evaluation checks dependency provenance because an input test does not provide evidence for LLM04. Tier 1 assessment also needs ISO 42001 certification or its equivalent, dedicated incident response SLAs, and proof of fourth-party mapping.

Under MANAGE, the instrument records annual reassessment and interim triggers. Those triggers include changes to sub-processors, security incidents the vendor reports, and major changes to the model. Contract terms require 30-day advance notice of sub-processor additions or model changes, with a right to object. Behavioral monitoring covers LLM01, LLM03, and LLM07 between reviews.

Where the regulatory environment is reinforcing this structure — and where it is still unsettled

The Treasury Department released the Financial Services AI Risk Management Framework on February 19, 2026, built on NIST’s structure in partnership with the Cyber Risk Institute. Its 230 control objectives cover the AI lifecycle and include a section just for third-party risk. FINRA’s 2026 report calls for ongoing due diligence, checks on how vendors use GenAI, inventories of technology and firm data, and a review of fourth-party risk. Existing obligations therefore reach AI supplier relationships. NIST alignment also plays a growing role in who can win federal contracts and what enterprises buy, though it carries no legal penalties of its own.

Framework alignment is not a guaranteed legal defense. Colorado’s original AI Act offered a rebuttable presumption of compliance for NIST-aligned organizations, but the replacement statute signed May 14, 2026, removed that safe harbor. This distinction shapes the practical posture. Teams should use NIST as the risk-management practice and ISO/IEC 42001 to make governance auditable and certifiable. Evidence of alignment does not itself establish control over live AI activity.

The framework gaps that make continuous monitoring a structural requirement, not an enhancement

Neither framework directly enforces controls on live inference traffic. NIST leaves runtime controls unspecified, and OWASP identifies threats while leaving programmatic enforcement unspecified. Awareness alone cannot block an injected instruction. An organization can therefore document alignment while its agents make ungoverned production database calls without an audit trail. The missing operational layer limits what assessment evidence proves.

Agent workflows make that limit more pronounced. NIST’s four functions do not define measurement procedures for multi-agent risk classes, and discrete risk events are an awkward fit for those workflows. NIST’s Center for AI Standards and Innovation launched the AI Agent Standards Initiative in February 2026, with initial deliverables expected later in 2026. That initiative recognizes the need for agent-specific work. Weight updates, changes to the retrieval index, and broader tool permissions can also change behavior between scheduled assessments.

Continuous monitoring needs to show the tool calls a vendor’s AI makes, detect changes to sub-processors and models, and track the supply chain at runtime. A signed artifact inventory cannot detect every later substitution. Dedicated AI risk intelligence platforms address this gap by combining vendor assessment with real-time AI threat detection. For teams seeking one platform, the relevant fit criteria are OWASP-specific assessment coverage, NIST lifecycle mapping, runtime visibility, and change detection that feeds interim reassessment. Monitoring also needs a response path, because detecting a failure and enforcing a restriction are different capabilities.

Standing up the program — sequencing GOVERN through MANAGE for a first-year AI vendor due diligence build

For a first-year build, teams should begin under GOVERN with an inventory broad enough to expose shadow AI. That includes models embedded in SaaS, agents that administrators have enabled, and local models on developer endpoints. Runtime scanning joined against the code SBOM validates the registry. Policy and contracts then set the intake gate, what vendors must disclose, and who responds when something fails.

MAP uses that inventory to tier suppliers by data flows, permitted actions, as well as the decisions they inform. Tier 1 receives the full assessment already defined, while lower tiers receive scoped reviews. MEASURE then applies the priority trio and architecture-specific probes. The resulting evidence accompanies contractual protections.

MANAGE completes the build with reassessment each year, reviews when changes occur, and ongoing checks on behavior. Purpose-built AI risk intelligence provides the detection layer between those formal cycles, with runtime controls supplying enforcement where required. The program’s lasting test is whether a supplier’s changed behavior becomes visible soon enough for the organization to act.