How should security teams govern AI plugins installed by employees across approved agent platforms?

Why This Matters for Security Teams

Approved agent platforms create a false sense of safety when employees can add plugins that extend reach into mail, storage, ticketing, and code systems. Those plugins are not cosmetic. They can alter tool invocation, expand data access, and create new exfiltration paths. Current guidance suggests treating plugin governance as software supply chain control, not preference management, because the risk is in what the plugin can do once installed.

That matters even more for AI assistants that act on behalf of users. A plugin may appear low risk in a marketplace, then become high impact once it inherits workspace permissions and can chain actions across systems. The most relevant threat patterns are already visible in cases like OWASP NHI Top 10 and the OWASP Agentic AI Top 10, which both emphasize runtime abuse, excessive tool access, and hidden trust expansion.

In practice, many security teams first discover risky plugins only after they have already been installed widely across business units, rather than through intentional approval and inventory.

How It Works in Practice

Governance should start with visibility. Security teams need to know which plugins are permitted, which are actually installed, which users enabled them, and which platforms expose them to enterprise data. That means discovery across managed endpoints, browser extensions, SaaS app catalogs, and the agent platform itself. A plugin inventory should be tied to identity, device posture, and the specific workspace where it runs.

Provenance review is the next control point. Teams should verify the publisher, permission scope, update history, data handling claims, and whether the plugin routes content to external services. This is especially important because many plugins operate with delegated trust from the human user and can inherit broad access to shared drives, chats, and calendars. The issue is not only installation, but runtime authority. Analysis of Claude Code Security and CoPhish OAuth Token Theft via Copilot Studio both show how trusted AI surfaces become security issues once extension paths are abused.

Practically, security teams should combine:

• approved plugin allowlists by platform and business function
• central review for data access scope and outbound integrations
• endpoint and browser coverage to detect unapproved installations
• periodic reassessment when plugin permissions or vendor terms change
• logging of plugin-triggered actions for investigation and rollback

Where possible, teams should require least privilege at the platform layer so a plugin cannot exceed the minimum scopes needed for its task. Pair that with vendor due diligence on telemetry, retention, and support for rapid revocation. For broader risk framing, the NIST AI Risk Management Framework helps teams connect plugin oversight to governance, map, and manage functions, while Ultimate Guide to NHIs and 2025 Outlook and Predictions is useful for understanding how non-human access expands once a plugin is effectively acting with delegated identity.

These controls tend to break down in federated SaaS environments where employees can install plugins from multiple marketplaces and the security stack cannot reliably observe extension-level behavior.

Common Variations and Edge Cases

Tighter plugin control often increases friction for employees, requiring organisations to balance productivity gains against data exposure and response overhead. That tradeoff is real, especially when approved agent platforms are used by developers, analysts, and support teams who want fast extension access.

There is no universal standard for this yet, but current guidance suggests differentiating between low-risk utility plugins and plugins that can read, write, or transmit enterprise data. A translation plugin is not the same as one that can access inboxes, tickets, CRM records, or source code. Some organisations maintain a curated marketplace, while others allow requests through a security review queue. Both can work if the approval process is tied to actual permissions and usage telemetry.

Edge cases often appear when the plugin is embedded inside the platform rather than installed as a visible extension. That includes model-connected tools, workflow automations, and agent actions that do not look like traditional software installs. Security teams should also watch for shadow approvals, where one department grants a plugin access to a shared workspace and another department inherits that exposure. Research from The State of Secrets in AppSec is a reminder that fragmented control and slow remediation make exposure persist long after the original decision.

For mature programmes, the practical test is simple: if the organisation cannot quickly answer who installed the plugin, what it can access, and how to remove it everywhere, the governance model is still incomplete.

Related resources from NHI Mgmt Group

• How should organisations govern AI-driven physical access workflows across HR, IT, and security teams?
• How should security teams govern API keys used for generative AI access?
• How should security teams govern AI agents that reason across multiple data platforms?
• How should security teams govern AI agent orchestration across multiple systems?