An agent plugin is a packaged bundle of skills, tools, and MCP server configuration that can be installed into a client. In identity terms, it is not just software distribution, but a runtime access object whose risk depends on the client’s policy, secret handling, and tool-scoping decisions.
Expanded Definition
An agent plugin is more than a convenience layer for extending an AI agent. In NHI security terms, it is a packaged execution surface that can introduce new tools, permissions, secrets, and MCP server configuration into a client runtime. That makes the plugin an identity-bearing object, because its security posture depends on how the client authenticates, authorises, and scopes the plugin’s access.
Definitions vary across vendors, but the core distinction is consistent: a plugin is not simply code to be loaded, it is a delegated capability boundary. Good practice aligns with the principles in the NIST AI Risk Management Framework and with the agentic security concerns catalogued in OWASP Agentic AI Top 10. The practical question is not whether the plugin is useful, but whether it can be installed, updated, revoked, and monitored without creating standing access that exceeds the agent’s intended mission.
The most common misapplication is treating an agent plugin like a normal app extension, which occurs when teams ignore secret propagation, tool scope, and client-side policy enforcement.
Examples and Use Cases
Implementing agent plugins rigorously often introduces governance overhead, requiring organisations to weigh developer speed against tighter approval, logging, and revocation controls.
- A customer-support agent installs a ticketing plugin that can read case metadata and write responses, but the client restricts it to specific queues and time-bound access.
- An engineering agent uses a deployment plugin connected through MCP to open pull requests, while the platform blocks destructive commands and isolates production credentials.
- A finance workflow plugin retrieves invoice data from a third-party system, but the organisation requires explicit tool-scoping and reviewable consent before any export action.
- A security team tests a plugin from a vendor update feed and validates whether it requests secrets at install time or only at runtime, then compares the behaviour to guidance in the OWASP NHI Top 10.
- A cloud operator deploys an internal plugin for incident triage and pairs it with MITRE ATLAS adversarial AI threat matrix techniques to test whether prompt injection can redirect tool calls.
Research into agent misuse has shown that weak tool boundaries can turn an otherwise useful plugin into an attack path, as seen in cases discussed in CoPhish OAuth Token Theft via Copilot Studio.
Why It Matters in NHI Security
Agent plugins matter because they often concentrate the exact failures that create NHI incidents: overbroad permissions, long-lived secrets, and unclear ownership of runtime access. NHIMG reports that 97% of NHIs carry excessive privileges, which is a warning signal for plugin ecosystems where installation convenience can outrun governance. If a plugin can inherit credentials or request broad tool access, then compromise of the plugin becomes compromise of the identity plane behind it.
This is why plugin governance must be tied to least privilege, secret isolation, and revocation discipline rather than only to software supply chain checks. A plugin that is safe in one client may be unsafe in another if the client allows persistent tokens, unconstrained MCP connectivity, or unreviewed third-party updates. That risk profile is also reflected in the security concerns described in Ultimate Guide to NHIs — 2025 Outlook and Predictions and the control logic in the NIST AI Risk Management Framework.
Organisations typically encounter the real impact only after a plugin leaks a token, oversteps its scope, or executes an unintended tool action, at which point the plugin becomes operationally unavoidable to address.
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 Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Plugins often concentrate secret handling and scope issues covered by NHI controls. |
| OWASP Agentic AI Top 10 | A2 | Agent plugins are a primary tool-extension risk surface in agentic applications. |
| NIST AI RMF | GOVERN | AI RMF addresses governance of AI system capabilities and associated risks. |
| NIST Zero Trust (SP 800-207) | SC.L2-3 | Zero trust requires per-request authorization for exposed plugin capabilities. |
| CSA MAESTRO | MAESTRO models agentic toolchains as composable security zones needing control. |
Enforce least-privilege, continuous verification, and explicit trust boundaries for plugins.
