What do organisations get wrong when they rely on marketplace approval as their main AI plugin control?

Marketplace approval is only one signal. A plugin from an official directory can still be risky if it reads sensitive files, spreads across endpoints, or changes behavior after installation. Teams often miss provenance, endpoint count, and runtime effects. Effective control requires inventory, behavioral review, and ongoing monitoring, not just a trusted listing.

Why This Matters for Security Teams

Marketplace approval creates a false sense of trust. A plugin can come from an official directory and still request broad file access, exfiltrate data through legitimate APIs, or change behavior after installation. That is the core failure: teams confuse directory vetting with runtime safety. In practice, the control gap becomes visible only after an endpoint inventory, data exposure review, or incident response exercise, not during the approval process.

Security teams should treat approval as one input, not a final decision. Guidance from NIST SP 800-53 Rev 5 Security and Privacy Controls supports continuous monitoring, least privilege, and configuration control, which is closer to what plugin risk demands. NHIMG research on the JetBrains Marketplace AI Plugin Campaign shows why directory presence alone is not a reliable trust signal. In practice, many security teams encounter plugin abuse only after secrets have already been accessed or workflows have already been altered, rather than through intentional pre-install review.

How It Works in Practice

Effective control starts by separating provenance from privilege. A marketplace listing may confirm basic publisher identity or submission checks, but it does not answer what the plugin can read, where it can transmit data, or whether its behavior can evolve after installation. That means the approval workflow should feed into a broader control stack that includes inventory, code and behavior review, endpoint scope, and runtime telemetry.

For AI plugins, the practical questions are operational rather than reputational: Does the plugin access sensitive files or chat history? Does it connect to external services? Does it run on every endpoint or only approved workstations? Does it store tokens, API keys, or model outputs in a way that expands blast radius? These questions map to the kinds of controls NIST expects in mature environments, and they align with NHIMG guidance in the Ultimate Guide to NHIs – Standards.

• Maintain a live plugin inventory with publisher, version, permissions, and deployment scope.
• Review declared permissions against actual file, network, and identity access before rollout.
• Require short-lived credentials and scoped tokens for plugin actions that touch sensitive systems.
• Monitor post-install behavior for new network destinations, privilege changes, and unexpected data access.
• Remove or quarantine plugins that change purpose, expand endpoints, or request new permissions.

When teams combine marketplace approval with runtime controls, they can detect whether an approved plugin is behaving like a benign productivity tool or like an exfiltration path. The key lesson from the JetBrains GitHub plugin token exposure is that trusted distribution channels still need independent verification. These controls tend to break down in fast-moving developer environments where plugins are installed locally without central telemetry because permission drift and endpoint sprawl are difficult to see in time.

Common Variations and Edge Cases

Tighter plugin control often increases friction for developers, so organisations must balance speed against containment. That tradeoff becomes especially visible when teams allow experimental plugins, internal beta tools, or agentic extensions that legitimately need broad access to repositories, terminals, or production-like data. Current guidance suggests that these cases should be isolated rather than broadly exempted, but there is no universal standard for this yet.

One common edge case is a plugin that behaves safely at install time but becomes risky after updates. Another is a plugin that is benign on one endpoint and dangerous on another because of local credentials, mounted volumes, or connected SaaS accounts. A third is a plugin that never directly steals data but expands the attack surface by reading context that other tools can later abuse. That is why NHIMG’s research on the DeepSeek breach is relevant here: exposed data and trust assumptions often matter more than the installation channel itself.

Where organisations go wrong is assuming a directory badge replaces governance. It does not. The more sensitive the environment, the more approval must be paired with ongoing review, strict scoping, and removal authority when behaviour changes. If a plugin can touch secrets, code, or user content, marketplace approval is only the starting point, not the control.

Related resources from NHI Mgmt Group

• What do organisations get wrong when they treat access requests as a one-time approval instead of an ongoing control?
• What do organisations get wrong when they secure AI only at the model layer?
• What do organisations get wrong when they let AI assistants handle privacy lookups?
• What do teams get wrong when they rely on human-in-the-loop controls for AI?