They often treat plugins as optional productivity add-ons rather than durable access paths. In reality, a plugin can persist across sessions, influence future actions, and act like standing privilege. That means plugin lifecycle, review, and revocation need the same discipline as other non-human identities.
Why This Matters for Security Teams
Marketplace plugins for AI tools are often approved as convenience features, but they can become durable access paths into models, data, and downstream systems. The mistake is assuming a plugin is a one-time install rather than an identity-bearing integration with ongoing reach. That matters because plugin permissions often outlive the original user session, and in some cases they can influence future prompts, retrieve sensitive context, or trigger actions long after deployment.
Security teams should treat plugins as part of the NHI surface, not as a harmless extension layer. The risk is visible in incidents such as the JetBrains Marketplace AI Plugin Campaign, where malicious plugins were used to steal AI API keys, and the JetBrains GitHub plugin token exposure, which showed how plugin trust can turn into credential exposure. NIST guidance on access enforcement and least privilege, including NIST SP 800-53 Rev 5 Security and Privacy Controls, reinforces that access must be governed, monitored, and revoked when no longer needed.
In practice, many security teams encounter plugin abuse only after tokens, context, or downstream access have already been used, rather than through intentional plugin review.
How It Works in Practice
Marketplace plugins are best understood as software-defined trust brokers. Once installed, they may receive scoped tokens, access model context, call external APIs, or act on behalf of a user or agent. That makes plugin lifecycle management critical: approval, scope review, continuous monitoring, and rapid revocation all need to be explicit. Current guidance suggests treating each plugin like a distinct NHI with its own identity, permissions, and audit trail.
The operational model should be simple and strict:
- Assign a unique identity to each plugin instance or integration.
- Use least privilege and narrow scopes for every API or model action.
- Issue just-in-time access where possible, rather than long-lived credentials.
- Log installation, prompt access, outbound calls, and privilege changes.
- Revalidate plugins after every version change, marketplace update, or ownership shift.
This is where NHI governance and agentic controls intersect. The Ultimate Guide to NHIs — The NHI Market is useful for framing why software identities need the same lifecycle controls as human accounts, while the DeepSeek breach illustrates how exposed secrets and broad trust boundaries can compound quickly. The underlying principle is reinforced by NIST SP 800-53 Rev 5 Security and Privacy Controls, especially where access review and revocation are concerned. These controls tend to break down when a plugin can inherit broad workspace privileges and silently reuse stored tokens across sessions because revocation does not always invalidate every downstream session or cached credential.
Common Variations and Edge Cases
Tighter plugin control often increases operational overhead, requiring organisations to balance developer convenience against blast-radius reduction. That tradeoff becomes sharper in environments where plugins are embedded in productivity workflows, shared across teams, or approved through a marketplace with limited supply-chain visibility.
There is no universal standard for plugin governance yet, but current best practice is evolving toward continuous trust assessment. A plugin that only reads public documents is not equivalent to one that can send messages, create tickets, or access code repositories. The difference is not cosmetic; it determines whether the plugin is merely informative or functionally privileged. If a plugin can influence future model behavior, it should be reviewed like an always-on integration, not a temporary add-on.
This is especially important when plugins are bundled with agentic features or chained into multi-step workflows. In those cases, an apparently low-risk extension can become a control point for lateral movement, data exfiltration, or unauthorized actions. Teams should also watch for marketplace updates that change permissions without a fresh review, since trust can drift over time. The practical lesson is that plugin approval is not the end of governance. It is the start of ongoing identity and access management for a non-human actor.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10, OWASP Agentic AI Top 10 and CSA MAESTRO address the attack and risk surface, while NIST AI RMF and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Plugins behave like durable non-human identities with persistent access paths. |
| OWASP Agentic AI Top 10 | A1 | Plugins can alter agent behavior and extend tool access across sessions. |
| CSA MAESTRO | TRUST-03 | Plugin trust must be continuously evaluated as part of agentic supply-chain risk. |
| NIST AI RMF | AI RMF governance covers ongoing oversight of autonomous integrations and impacts. | |
| NIST CSF 2.0 | PR.AC-4 | Least privilege and access review are central to plugin governance. |
Apply least privilege to every plugin and revoke access immediately when scope changes.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 28, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
