A Repeatable Workflow for Mapping Third-Party LLM Vendor Risk to OWASP and NIST Without Manual Effort

AI vendor risk assessment mapped to OWASP LLM Top 10 and NIST AI RMF becomes repeatable when inventory, risk tagging, testing, and monitoring run as one automated cycle. The workflow maps findings as they are generated, rather than leaving analysts to assemble compliance evidence afterward. Automation does the assessment work that repeats, while defined escalation gates send findings to people when they need human judgment.

Why third-party LLM vendors are where enterprise AI risk actually lives

Microsoft 365 Copilot’s EchoLeak vulnerability showed how an organization could gain an attack path by using a vendor product. Disclosed in June 2025 as CVE-2025-32711 with a CVSS score of 9.3, the zero-click indirect prompt injection exfiltrated data through a crafted email. No user action was needed to trigger it. Microsoft patched the vulnerability, which carried risks of Prompt Injection, Sensitive Information Disclosure, and Data and Model Poisoning.

Noma reported a similar boundary failure in Salesforce Agentforce. ForcedLeak, disclosed in 2025 with a CVSS score of 9.4, used a Web-to-Lead field to deliver an indirect prompt injection that led to CRM data exfiltration. Salesforce patched it. The incident maps to Prompt Injection and Excessive Agency and shows how agents from vendors can use their permissions to act on hostile input.

In both cases, the receiving organization had not introduced the vulnerability. Yet it bore the exposure. Most enterprise AI deployments rely on third-party foundation models, APIs, and vendor products, so governance that covers only AI built in-house misses most of the risk surface. The data supply chain adds another risk when unclear terms from the model-operator let sensitive data from an application enter training, with similar concerns for copyrighted material. When agents can use a broad set of tools, those dependencies carry more risk because successful injections can lead to real-world action.

What OWASP LLM Top 10 and NIST AI RMF actually require from a TPRM program

NIST AI RMF GOVERN 6 covers policies for third-party software and data, including how models are brought in and how resources are set aside for safety testing. MANAGE 3 covers the risks and benefits that come from third-party entities. These provisions set a governance goal for third-party risk management, or TPRM. OWASP supplies the threat categories against which vendor products can be assessed, rather than treating AI as another line on a general security questionnaire.

OWASP Top 10 for LLM Applications 2025 identifies several especially relevant categories. LLM01 covers direct and indirect Prompt Injection, while LLM02 covers Sensitive Information Disclosure through training-data memorization, system prompts, and context windows. LLM03 addresses Supply Chain dependencies, including pre-trained models, fine-tuning datasets, plugins, and frameworks. LLM04 covers the risk of poisoning in both data and models. LLM06 covers Excessive Agency, where tools or permissions an agent does not need let it do more than its intended function.

The crosswalk already exists in structured, machine-readable form. It links LLM02 to Data Privacy and AC-3/SI-15, LLM03 to Value Chain and Component Integration and SR-3, and LLM04 to Information Security / Harmful Bias and Homogenization and SI-7. It also links LLM06 in the 2025 edition to Information Security and AC-6, LLM09 to Confabulation / Human-AI Configuration and SI-10, and LLM10 to Information Security and SC-5. Those risk themes and control references provide mapping targets, while the AI RMF functions organize the workflow. They are related layers.

Why manual review cannot produce a repeatable mapping at vendor scale

The obstacle is not just the number of questionnaires. Enterprises with hundreds or thousands of vendors face a mismatch between periodic reviews and products that change between assessments. A model update, added plugin, or configuration change can introduce a risk that was absent at onboarding but present six weeks later. More analysts can process more reviews, but they do not turn a snapshot into continuous observation.

The inputs also miss key AI dependencies. Traditional software bills of materials come from the build graph and do not capture third-party model APIs, training-data provenance, or evaluation evidence. AI-BOM generation is less mature and often manual or vendor-supplied. Questionnaires built before 2024 may likewise omit model provenance, data supply chain integrity, and third-party model vetting. A team using those questionnaires should review them for those gaps.

Even a completed review can produce the wrong evidence. Generic TPRM checklists do not map directly to OWASP LLM categories or NIST AI RMF functions, leaving analysts to translate broad assurances into AI-specific findings afterward. That translation is difficult to repeat consistently across a changing portfolio. What would a workflow look like if its inputs and outputs were structured for the mapping from the start?

Stage one of the workflow: building a machine-readable AI asset inventory under GOVERN 6

The starting artifact is an AI Bill of Materials, or AI-BOM. It records the components an AI system depends on in machine-readable form, with enough detail to identify each component unambiguously later. NIST AI 600-1 GV-6.1-005 calls for a framework to assess supplier risk based on the use case, so an AI application inventory is a useful place to start under GOVERN 6.

OWASP AIBOM Generator is Apache-2.0 licensed and emits CycloneDX 1.6 JSON from a Hugging Face model ID. Snyk AI-BOM scans local Python, Java, JavaScript, and Go projects for models, datasets, agents, tools, and MCP servers. Its agent and tool coverage is relevant because an inventory of models alone cannot describe the permissions-related exposure behind Excessive Agency. These tools address discovery needs.

