What Is Third-Party AI Security Verification?

The majority of the conversations about AI security begin with the in-house built model or the newly released agent. They should begin with all of the below. Almost all production AI systems nowadays are built out of components that the security team doesn't write: they acquire a foundation model from an outside research lab, connect agents to tools via an MCP server, download plugins and skills from a marketplace, and train with data provided by a third party. If you don't take AI agent security seriously, then the greatest dangers remain hidden.

Third-party AI security verification is the process of verifying if the external AI components that an organization uses and relies on but does not own are safe, or assumed safe based on a vendor's page. It's a different question from whether an AI security vendor's own certifications and controls are sufficient, which we discuss in our guide to evaluating AI security vendors.

Why Third-Party AI Dependencies Are a Distinct Risk Category

Traditional vendor risk management thinks that a vendor is a thing that can be fixed, audited, and renewed: a version number, a SOC 2 report, and a renewal date. Third-party AI dependencies pose two distinct threats: They don't declare, and they are not limited to the first vendor. The two problems below illustrate the need for a playbook for AI supply chain verification that's not a rehash of third-party risk management.

A Compromised Agent Plugin Looks Like a Feature Update, Not Malware

A traditional supply chain attack typically leaves a footprint: a strange binary, an odd outgoing communication, a signature that a scanner will pick up. There's no need for any of that to damage an AI agent plugin or skill. It requires only a little reworded system prompt, a description of the tool that pushes an agent in the right direction, or a new permission set that is included in a standard update.

Since agents read instructions in natural language, instead of fixed code paths, a malicious change may be indistinguishable from a legitimate change at the code level, with the distinction only being noticeable in the action(s) taken. A plugin that begins delivering conversation context to a new endpoint or a skill that makes an agent not wait for an approval step ships the same way as an approved bug fix. Signature-based scanning isn't designed to detect that, and that's why the third-party AI models and plugins need to be verified by watching them, not just their code.

The Hidden Sub-Processor Problem: Fourth- and Fifth-Party AI Exposure

Each third-party AI vendor has its own provider: the foundation model it is fine-tuning on, the vector database it is using to query, the orchestration that it's running, the sub-processor that it is passing data to for embeddings and/or moderation. None of them are selected or even known to the organization; they are fourth-party AI exposure or, if that vendor has its own suppliers, fifth-party.

This is the sub-processor risk in AI that most vendor questionnaires fail to address: the vendor, not the three or four AI systems that are in operation in the background. One weak data control in a fine-tuning pipeline or one compromised embedding service can impact dozens of downstream products and the downstream customers don't know until the vendor tells them, if at all.

What Counts as a Third-Party AI Dependency

However, it must first be named before it can be verified. Most companies are not aware of the number of categories of third-party AI dependency risk that they are carrying because AI dependency has become a concept that goes by the name "the LLM API we use. In fact, there are four categories of reality, and each has a different way of verifying it.

External Models (OpenAI, Anthropic, Google, and Others)

The most obvious dependency is the use of foundation models from other labs, which are typically the least investigated since a known provider name is supposed to be enough verification. Verifying third-party AI models involves more than just the brand: knowing where the data the model was trained on comes from, which regions process the data, whether the provider trains on submitted prompts automatically, and what change-management process is in place for changes to the model which may silently alter the model's behavior within a production application.

MCP Servers You Don't Host

MCP servers are the "glue" that makes agentic systems work; by using a common protocol, agents can access the internal tools, databases, and third-party services. Each credential and each tool call traversing that server has the same security posture. Each credential and each tool call that passes through that server has the same security posture.

MCP server dependency risk concretely emerges in the form of an under-secured MCP server that can be triggered to execute unauthorized tool calls, leak the context it was meant to protect, or be impersonated by a malicious server that pretends to be a trusted one. Since MCP servers are right in the middle of an agent and what it is managing, verifying MCP servers cannot be an afterthought that is attached to general vendors.

Agent Plugins and Skills

