Third-Party AI Risk Management Software: Assessment Tools, Agent Controls and Where Each Layer Stops

Third-party AI risk management software is not one product category, it is four control layers that most buyers evaluate as if they were interchangeable. Vendor assessment platforms score the suppliers you onboard. Model supply chain tools inspect the weights and packages you pull. AI discovery tools find the services your staff signed up for without telling anyone. Runtime enforcement controls what your own agents do when they call any of it. No single tool covers all four today, and the gap that hurts most teams is the last one, because it is the only layer that can still act after everything upstream has already approved the vendor.

The reason this matters more this year than last is not a vendor talking point. Verizon published the 2026 Data Breach Investigations Report on May 19, 2026, and it puts breaches involving a third party at 48 percent of all breaches, with vulnerability exploitation the top entry point at 31 percent. Roughly half of breaches now arrive through someone else's product. AI adoption has been adding third parties to enterprise environments faster than any procurement process can enrol them.

What does third-party AI risk management actually cover?

Third-party AI risk management covers the security, privacy and compliance exposure created by AI systems your organization does not run itself. That includes the AI vendors you buy from, the model providers sitting behind those vendors, the AI features that appeared inside SaaS tools you already had, and the AI tools and MCP servers your own engineers installed directly. The last two categories are where programs built for classic vendor management fall down, because nothing in them triggers a procurement event.

Here is the honest map of the layers, and what each one can and cannot see.

Read the blind spots column rather than the catches column. That is where the money is wasted, because every one of these products demos well against the risk it was built for.

Why AI vendors break the standard vendor questionnaire

A vendor security questionnaire assumes a stable thing to ask about: a company, a product, a data flow, an infrastructure footprint. AI vendors violate that assumption in three specific ways, and each one needs a question your existing template probably does not have.

The model provider is a fourth party you did not contract with. When you buy an AI vendor, your data usually reaches a foundation model provider underneath. That provider's retention terms, region and training position govern your data whether or not you assessed them. Ask which providers are in the chain, whether the vendor can change them without notifying you, and what contractual position covers training on your inputs. A SOC 2 report for the vendor says nothing about any of this.

The product changes capability without changing version. A traditional software assessment is anchored to a release. An AI product's behaviour can change when the underlying model is swapped or a system prompt is edited, with no release note and no change window. Ask what constitutes a material change and what notice you get. Point-in-time assurance ages faster here than anywhere else in your portfolio.

The agent has write access, not just read access. Most vendor risk thinking is about data leaving. An AI agent connected to your systems can also send email, move money, modify records and delete things. The relevant question is no longer only what data the vendor can see, it is what actions the vendor's agent can take, under whose credential, and what stops an action that was never intended. That question has no good answer in the assessment layer at all, which is why the runtime section below exists.

The administrative side of vendor onboarding has its own tooling and is worth keeping separate in your head, since collecting and tracking each supplier's certificate of insurance and compliance documents is a paperwork problem with mature answers, while the AI-specific questions above are genuinely new and still have to be written into your template by hand.

How do I do a third-party AI risk assessment?

A workable AI vendor assessment adds five questions to whatever you already send, and each one should have a documented answer rather than a yes or no checkbox. Ask which foundation models and subprocessors are in the chain and whether they can change without notice. Ask what the contract says about training on your inputs and outputs, on your specific plan rather than in general marketing copy. Ask what write access the product needs, enumerated as actions and not as scopes. Ask what the vendor logs about actions taken on your behalf and how long you can retrieve it. And ask what happens on the vendor's side when their own model is prompt-injected through content you supplied, since that is now a normal failure mode rather than an exotic one.

Those five cover the questions that generic templates miss. The rest of your questionnaire still applies, and none of this replaces the discipline of AI agent access control best practices inside your own estate.

The layer most programs are missing

The clearest published illustration of why assessment alone is not enough is the postmark-mcp package. Public reporting on September 25, 2025 described an npm package impersonating a legitimate transactional email integration, where community reports attribute a hidden change in version 1.0.16 that blind-copied every outgoing message to an external address. Snyk write-up describes the exposure as any email content sent through the server, including attachments and headers and potentially secrets, tokens, customer PII and regulated data. Fifteen clean releases shipped before the malicious one.

Walk that through your program. There was no vendor to onboard, no contract, no security contact and no procurement record, so the assessment layer had nothing to assess. A scan at install time would have passed, because the code was clean then. Discovery tooling would not have seen it, because it never authenticated through an identity provider. The tool inherited an API key that was already sitting in the environment. Four of the five layers in the table above were structurally incapable of firing.

The fifth one was not. A control positioned at the moment the agent calls the tool sees an email being sent to a recipient outside the approved set, using a credential scoped for a different purpose, and can refuse. That decision needs no knowledge of the vendor at all, which is exactly why it survives when the vendor record does not exist. This is the argument for treating MCP server security as a runtime problem rather than a procurement one, and it is why our own comparison of agentic third-party exposure management against agent runtime control concludes that the two are complements and not substitutes.

Being direct about our own limits, since this is a page about buying decisions: a runtime control plane will not produce a vendor assessment, will not populate your risk register, and will not answer an auditor asking whether your suppliers are well governed. If those are your obligations, buy the assessment layer and buy it first. Runtime enforcement is what you add when your agents started taking actions that a written assurance cannot undo.

Which layer should a security team buy first?

Sequence it by what your agents can already do, not by what feels most complete.

Does an AI vendor assessment cover MCP servers?

Partly, and the shortfall is structural rather than a product defect. An assessment platform can evaluate an MCP server whose publisher went through procurement, which covers the commercial ones. It has no record of a server pulled straight from a package registry by a developer, which is how the majority of them arrive. The practical answer is to treat commercially supplied servers as vendors and locally installed ones as code, then enforce on both at the point where the agent actually calls them.

Can third-party risk software stop an AI agent from leaking data?

No. Assessment software tells you whether a supplier looks trustworthy before you connect it, which is genuinely useful and completely insufficient on its own. Stopping a leak requires a control positioned at the moment the agent calls a tool, able to inspect what is being sent and to whom and refuse. That is enforcement, and it belongs to a different layer of the stack than any questionnaire.

The takeaway

Buy by layer, not by category name. Map the four or five layers above against what your agents can already do in production, be honest about which layer would have fired in the last incident you read about, and accept that the vendor selling you the most complete-sounding platform is still only covering one or two of them. Assessment before the fact, enforcement at the moment of action. If your agents call tools that move money, send data or change records, start with AI runtime security and the permission model behind it on tool permissions.