Wiz AI-SPM extends discovery into the cloud runtime. It discovers AI services, model usage, and supporting infrastructure, then maps models, datasets, identities, network paths, and cloud resources into a security graph. That view connects components to what they can access in production. Rule-based tiering can then categorize vendors by data interaction type and regulatory considerations. The resulting AI-BOM becomes the structured handoff to risk tagging.

Stage two of the workflow: automated risk tagging against the OWASP-NIST crosswalk under MAP 4

NIST AI RMF MAP 4 calls for mapping the risks and benefits of all the components in an AI system, including third-party software and data. The AI-BOM supplies the components for that work. An automated tagging layer applies the crosswalk as a lookup structure, linking relevant risk indicators to OWASP categories and their NIST mappings.

Vendor documents provide another set of inputs. Natural language processing can pull risk indicators from contracts, policies, and documentation, while machine learning can find patterns across large numbers of assessments. These methods help organize the evidence. They do not establish that a vendor’s claims are true. Incident and vulnerability databases add known findings to that picture. NIST AI 600-1 places assessment against those databases under GV-6.1-005, so a reference to EchoLeak’s CVE supports that assessment without a separate manual lookup.

A workflow-centric method uses OWASP categories as threat scenarios with inherent risk scores and maps NIST CSF 2.0 categories and subcategories to those scenarios. It then scores how well outcomes are covered across tool and architecture archetypes and estimates residual risk by scaling inherent risk against the outcomes left uncovered. That CSF-based scoring layer is distinct from AI RMF function mapping. Together, the layers yield an auditable prioritization signal without treating every tagged risk as equally urgent.

Stage three of the workflow: automated red-teaming and evidence generation under MEASURE

A risk tag is a hypothesis. Automated red-teaming tests whether the suspected weakness can be exploited in the vendor’s product and ties the findings to the crosswalk. The compliance mapping is part of the assessment output.

Automated red-teaming platforms can map findings to OWASP 2025 entries including LLM01, LLM02, LLM05, LLM06, LLM07, and LLM10. Their outputs can also map to the OWASP Agentic Security Initiative categories ASI01–ASI10, MITRE ATLAS techniques, and NIST AI RMF MAP, MEASURE, and MANAGE function areas. Multiple mappings let the same finding support different assessment needs. They do not, by themselves, prove that every relevant risk has been tested.

For agentic vendor products, assessments need to check for Excessive Agency. Testing checks which tool calls crafted input can cause and which permissions go beyond the agent’s stated function. The category is LLM06 in the 2025 edition and LLM03 in the 2026 list, so the edition must remain attached to the identifier. Findings with OWASP identifiers, applicable CVSS scores, and incident references provide evidence auditors can examine. They support the documentary requirement without making a risk label a substitute for test results.

Stage four of the workflow: continuous monitoring to keep the mapping current under MANAGE 3

An onboarding assessment describes a vendor at one point. Under MANAGE 3, that assessment needs to remain useful as model versions, plugins, configurations, and the surrounding threat landscape change. Continuous monitoring provides early warning of emerging threats across a portfolio that manual reviews cannot cover comparably.

Monitoring also needs a rule for what happens next. The residual-risk scoring set up during tagging and assessment determines which threshold changes need human review and which can be handled through automated remediation.

The monitoring output then refreshes the AI-BOM itself. New components, updated model versions, and newly discovered vulnerabilities enter the inventory without manual reentry, triggering tagging and assessment for affected components. That feedback loop is what makes the workflow repeatable. Without it, automation merely produces a faster onboarding review.

The real limit of automation and where human judgment must remain in the loop

AI-generated assessments can be wrong, even when their output looks orderly. A vendor may supply documentation that satisfies automated parsing without satisfying the underlying control intent. Matching a sentence to a control is not the same as validating the control in context. A defensible workflow must account for the limits of parsing in validating controls in context.

The response is to define where human judgment enters. Residual-risk thresholds require escalation for specified findings, and reviewers take a closer look at high residual risk, new threat patterns, and documentation that is unclear or inconsistent. The crosswalk adds a validation boundary of its own. Findings that cannot be assigned to a specific OWASP category and NIST control are flagged as gaps for analyst review.

Dedicated AI risk intelligence platforms can better support this boundary when the way they assess risk is built around OWASP LLM categories and NIST AI RMF functions. That is an architectural advantage over adding AI features to a generic checklist. The practical lesson for TPRM, InfoSec, Privacy, and Legal teams is to make automated evidence production the baseline while retaining human decisions at defined escalation gates. Automation should concentrate review where it changes the outcome.

Putting the four stages together as an operational program

GOVERN, MAP, MEASURE, and MANAGE work together in one cycle. The operational handoffs are a signed, machine-readable AI-BOM, structured risk tags and scores, mapped test findings, and monitoring updates that restart assessment where needed. Each handoff preserves the connection between a vendor component and the evidence about it.

For a team starting from scratch, the entry point is the AI application inventory. For a team evaluating platforms, the questions are equally practical. Does the platform map findings natively to OWASP LLM categories and NIST AI RMF functions? Does it cover models, APIs, agents, plugins, and MCP servers, and does it support continuous monitoring rather than another point-in-time questionnaire cycle?

Those criteria distinguish an automated mapping program from an automated form.