AI Plugins Are the New Software Supply Chain

As AI systems become extensible through skills, apps, MCP servers, and reusable agent workflows, installing a capability starts to look less like adding a prompt and more like adding a software dependency.

The first generation of AI customization looked relatively harmless. Teams wrote system prompts, saved prompt templates, added retrieval, and perhaps wrapped a few internal APIs with function calls. Most of the logic remained inside an application that engineering teams built and controlled themselves.

That boundary is changing quickly. AI platforms are increasingly becoming extensible ecosystems where reusable capabilities can be installed rather than built from scratch. A plugin may contain instructions that shape how an agent behaves, executable code, connections to external systems, tool definitions, authentication requirements, and workflows that coordinate several of these components together. OpenAI's current plugin architecture, for example, allows a plugin to package skills, apps, and app templates. Skills themselves can contain instructions, examples, supporting resources, and code, while apps connect ChatGPT or Codex to external data and actions.

That is a fundamentally different security object from a prompt.

Once a reusable AI extension can influence reasoning, execute code, access repositories, query databases, send messages, update CRM records, or invoke business workflows, organizations should stop treating plugin installation as a productivity preference. It becomes a software supply-chain decision.

The closest analogy is no longer a browser bookmark. It is closer to installing an npm package, enabling a GitHub Action, adding a browser extension, or deploying a SaaS integration.

And we already know how much security engineering those ecosystems eventually required.

A plugin is becoming a package of authority

The term “plugin” can make these systems sound simpler than they are. In practice, several independent forms of authority may be bundled behind a single convenient capability.

An instruction layer can influence how an agent interprets requests and makes decisions. A code layer can execute logic that users may never inspect directly. A tool layer can expose operations such as reading a repository, writing a file, sending an email, querying a database, or creating a ticket. An integration layer can authenticate against external systems. A workflow layer can connect these pieces into an automated sequence that runs with relatively little human involvement.

This is why the security model cannot stop at asking whether a plugin itself is “trusted.” The more useful questions are what components it contains, what systems those components can reach, what permissions they inherit, what code will run, and which actions require additional approval.

OpenAI's current architecture illustrates this separation clearly. Installing a plugin does not itself grant arbitrary access to connected systems. Underlying apps retain their own permissions, administrators can scope access by role, and action controls or confirmation requirements can be configured independently. If the user does not have access to a resource in the source system, a plugin should not magically create that access through Codex or ChatGPT.

This is the right architectural direction because a package and its authority should be separate concepts. Installing an AI workflow should not implicitly mean granting it every permission it might ever need.

Software security learned this lesson through operating systems, cloud IAM, OAuth scopes, mobile applications, and browser permissions. AI extension ecosystems are now encountering the same problem in a new form.

We have seen this movie before

Modern software depends on enormous dependency graphs. A developer may explicitly install a handful of packages while indirectly trusting hundreds of transitive dependencies. That productivity has been transformational, but it also created an attack surface where compromised maintainers, malicious packages, dependency confusion, stolen credentials, vulnerable build systems, and poisoned updates can spread through organizations at extraordinary speed.

AI plugins introduce a similar dependency problem, except the dependency is no longer limited to conventional executable code. An AI extension can also influence the behavior of a model through natural-language instructions and context.

That distinction matters because traditional application security largely assumes a reasonably deterministic execution model. Code enters the system, software executes it, and security tools can inspect binaries, dependencies, API calls, network activity, and permissions. Agentic systems add another layer: content itself can affect execution.

A malicious dependency does not necessarily need to contain an obvious rm -rf or credential-stealing function. It could manipulate what an agent believes it should do, which tool it chooses, how it interprets retrieved information, or whether it considers an action safe.

This is part of what makes AI supply-chain security more complicated than conventional package scanning. We may need to inspect both what software executes and what instructions influence the agent executing it.

