Plugin and Tooling Security: LLM03 Supply Chain Risks in Practice

Last updated on September 19th, 2026 at 04:17 pm

Everybody fixates on quick drug delivery and jail escapes. Ok then – those are headlines. Seldom mentioned in the background, LLM supply chain security is becoming one of the biggest weaknesses in today’s AI systems.

OWASP calls its list of the top 10 risks the LLM03 Supply Chain Vulnerabilities. And, truly speaking, the name is a misnomer for how harmful it is.

The fundamental issue is this: large language models are no longer isolated. They are attached to plugins, invoked through external tools, executed within IDE integrations, and they call third-party APIs during the conversation. All such connection points are potential entry points for attackers. Not logically abstract ones, but real ones with attached CVEs.

It breaks down what LLM03 means in practice, where the real risk lies (some risks you may already be dealing with right now), and what secure patterns look like when teams execute them properly.

What OWASP LLM03 Actually Covers

The Supply Chain Problem Is Bigger Than You Think

By defining LLM03, OWASP wasn’t referring to a model’s weights or training data. The supply chain of a modern application powered by an LLC is:

• Third-party pre-trained models.
• Fine-tuning datasets that have been fetched from publicly available or semi-public sources.
• Tool extensions in the form of Plugins and tools the model doesn’t do.
• AI coders integrated directly into developer programs.
• Context feeding: context in prompts via vector databases and retrieval systems.
• Automatic deployment pipelines of model changes.

All these can be undermined. And because LLM applications move so fast (in practice, startups run businesses, developers integrate whatever works), security considerations often aren’t considered before building new features and, in fact, are rarely considered at all.

According to the OWASP LLM Top 10 project, the notion of supply chain risk is vaguely defined: any compromised components, insecure integrations, as well as lack of proper vetting of tools trusted by your LLM, are considered a threat. The latter is the trickiest part: trustInsecure Plugins: How LLMs Get Exploited Through Extensions.

Plugins Operate With Inherited Trust

One thing isn’t clearly stated: connecting a plugin to an LLM often depends on the model’s access level. So, if your LLM can access a database, file system, or an API, and there is a plugin that can execute operations in that LLM context, then the action of the plugin will be capable of doing the same.

I have tried several LLM frameworks with plugins, and the obvious difference is that there’s little friction between the model and the environment where the plugin runs. An ill-intentioned or poorly written plug-in may:

• Exfiltrate conversation context
• Make unaddressed API calls.
• Alter outputs before passing them to the user.
• Vitalize prompted content in the future.

This risk was revealed early through the ChatGPT plug-in ecosystem – through all ChatGPT Models where the tool can be used. Researchers demonstrated that indirect prompt injections could occur through plugins, where content delivered to a model by a plugin included instructions to redirect the model’s behavior. The model had no native mechanism to distinguish between data and a plug-in instruction.

Real Exploits, Real CVEs

This is not hypothetical ground. The rise of code assistants in IDEs, such as GitHub Copilot and other AI code assistants, has revealed weaknesses in their ability to parse local environment context.

In the actual sense, the risk presents itself in the following form:

• A developer installs an AI extension in a coding assistant like VS Code.
• The extension brings context to the open project – files, configs, even.env variables.
• If the extension is compromised, or if it phones home to an attacker-controlled server, it can leak that local context.

Apparently, VS Code extensions (not necessarily AI-specific) have been spotted transferring data to third-party endpoints. As the number of AI-powered extensions grows, so does this attack surface.

In my experience, most developers who use AI coding assistants don’t check an extension’s network permissions, requested scopes, or update history before installing it. The tool is good; it serves its purpose; that is the only point of vetting that occurs.

Unvetted Tools and Third-Party Model Risk

When the Tool Is the Threat

Beyond plugins, LLM-based applications increasingly depend on external tools via frameworks such as LangChain or AutoGPT-style agents, or custom orchestration. These tools might:

• Execute code
• Browse the web
• Write and read files.
• Make external API calls to the user.

Whenever one of these tools is a part of a third-party package – a PyPI library, an npm package, a third-party-provided integration- it becomes a part of the supply chain. And community-contributed does not imply being security-reviewed.

Python and JavaScript ecosystems have a long history of malicious packages pretending to be other legitimate packages (typosquatting). That trend is currently spreading into AI tooling. Anything that identifies itself as a LangChain memory extension or a vector DB connector could harvest an API key or inject a malicious instruction into the LLM’s tool-call outputs.

Pre-trained Models From Unverified Sources

Hugging Face hosts hundreds of thousands of models. Most are legitimate. Some aren’t.

Scholars have shown that serialization exploits can be present in models deployed in community repositories, e.g., Pickle, which Python uses to store model weights. A load command that loads a model from an unverified source may execute arbitraryary coon thethe host machine before training or inference begins; in several developer tutorials, users load models without much evaluation of the source account, download count, or community flags. The ease of importing pretrained models creates an illusion of security, as it looks like a regular import rather than a potential remote code execution exploit.

AI Coding Assistants: The Trusted Insider Risk

Why IDE Integrations Are Uniquely Dangerous

AI coding assistants, Copilot, Cursor, Codeium, Tabnine, etc., are in an advantaged position. They can have access to:

• Open-source files in the entire project.
• Some of these configurations use terminal and shell context.
• Commit messages and Git history.
• Environment variables when not in isolation.

This is because they are high-value targets. An insider attacker may also read not only your current file but also whatever secrets you have, what architecture choices you have made, and what API endpoints you have.