Plugins, skills, and tool definitions augment what an agent can achieve, and they tend to be the simplest of the dependencies to add and the most difficult to audit. A skill installed from a marketplace may contain instructions that are to be considered trusted context by the agent, and a tool definition may ask for permission on a level that goes beyond what it is describing. Verification here requires not only determining what a plugin says it does, but also what it is allowed to do upon installation.

Sub-Processors Embedded Inside Other Vendors' Products

There are many third-party AI dependencies that don't come in the name of AI; they're built into a CRM, support ticketing system, or HR application that added a generative AI feature. The vendor relationship dates back to the era before AI arrived, and it doesn't come up for re-review very often when the feature rolls out. That's how an organization finds itself with sensitive data going into a model they didn't sign up for, three layers deep in a contract they signed before it was available.

The Core Verification Practices

The first step is to name the dependency categories. The more difficult, continuous task is to develop a repeatable procedure that is actually used to validate them before and after deployment. The four below are the fundamental processes of that process and are roughly in the order they are discovered when first meeting a new dependency and then when it enters production.

Complete Inventory of Models, Datasets, Plugins, and MCP Servers

There is no one's inventory to verify it. The starting point is a complete list of all the models being used, all the datasets that are being used to train or retrieve, all the plugins and skills installed, and all the MCP servers an agent can reach, both those that are purchased separately from the formal review process. Active discovery is not only a manually maintained spreadsheet that gets stale the week after it's created, but it is also a method of shadow AI use that occurs enough that it is necessary for this inventory. This baseline provides a point to which the subsequent practices are bound; otherwise, there is no way of knowing that a practice exists for which a dependency is claimed.

Validating Model Provenance and Integrity Before Deployment

Model provenance validation is the process of determining the origin of a model: the lineage of training data, whether weights have been manipulated since they were released, and whether a "fine-tuned" model is actually a revised version of the original model that it purports to be. Integrity validation before deployment: Just as a build pipeline does a checksum or signature check before a software package ships to production, integrity validation before deployment does the same for the artifact itself before it ever reaches production. Without this step, you have to assume that a file retrieved from a registry is what its name implies.

Pinning Dependencies to Verified Versions

One of the quieter attack points in the AI supply chain is closed by the introduction of dependency pinning - the process of refusing to download the "latest" version of a model, plugin, or server, but only a fixed, known version. If the auto-updating dependency changes its behavior, permissions, or even ownership without anyone saying “OK”, a pinned version at least ensures that what was verified is what is running. Updates must be a conscious, reviewed action, not just a no-brainer for a package manager.

Continuous Monitoring for Unexpected Behavior

Pre-deployment checks address the question, "Was this safe when we approved it?" Continuous dependency monitoring is the answer to the more difficult question: is it still operating as it did on day one? The model can drift, a plugin update can sneak in a new permission, an MCP server can be compromised weeks after it's passed review – none of which a single integrity check can detect.

That's where runtime visibility proves its worth! Akto, for instance, continuously monitors the behavior of the AI agents and MCP connections in production instead of just reviewing the dependency as a single snapshot.

The Questions a Real Verification Process Should Answer

The majority of AI vendor risk questionnaires are still geared toward the traditional SaaS paradigm, which includes uptime, encryption at rest, breach notification timelines, and so on, and they leave out the questions that are important for an AI dependency. A verification process designed for this class must have answers to a shorter, more pointed set of questions:

Will your data train your models? Not "do you care about data privacy", but rather a direct question of whether prompts, outputs, or uploaded documents are used for model training or fine-tuning by default and how to opt out.

• Where does the data get really processed? Where it is being done, who is doing it, and whether it's inside the vendor's infrastructure or passed off to a fourth-party the contract never mentioned.

• What is below your product? What foundation model, what orchestration framework, what MCP servers or plugins the product itself relies on, it's only as secure as the base upon which it was built.

• Are you able to create model cards and audit logs on demand? A vendor who provides a model card that specifies training data used, intended uses of the model, and known limitations, as well as audit logs that identify which actions are associated with which agent or model version has actually developed the infrastructure to verify. You can't trust a vendor that says they can't.

If it's not a vendor risk questionnaire that asks these four questions in some variation, it's not a vendor risk questionnaire; it's just a vendor hygiene questionnaire with an AI hoodie on it.