The MCP ecosystem makes the potential consequences particularly concrete. MCP's official security guidance warns that local MCP servers may execute binaries or startup commands on a user's machine and can therefore introduce arbitrary code execution, data exfiltration, privilege escalation, and data-loss risks if installed from an untrusted source. The guidance recommends explicit consent, visibility into commands being executed, sandboxing, and minimal privileges for local servers.

That is software supply-chain language, even if the ecosystem surrounding it is still new.

MCP turns integrations into a security boundary

Model Context Protocol has become an important part of this conversation because it standardizes how AI applications connect to external tools and resources. Standardization is valuable: developers no longer need to invent a bespoke integration architecture for every agent and every system.

But standardization also creates a reusable security boundary. If an MCP server exposes powerful operations, the client and server must correctly authenticate users, validate tokens, scope permissions, and prevent capabilities from leaking across trust boundaries.

The MCP specification explicitly requires token audience validation for protected HTTP resources and prohibits blindly passing upstream credentials through to downstream services. Its security guidance documents risks such as confused-deputy attacks, token theft, server-side request forgery, session hijacking, and malicious local MCP servers. It also recommends progressive least privilege rather than granting large omnibus scopes up front.

These are not theoretical concerns unique to AI. They are familiar identity and distributed-systems problems appearing inside a new execution model.

Suppose an employee installs an AI development extension that can read GitHub repositories, execute commands locally, interact with a cloud environment, and access an issue tracker. Individually, each capability might be legitimate. Combined, they create a potentially powerful execution path across source code, credentials, infrastructure, and organizational data.

Now consider what happens when an agent consumes untrusted content from an issue, README, repository file, website, or external tool response while possessing those capabilities.

The trust graph becomes much more complex than:

user → AI model

It begins to look like:

user → agent → plugin → skill → MCP server → external API → organization data

with untrusted content potentially entering at several points along the way.

Security therefore needs to reason about the entire chain.

Prompt injection becomes a supply-chain problem too

Prompt injection is often discussed as a vulnerability of models, but extensibility turns it into a problem for the surrounding ecosystem as well.

Imagine that an agent has access to an installed workflow for reviewing repositories. The workflow gives the agent instructions about how to inspect code, which tools to use, and how to prepare the final result. During execution, the agent opens a repository containing adversarial instructions embedded in a file. If the agent cannot reliably distinguish those instructions from trusted workflow guidance, the malicious repository may influence how installed tools are used.

This does not necessarily mean the plugin itself is malicious. A perfectly legitimate plugin can become part of an unsafe execution chain if it exposes excessive capabilities or if the surrounding runtime lacks sufficient isolation.

That distinction is important.

In conventional security, we separate a vulnerable library from a malicious library. AI systems need another category: a legitimate capability that becomes dangerous in an adversarial context.

This is why simply building a marketplace of “verified” AI extensions will not solve the entire problem. Publisher identity helps. Code scanning helps. Reviews help. But a trusted plugin interacting with untrusted content can still produce unsafe behavior if permissions and runtime controls are too broad.

Plugin security therefore needs both supply-chain controls and runtime controls.

We should verify what we install, but we should also assume that installed components will eventually encounter hostile input.

What an enterprise AI plugin security model should look like

A mature enterprise plugin ecosystem will probably converge toward controls that already exist elsewhere in software engineering, adapted for agentic execution.

The first is publisher provenance. Organizations should be able to determine who produced a plugin, whether that identity has been verified, and whether ownership has changed. Anonymous code with broad enterprise access should eventually feel as uncomfortable as installing an unsigned binary from an unknown website.

The second is package integrity and versioning. A reviewed plugin should correspond to an identifiable artifact. Updates should not silently transform its behavior or permissions. Organizations will need version pinning, change histories, controlled upgrades, and eventually some form of artifact signing or equivalent integrity verification.

