How can organisations reduce risk from community-built AI plugins?

Why This Matters for Security Teams

Community-built AI plugins are attractive because they accelerate experimentation, but they also expand the trusted computing base in ways many teams do not fully inventory. A plugin that can accept credentials, call an LLM, reach a local model endpoint, or write state back into an output channel can become a privileged integration point rather than a simple add-on. That makes plugin review an NHI control problem as much as a software supply chain problem, especially when secrets are involved, as shown in NHIMG research such as JetBrains Marketplace AI Plugin Campaign and the LLMjacking: How Attackers Hijack AI Using Compromised NHIs findings from Entro Security. The operational risk is not only malicious code, but also unsafe data handling that leaks tokens, serialized state, or prompts into places defenders do not monitor. Current guidance from the NIST Cybersecurity Framework 2.0 still applies, but it must be extended for agentic integrations. In practice, many security teams discover plugin overreach only after a credential has already been reused, exfiltrated, or embedded into downstream logs.

How It Works in Practice

Reducing risk starts by treating each plugin as a third-party node with defined trust boundaries, not as a harmless productivity extension. Security teams should require a pre-approval review that checks what the plugin can read, what it can transmit, and whether it stores secrets locally, in memory, or in serialized output. For plugins used with image generation, LLM calls, or local model endpoints, the review should also cover whether the plugin can chain requests, trigger external tools, or persist conversation context beyond the task that created it. A practical control set usually includes:

• Approval only for plugins with a documented data flow and a named owner.
• Secrets supplied by vault or broker, never hardcoded in plugin settings.
• Short-lived tokens with scope limits, rather than standing credentials.
• Static analysis and manual review for prompt handling, serialization, and logging.
• Network egress restrictions so the plugin cannot quietly move data to unapproved endpoints.
• Continuous revalidation when the plugin updates, because behaviour can change outside the original review.

This is where NHI governance becomes practical: plugins that can accept credentials should be assessed like privileged workloads, because token theft and silent reuse are common failure paths in AI tooling. The NHIMG The State of Secrets in AppSec research highlights how persistent secrets management gaps widen the blast radius once a plugin mishandles credentials. For implementation guidance, align review criteria with the OWASP NHI Top 10 and NIST’s focus on asset, identity, and recovery controls in the NIST Cybersecurity Framework 2.0. These controls tend to break down when plugins are allowed direct internet access and broad token scopes because reviewers cannot reliably observe all downstream data paths.

Common Variations and Edge Cases

Tighter plugin control often increases delivery friction, so organisations have to balance developer agility against credential exposure and data leakage risk. Best practice is evolving for community-built AI plugins, and there is no universal standard for every environment yet, especially where teams mix local models, hosted LLMs, and internal workflow automation. A few edge cases deserve special handling:

• Plugins that only transform prompts still need review if they can log inputs or outputs containing secrets.
• Open-source plugins with active communities may be safer than obscure forks, but reputation is not a control.
• “Read-only” plugins can still leak data if they serialize context into telemetry, caches, or crash reports.
• Plugins running in developer laptops need the same NHI policy checks as production extensions if they can access live credentials.

For deeper governance, use the Top 10 NHI Issues as a checklist for secret handling, privilege scope, and monitoring expectations. Community plugins are most dangerous when teams assume their risk is bounded by the UI layer, because the real exposure often sits in hidden credential paths and unreviewed state persistence.

Related resources from NHI Mgmt Group

• How should teams reduce the risk of exposed AI credentials being abused?
• How should teams reduce risk from malicious npm package installs?
• How can organisations reduce shadow AI risk without blocking adoption?
• How can organisations reduce risk from AI tools without banning them?