AI Bill of Materials (AI BOM) as the Emerging Standard Artifact

Years ago, software teams addressed a related issue by creating a structured list of all the libraries and packages within an application: a Software Bill of Materials. The AI Bill of Materials (AI BOM) expands upon this concept to AI systems in particular: It is a structured, ideally machine-readable, list of models, datasets, prompts, agents, tools, and MCP servers used by an AI system, and how they are connected.

The best sign that this is becoming an industry standard idea over a niche one is the AI Bill of Materials (AI BOM) by Cisco, which can be used to scan code bases, container images, and cloud environments to automatically generate this type of inventory, models, agents, tools, MCP servers and clients, datasets, prompts, guardrails, and how they are orchestrated together - without forcing teams to document all this by hand. Cisco has also open-sourced the underlying scanner, which is a good indicator of where the industry is headed with this artifact: it's something that should be built by every vendor, it's not something that only security-mature organizations bother making.

Why is an AI BOM important for third-party AI security verification? Because "what's underneath your product" is no longer a question a vendor answers at a sales call; it is now a document that can be requested, compared across releases, and compared to what's running in production. Soon enough, an organization's capacity to create an AI BOM for its own systems and to request one from vendors will become as commonplace as a SOC 2 report.

The Cost of Skipping This

It is not idle risk-management etiquette, because the numbers have turned in the wrong direction. The IBM X-Force 2026 supply chain report, IBM's 2026 X-Force Threat Intelligence Index, showed that large-scale supply chain and third-party compromises have grown almost fourfold since 2020, largely due to attackers taking advantage of trusted developer identities, CI/CD automation and SaaS integrations to infect supply chains downstream, the very same types of trusted relationships that make AI dependencies dangerous.

The financial situation is no less bleak. The IBM Cost of a Data Breach Report 2025 revealed that the second-costliest attack vector measured is supply chain compromise, which costs $4.91 million per attack on average and was detected and contained at the longest time, of 267 days, compared to the other attack vectors, since the attacks are not driven by strong technical vulnerabilities but rather by the trust relationship. The same report revealed that 63% of breached companies either did not have an AI governance policy established or were working on creating one, while 97% of companies that suffered an AI-related security incident reported no access controls on AI at the time of the incident.

There is early policy-level reaction in regulated sectors. The Healthcare Sector Coordinating Council's Third-Party AI Risk Guide, created for an industry where AI tools lurk deep within electronic health records and out-of-hospital monitoring devices, is designed to uncover the AI supply chain discovery and disclosure gaps that currently make this risk so difficult to manage - and which will no longer be an acceptable response after an incident, in healthcare or elsewhere.

How This Differs from Evaluating a Security Vendor

Let's get a clarification about what this guide is not going to cover. The other thing you should do is, before you decide on an AI security vendor, determine whether their product is trustworthy or not as well, by verifying its certifications, asking the vendor how their controls are verified, and determining whether the claims are substantiated by an independent third party or not.

Third-party AI security verifications, discussed here, pertain to the models, MCP servers, and agent components that an organization consumes when creating its own AI systems. Vendor evaluation is related to a security tooling organization purchases to secure those systems. There is a degree of overlap here, of course – as a security vendor, you're also a third party, but they're different questions. To see a detailed breakdown of how to assess an AI security vendor in particular, see our guide to evaluating AI security vendors for enterprise AI agents.

How Akto Verifies Third-Party AI Dependencies

Akto's 3rd party AI dependency risk discovery is a problem of discovering and cataloging all the AI agents, MCP servers, and tool connections throughout an organization's infrastructure, cloud environments, and employee devices, including shadow AI and shadow MCP use that hasn't been reviewed. That inventory is categorized by behavior, PII exposure, and third-party dependencies, giving security teams a real picture of what they are running rather than a best-guess.

Then, Akto constantly probes agents and MCP servers with thousands of tests for prompt injection, privilege escalation, data leakage, and tool misuse, and sees if they actually perform as the documentation says they do in case of an attack. At the present time, Akto is monitoring production for unauthorized tool usage, unexpected agent loops, and access-pattern anomalies, which would seem to indicate a dependency started to behave differently since its time of review – and Akto has been deemed a representative vendor by Gartner for the AI agent security segment.