The third is a permission manifest. Before installation, administrators should be able to understand what the capability needs: repositories, file systems, messaging platforms, CRM records, databases, network destinations, execution environments, or write operations. More importantly, permissions should be specific enough to support least privilege rather than a generic “full access” checkbox.

Current platforms are already moving in this direction. OpenAI separates plugin installation from underlying app access and allows enterprise administrators to control which roles can use apps, whether apps can take actions, and when user confirmation is required. Custom MCP apps must be reviewed and published by authorized administrators before wider deployment, and OpenAI explicitly warns that custom apps are not verified by OpenAI and should only be added when the organization trusts the underlying application.

The fourth requirement is static and behavioral inspection. Conventional scanners can inspect dependencies and code. AI-specific scanners may additionally need to examine embedded instructions, tool declarations, network destinations, suspicious startup commands, hidden resources, or unexpected privilege requirements. Runtime testing may be equally important because some dangerous behavior only appears when an agent interacts with particular inputs.

The fifth is sandboxing and egress control. An extension that executes code should not automatically inherit every file, secret, credential, network route, and cloud permission available on the host machine. MCP's security guidance explicitly recommends sandboxing local servers and restricting access to the filesystem, network, and other resources.

The sixth is auditability. Organizations should know when a plugin was invoked, by whom, which tools it used, what privileged operations occurred, and which external systems were contacted. This becomes especially important when agents operate asynchronously and users are not watching every individual action.

Finally, organizations need revocation. If a plugin or integration is discovered to be compromised, there must be a fast way to disable it, invalidate credentials, prevent new executions, and identify previous activity. A marketplace without an incident-response mechanism is not a mature enterprise ecosystem.

Together, these controls form something similar to the security infrastructure that grew around package managers, mobile app stores, OAuth applications, and cloud marketplaces.

The dangerous part is not only third-party plugins

It would be easy to conclude that the solution is simply to ban external plugins and let employees build internal ones.

That would reduce some risk, but it would not eliminate the supply-chain problem.

Internal AI capabilities also have dependencies. An internally created skill may reference external libraries. An MCP server may use third-party packages. A workflow may depend on an external SaaS API. A developer may copy a community integration into an internal repository and modify it. An agent could generate part of the implementation itself.

The distinction between “internal” and “external” therefore becomes blurry.

Even entirely internal workflows need ownership, review, testing, versioning, permission boundaries, and maintenance. Anthropic's own guidance for scaling Claude in legal organizations reflects this operational reality: it recommends intentionally governing how skills are quality-controlled, tested before rollout, and maintained after deployment, with successful workflows eventually distributed through administrator-managed plugin marketplaces.

This resembles internal platform engineering more than casual prompt sharing.

Companies already operate internal package registries, service catalogs, Terraform module libraries, CI templates, and developer portals. I expect many organizations to eventually maintain an equivalent AI capability catalog: an approved set of skills, agents, MCP servers, tools, and workflow components that teams can safely reuse.

That catalog will need owners.

It will need versions.

And it will need security review.

Convenience will drive adoption faster than governance

The supply-chain analogy matters because reusable ecosystems create enormous economic pressure toward convenience.

Developers use npm because rebuilding every utility from scratch would be irrational. Teams install GitHub Actions because reusable automation is faster than creating custom CI machinery for every repository. Organizations integrate SaaS platforms because building equivalent capabilities internally would cost far more.

AI plugins will succeed for exactly the same reason.

If an engineer can install a production-ready workflow for investigating incidents, reviewing pull requests, generating analytics, interacting with a design system, or managing project tickets, rebuilding the same capability internally will often make little sense.

The better these ecosystems become, the more rapidly organizations will accumulate AI dependencies.

That is when governance usually arrives.

Software history repeatedly follows this pattern: an ecosystem begins with experimentation, convenience creates widespread adoption, serious incidents reveal hidden trust relationships, and security infrastructure develops afterward.

AI engineering has an opportunity to compress that learning cycle.

We already know the likely requirements.

