As an access control problem first. Packaging matters for interoperability, but the real risk sits in the runtime enforcement layer where plugin actions, MCP tool calls, and secret access are authorised. If you only govern the folder format, you miss the point at which identity and privilege are actually exercised.
Why the Question Is Really About Runtime Authority
Agent plugins are not just installable add-ons, they are execution paths that can read context, call tools, and trigger side effects. That means the security boundary is not the package folder or marketplace listing alone, but the point where a plugin is allowed to act, what it can reach, and under which principal it operates. The right question is which identity and privilege decisions happen at runtime.
Packaging still matters because it affects distribution, provenance, and interoperability. But packaging is a precondition, not the control plane. If an organisation only checks file structure or signed delivery and ignores delegated access, token scope, and tool authorization, it is protecting the wrapper while leaving the action layer open.
That distinction becomes sharper when plugins sit beside MCP servers, agent tools, or chained integrations. The same plugin can be benign in one deployment and high risk in another if it is granted broad access to secrets, APIs, or internal systems. The security outcome depends less on how the plugin is shipped and more on how its runtime permissions are constrained and reviewed.
Where Packaging Ends and Access Control Begins
Packaging is about whether the plugin can be trusted as a distributable artifact: can it be installed, updated, inspected, and versioned safely? Access control is about whether the plugin can be trusted to do anything meaningful after installation. In practice, the second problem is the one that decides blast radius, because plugin code often operates through authenticated sessions, delegated tokens, or service credentials already present in the environment.
A useful rule is to treat packaging controls as supply-chain hygiene and access controls as operational safety. The first reduces the chance that a bad plugin arrives. The second limits the damage when a plugin is present, compromised, overextended, or simply misused. Both matter, but they answer different questions, and confusing them leads to false confidence.
This is especially important for agentic or workflow-driven environments where plugin actions are not just UI behavior. A plugin may invoke tools, fetch data, write records, or launch follow-on requests. Those are authorization events, not packaging events, and they should be governed with the same seriousness as any other privileged action path.
How to Judge the Boundary in Practice
Ask whether the control you are considering would still stop harm after the plugin has been installed. If the answer is no, it is probably a packaging control, not the primary control for the real risk. If the control limits what the plugin can read, call, delegate, or persist at runtime, then you are in access-control territory.
For teams designing policy, the cleanest division is to separate artifact trust from action trust. Artifact trust covers source, signing, review, update handling, and reproducibility. Action trust covers least privilege, per-action authorization, scoped tokens, approval gates, and revocation. A mature program needs both, but it should never confuse one for the other.
That is why plugin governance should be tied to the environment that executes the plugin, not only the repository that distributes it. The same packaging format can support both low-risk and high-risk use cases. Runtime policy is what distinguishes them, which is why access decisions must be explicit, testable, and revocable.
Risk and Threat Considerations
When organisations treat agent plugins as a packaging problem, they tend to under-control the runtime permissions that matter most. The result is overbroad tool access, unnecessary token exposure, and a larger blast radius if the plugin is malicious, compromised, or simply misconfigured.
Failure mechanism: A plugin is installed from a seemingly acceptable package, then uses the trust already granted to the host, agent, or user session to call tools, access secrets, or trigger downstream actions beyond its intended scope.
Impact: Attackers or faulty plugins can pivot from a distribution issue into an authorization failure, leading to data exposure, credential abuse, unauthorized transactions, or wider agent compromise.
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 and OWASP Agentic AI Top 10 address the attack surface, NIST SP 800-53 Rev 5 sets the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | Agent plugins can overreach at runtime through scoped identities and tokens. |
| Recommendation — Apply least privilege to plugin credentials and remove excess action rights. | ||
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | The question centers on plugin authority, delegated action, and runtime privilege. |
| Recommendation — Enforce per-action authorization and bounded delegation for plugin tool use. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Plugin risk is primarily about limiting what installed code can do. |
| IA-5 — Authenticator Management | Plugins often depend on tokens or secrets whose lifecycle must be controlled. | |
| IA-9 — Service Identification and Authentication | Plugin and MCP tool calls often rely on non-human runtime authentication. | |
| Recommendation — Restrict plugin permissions to the minimum required capabilities. Manage plugin secrets and tokens with strict issuance, rotation, and revocation. Authenticate plugin-to-tool interactions before allowing sensitive actions. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Access decisions, not packaging alone, determine plugin risk at execution time. |
| A.8.5 — Secure authentication | Plugins commonly depend on authenticated API or token-based runtime access. | |
| A.8.2 — Privileged access rights | Plugins with elevated rights need explicit control over their privilege scope. | |
| Recommendation — Define and enforce access rules for plugin execution and tool invocation. Use strong authentication for plugin and tool access paths. Limit and review privileged rights granted to plugins and agents. | ||
Practitioner Guidance
What to prioritise: Put runtime authorization in front of packaging checks when the plugin can touch secrets, internal APIs, or write-capable tools. Packaging review is still useful, but it should not be the control that decides who can do what.
What to verify: Confirm that plugin actions are scoped to the minimum set of tools and credentials required, and that revocation works without redeploying the entire platform. If a plugin cannot be cleanly bounded or removed, the governance model is too weak.
Common mistake: Treating a signed or approved package as proof that the plugin is safe to execute broadly. Trust in delivery does not equal trust in authority.
Practitioner takeaway: Judge agent plugins by the authority they exercise at runtime, not by the format they arrive in, because that is where privilege, secrets, and real-world impact are actually controlled.
Related resources from NHI Mgmt Group
- When should organisations treat agent access as a privileged access problem?
- Should organisations treat AI agent access and employee onboarding as one governance problem?
- Should organisations treat agent actions like API traffic or like a new control problem?
- When should organisations treat agent output integrations as part of access governance?