LLM Supply Chain Attack Checklist: Packages, Plugins, Extensions

Defining the LLM supply chain

OWASP's Top 10 for LLM Applications treats supply chain vulnerabilities as a distinct risk category covering third-party models, data, plugins, and dependencies, separate from insecure plugin design, which addresses plugins that accept free-form input or request excessive permissions. In practice, enterprise LLM applications accumulate risk through four overlapping component types.

Language-ecosystem packages arrive through standard dependency management and inherit the trust weaknesses of PyPI or npm, since those registries were not built with LLM-specific risks in mind. Plugins registered with a platform marketplace often accept model-generated input directly, which is a structural difference from traditional applications where input validation happens at a defined boundary. MCP servers expose tools, resources, and prompts to a connected model, with the access each server receives determined by how the host application configures and authorizes it, not by the model itself. Browser and IDE extensions inherit whatever permissions the host application grants, which can be broader than the extension's stated function requires. Treating these as one undifferentiated category obscures where risk actually concentrates.

Where static vetting stops

Pre-deployment review answers a narrow question: what does this component claim to need at install time. It does not answer what the component actually does once a model starts calling it in production. MITRE ATLAS frames AI supply chain compromise as something that can occur at multiple lifecycle stages, including deployment, which means a component that passes intake review can still behave differently after an update, or exploit permissions it was granted but rarely uses.

This matters most for components with tool-call or function-execution capability, since OWASP's plugin design guidance identifies these as carrying materially higher risk than components that only process text. A plugin or MCP server that accepts model-generated input as its trust boundary, rather than validated user input, can be manipulated indirectly through the model itself, a path that manifest review and dependency scanning were never designed to catch.

Governance and ownership

A checklist only works if someone owns the process. Security teams should assign clear responsibility for approving and periodically re-approving third-party LLM components, distinct from general software procurement, since procurement review typically does not evaluate tool-call permissions or transitive AI-specific risk.

NIST's AI Risk Management Framework recommends managing third-party component and data source risk across the AI lifecycle, which supports maintaining a living inventory of approved packages, plugins, and MCP servers alongside their documented permission scope, rather than a one-time approval record. That inventory needs a defined escalation and revocation procedure for components later found to exceed their granted scope or exhibit unexpected behavior, and audit trails for tool-call activity to demonstrate runtime control, since vetting artifacts alone do not satisfy that requirement.

Runtime governance platforms, including capabilities for agent identity, permissions enforcement, and audit logging, are one place these operational requirements get implemented, though the governance decisions, ownership, and escalation criteria remain the security team's responsibility regardless of tooling.

Evaluation questions for third-party LLM components

Work through these questions during intake and re-approval reviews.

• What permissions does a package, plugin, or MCP server actually need?

  Compare the component's requested permissions against the minimum access required for its stated function. MCP server scope in particular depends on host application configuration, so authorization should be reviewed explicitly rather than assumed to default to least privilege.

• How do we verify a component's provenance?

  Check whether the maintainer provides sufficient source and update history to confirm origin. Standard package registries were not built with AI-specific safeguards, so provenance for LLM tooling should be verified with the same rigor applied to other production dependencies.

• How is runtime behavior monitored after deployment?

  Static review cannot observe how a component behaves once it has tool-call access in production. Tool-call logging and monitoring are needed to detect behavior that diverges from the component's declared function after it has been granted access.

• What happens if a component is later found to be over-permissioned?

  Define a revocation and escalation procedure in advance. Without a documented process, discovering that a component exceeds its intended scope does not translate into a timely reduction of its actual runtime access.

• Are transitive dependencies reviewed, not just the direct package?

  A manifest review of a single package or plugin often misses dependencies it pulls in indirectly. Transitive dependency identification should be part of the intake process, not an afterthought handled only during incident response.