For teams that want to see how this works against their own AI agent and MCP environment, Akto offers a live walkthrough of its agentic security platform.

Final Thoughts on Third-Party AI Security Verification

Security of AI agents doesn't stop at the application level, but at the dependency level. An organization can configure their agents to be hardened, and still be compromised by an unverified model, unmonitored MCP server, or plugin update that no one had checked. That's where third-party AI security verification - inventory, provenance validation, dependency pinning and continuous monitoring - comes in, and an AI BOM is emerging as the artifact to verify it.

Akto makes it possible for security teams to do this: identify all of the AI agents and MCP connections on the infrastructure, cloud and employee devices, simulate them under real attack scenarios and keep an eye on their performance in live production. To gain an idea of what this will look like on your own AI stack, book an Akto's agentic security demo.

FAQs: Third-Party AI Security Verification

What is third-party AI security verification?

Third-party AI security verification is the process of ensuring that the AI models, servers, plugins, and other elements that an organization relies on but has no direct control over are safe (provenance, integrity, and ongoing behavior) instead of assuming they are safe because a vendor says they are.

How is this different from evaluating an AI security vendor's own certifications?

When you buy a security tooling product, you ask questions about vendor evaluation, which includes the certifications of the product, the security features built into the product, and the claims that are being made. Third-party AI security verification questions the safety of the AI pieces you use to create your own systems, AI models, MCP servers, and plugins. They are related and separate exercises.

What counts as a third-party AI dependency?

There are four general types: external foundation models from vendors such as OpenAI, Anthropic or Google; MCP servers that run on other vendor infrastructure; agent plugins and skills that are offered through marketplaces; and sub-processors that are built into other vendors' products, that are not necessarily identified as AI capabilities.

What is the "hidden sub-processor" problem in AI supply chains?

It is the 4th-party exposure that occurs when a 3rd-party AI vendor uses its own suppliers, such as a foundation model, a vector database, or an embedding service, that the organization didn't choose, doesn't review, and doesn't know about until something goes wrong.

Why does a compromised agent plugin look like a feature update instead of malware?

A malicious change could be a slightly altered prompt or a new permission scope, rather than a recognizable binary, because agents rely on natural language instructions to determine what to do. It is distributed by the same update method as a proper bug fix and hence is not detected by signature scanning.

What is an AI Bill of Materials (AI BOM)?

An AI BOM is a description of the models, datasets, prompts, agents, tools, and MCP servers within an AI system, and their relationships. There are tools such as AI BOM scanner from Cisco that automate the process of creating a BOM, which transforms "what's underneath your product" from a sales call answer into a document.

What questions should a third-party AI verification process actually ask?

At least: is the data fed to our models; who are the sub-processors that process it; on what models is your product based; and can you provide model cards and audit logs on demand, not just a general security statement?

How much do supply chain and third-party AI compromises cost on average?

According to the IBM Cost of a Data Breach Report 2025, the second most expensive attack vector is related to the supply chain and third-party compromises, which have an average cost of $4.91 million per breach and require 267 days on average to detect and contain.

What percentage of breached organizations lacked AI governance policies at the time of the breach?

The same IBM report found that 63% of breached organizations did not have an AI governance policy or were still working on one, while 97% of those that had an AI-related breach did not have appropriate AI access controls.

How does third-party AI verification relate to MCP supply chain security specifically?

An unverified MCP server is one of the most powerful and major third-party AI dependencies to get right, since it is in the middle of the action between an agent and tools or data that the agent affects. To detect the risk of dependency on an MCP server, this is about evaluating what a server can access, and not only whether it is accessible or not.

How does Akto verify the security of third-party AI dependencies?

Akto automatically identifies all infrastructure, cloud, and employee devices for AI agents, MCP servers, and tool connections, categorizes them by third-party dependency and PII exposure risk, and continually automates the red teaming process against them, while monitoring runtime to detect unauthorized tool calls and anomalous activity upon deployment.