The AI influencers in the developer demographic, the most vocal engineers and tech teachers with huge followings, have begun to raise flags on this. When they do, the discussion generally comes down to one core question: who is actually reading the code being sent to these models, and what is being stored server-side?

Most assistant providers state in their privacy policies what they retain. Most developers have not read them.

The Update Problem

This is a supply-chain peculiarity that’s easy to miss: automatic updates.
When an AI coding assistant has been updated without any notification (this is the default configuration of most extensions in IDEs):

• Request new permissions
• Change the data sent to the model provider.
• Add a dependency with a known CVE.

Without version transparency and managed updates, developers release unthinkingly into an ever-changing target. The extension that they had vetted in January is not necessarily the one that runs in July.

Secure Patterns That Actually Work

Allow-Lists: Don’t Trust, Verify

Strict allow-lists are one of the best mitigations against the risk of using plug-ins and tools. We don’t ask what we should block, but what we have expressly sanctioned.

Concretely, this is to be:

• Approved plugin registries – the LLM can only interface with plugins on a curated, internally reviewed list.
• Tool call restrictions: The LLM may only use tools from a specific set of authorized functions.
• API endpoint allow-lists: outgoing calls from the LLM’s execution environment are confined to authorized domains.

As a result, this strategy minimizes the blast radius if any of these components are compromised. The potential damage is lower than with open network access because a plugin can only call three authorized endpoints and read one data source.

Sandboxing LLM Tool Execution

Sandboxing provides isolation through a technical layer. In a case where the tools of an LLM are executed in a sandboxed environment:

• Access to the file system is restricted to specific directories.
• An allow-list screens network access.
• Process execution is managed or blocked.
• Memory access cannot leak into the host environment.

Tools such as gVisor, Firecracker-based microVMs, and container-level isolation (with appropriately scoped network policies) can help. It is aimed at ensuring that, in case of a tool misbehavior – or a plug-in being exploited – the environment the application is running in contains the harm.

Automated, infrastructure-level threat containment fits well with this. A system with anomalous tool-behavior detection (unusual outbound calls, unusual outbound data volume, repeated unsuccessful API calls, etc.) can then automatically isolate the system before a human is even notified to review the alert. This comes in handy particularly in agentic LLM systems which operate with a small amount of human supervision.

Reviewing Plugin Code Before Deployment

This one seems to be self-evident. It rarely happens.
A practical assessment of the security of the plugin should consist of:

Static analysis:

• What are the external requirements of the plugin?
• Are those requirements pegged to particular versions?
• Are there any known CVEs on those dependencies?

Behavioral review:

• What is the plugin’s actual functionality?
• Does it generate any uninvestigated calls on any network?
• Does it store or log any input/output data?

Permission audit:

• What is the requested scope of the plugin?
• Is it so much the better, requiring all of them to be in line with its declared purpose?
• What then happens in case those scopes are annulled?

I tested a couple of open-source LangChain applications and realized dependency pinning isn’t reliable. Most of them stipulate minimum versions using >= instead of precise versions, meaning a transitive dependency attack in the supply chain could drift unnoticed into the next install.

Version Transparency and Controlled Updates

Since the risk of update highlighted above is real, the teams that work with LLM tooling should define:

• Production LLM: All major packages and plugins are pinned.
• Review of the changelog as one of the approval procedures for updates.
• Dependency scanning of each build: Every dependency version. Code that depends on another package can encounter hidden vulnerabilities before it reaches production.
• Plugus rollouts use a stage model for Plugus updates, with behavior checks between phases.

Version transparency is also knowing the version of the model you are calling. Other LLM hosting providers do not have versioned URLs to update their model endpoints, so gpt-4 today may not be the same as it was last month.

This matters for security-sensitive applications, and locking to specific model snapshot versions where available is the right solution.

LLM03 in the Context of a Broader Security Strategy

Plugin and Tooling Security: LLM03 Supply Chain Risk in Practice Falls Within a Bigger Attack Surface.

LLM03 does not work in isolation. Other risks in the OWASP LLM Top 10 will interact with supply chain vulnerabilities:

• LLM01 (prompt injection) is potentially transmitted through a compromised plugin.
• Tools with overly permissive, insecure permissions can enable LLM06 (sensitive information disclosure).
• Unvetted models can enable LLM02 (insecure output handling) when the model is trained to produce malicious outputs.

LLM application security: Security teams should not treat tool and application security as a disjointed, unrelated checkbox in their risk model.

LLM Supply Chain Security finally demands the same amount of discipline as for the traditional software supply chains – only more so due to the behavior of the components (models, plugins, tools) usually being non-deterministic and behavior testing being progressively more difficult than in the traditional code.

What Good Looks Like: A Quick Reference

Wrapping Up

As with LLM systems, r supply chain risk is not novel, but it is one of the old software supply chain problems with a fresh face. However, because AI tooling is among the most rapidly adopted technologies, and because AI code assistants and code loading often come with privileged access, this is becoming more urgent than many teams currently realize.

A common surface solution is to apply to all plugin, tool, and third-party model components some combination of the approaches a security-sensitive team uses for any third-party dependency: explicit vetting, scoped permissions, version management, and behavioral monitoring.

The creation of such habits today, in allow-lists, sandboxing, code review, controlled updates, etc., will prove much more helpful as LLM applications become increasingly more complex and, as will inevitably happen, as the attacks against them become more clever.

Pranay Sai Aduvala

I’m a technology writer passionate about AI and digital marketing. I create engaging and useful content that bridges the gap between complex technology concepts and digital technologies. My writing makes the process easy and engaging. I encourage participation I continue to research innovation and technology. Let’s connect and talk technology!