Do not grant unnecessary permissions. Separate code from credentials. Verify publishers. Pin dependencies. Review changes. Sandbox execution. Monitor privileged actions. Maintain inventories. Make revocation possible.

The new part is applying those principles to components whose behavior may include both deterministic code and probabilistic model instructions.

An AI SBOM may eventually become necessary

One possible consequence is an AI equivalent of the Software Bill of Materials.

A conventional SBOM tells an organization which software components exist inside an application. For an agentic system, we may eventually need something broader.

Which model is being used? Which skills influence its behavior? Which plugins are installed? Which MCP servers can it call? Which external systems are connected? Which permissions are available? Which versions are deployed? Which tools can perform destructive actions? Which components came from external publishers?

Call it an AI Bill of Materials, an Agent Bill of Materials, or something else entirely. The name matters less than the underlying requirement: organizations cannot govern dependencies they cannot see.

This becomes even more important when one plugin depends on another capability, or when agents dynamically select tools at runtime. The dependency graph will not necessarily look like a traditional static package tree. It may look more like a graph of potential authority.

That suggests that the most useful inventory may include not only:

component → dependency

but also:

component → capability → permission → resource

Security teams could then answer a much more useful question:

If this component is compromised, what can it actually reach?

That is the question supply-chain security ultimately needs to answer.

The plugin marketplace will become part of the enterprise control plane

This connects directly to the broader evolution of enterprise AI.

As I argued previously, AI platforms are moving beyond the model layer toward a control plane that governs identities, permissions, policies, approvals, evaluations, observability, economics, and agent lifecycle.

Plugin governance naturally belongs inside that control plane.

An enterprise should eventually be able to define policies such as: only approved publishers may be installed; finance agents cannot use plugins with unrestricted external network access; production write tools require explicit approval; engineering roles may install development plugins but not HR integrations; vulnerable versions are automatically disabled; and high-risk capabilities require security review before organization-wide rollout.

At that point, the plugin ecosystem becomes analogous to a combination of an app store, package registry, IAM system, and internal developer platform.

That is a far more important role than “a place to download prompts.”

OpenAI's July 2026 migration from an app directory to a broader Plugin Directory is an interesting signal in this direction. Plugins are now positioned as packaged workflow capabilities across ChatGPT and Codex, potentially combining reusable skills with connected apps and templates, while administrators separately govern installation and underlying access.

The architecture is still evolving, and different vendors will undoubtedly use different terminology. But the pattern is becoming visible.

AI systems are becoming extensible.

Extensibility creates dependencies.

Dependencies create trust relationships.

And trust relationships eventually require supply-chain security.

Treat AI capabilities like production dependencies

For engineering leaders, the practical takeaway is straightforward: establish the governance model before the plugin ecosystem inside your organization becomes too large to understand.

You do not need an elaborate security bureaucracy for every experimental skill. Development environments should remain easy to explore. But there should be a clear boundary between experimentation and production deployment, especially when a capability receives persistent credentials, write access, access to sensitive data, or permission to execute code.

A useful production review can begin with a small set of questions. Who owns this capability? Where did it come from? What code and instructions does it contain? Which systems can it reach? What permissions does it receive? What untrusted input can it consume? Which actions require approval? How is its behavior logged? What version are we running? How do we disable it if something goes wrong?

If those questions sound similar to the questions security teams already ask about software dependencies and SaaS integrations, that is precisely the point.

We are not inventing an entirely new category of security from scratch.

We are extending familiar software-supply-chain principles into a world where dependencies can reason, interpret instructions, invoke tools, and act.

The AI industry spent its first phase making models more capable.

The next phase is making those capabilities reusable.

Reuse will create enormous leverage, but it will also create dependency graphs that few organizations currently understand.

And once an installed component can influence both what an agent thinks and what an agent can do, the package you install is no longer just a productivity enhancement.

It is part of your software supply chain.