How should security teams govern agent plugins across different MCP clients?

Treat each client as the real policy boundary and review plugin access per runtime, not just per package. A plugin that is safe in one client can be over-permissive in another if sandboxing, tool scope, or secret handling differs. Governance should follow the loader, the session, and the entitled tools, not the install artifact alone.

Why This Matters for Security Teams

Agent plugins are not governed safely by package review alone. In MCP environments, the meaningful control point is the client runtime that loads the plugin, mediates tool calls, and handles secrets. The same plugin can behave very differently across clients if one client exposes broader tool scopes, weaker sandboxing, or more permissive credential handling. That makes runtime context the real security boundary, not the artifact in the registry.

This matters because autonomous and semi-autonomous workflows can chain tools faster than reviewers can inspect them. A plugin that only needs read access in one client can become a write-capable path in another, especially when the client injects session tokens or inherits ambient permissions. NHI governance teams should map plugin trust to the loader, session, and entitled tools, then verify that the client enforces those limits consistently. Current guidance suggests treating MCP clients as distinct enforcement domains, not interchangeable consumers. The AI Agents: The New Attack Surface report found that 80% of organisations said their AI agents had already acted beyond intended scope, which is exactly the failure mode that appears when access is assumed to follow the package instead of the runtime. In practice, many security teams discover over-permissioned plugins only after a client-specific session has already widened the blast radius.

For the broader agentic risk model, OWASP Agentic AI Top 10 and NIST AI Risk Management Framework both reinforce runtime governance, traceability, and context-aware controls.

How It Works in Practice

Effective plugin governance starts with an inventory that ties each plugin to the specific MCP client builds, environments, and identity boundaries where it is allowed to run. That inventory should include the tools a plugin can call, the data it can touch, the secrets it can read, and whether the client can enforce per-session or per-task restrictions. Security teams should review the client policy layer first, then validate the plugin against it, rather than assuming a single approval covers every deployment.

A practical control stack usually includes:

• Per-client allowlists for approved plugins and exact versions.
• Runtime tool scoping so the client only exposes the minimum MCP methods required.
• Ephemeral credentials or token exchange tied to the session, not long-lived shared secrets.
• Policy-as-code checks at load time and at request time for sensitive tool use.
• Logging of tool invocation, identity context, and secret access for each client instance.

That model aligns well with workload identity principles in agentic environments. Instead of trusting a plugin because it was signed or published, teams should verify what the client proves about the workload, the session, and the tool entitlement at the moment of use. CSA MAESTRO agentic AI threat modeling framework and MITRE ATLAS adversarial AI threat matrix both support threat modeling around chaining, escalation, and runtime misuse. NHIMG’s CoPhish OAuth Token Theft via Copilot Studio research is a useful reminder that plugin-like integrations often fail through token handling and delegated trust, not just code defects. These controls tend to break down when the MCP client can inherit broad enterprise identity, because the plugin then gains more authority than the security review ever intended.

Common Variations and Edge Cases

Tighter plugin governance often increases operational overhead, requiring organisations to balance deployment speed against runtime isolation and approval churn. That tradeoff becomes sharper when different MCP clients expose different sandbox models or secret stores, because a single plugin may need separate risk decisions for each client rather than one global approval.

Best practice is evolving, but current guidance suggests three common exceptions. First, development clients used by engineers may need broader tool access than production clients, yet that exception should be explicit and time-bound. Second, plugins that only read public data still require review if the client can silently expand their reach through inherited credentials. Third, some clients do not support strong per-plugin isolation, so governance must shift to compensating controls such as network egress restriction, dedicated service accounts, and session-level approval gates.

This is also where static policy breaks down. A plugin can be safe in a tightly sandboxed desktop client and unsafe in a server-side orchestrator that fans out tool calls across multiple agents. Security teams should document which client behaviors are trusted by design and which are merely tolerated because there is no universal standard for this yet. NHIMG’s The State of Non-Human Identity Security report highlights how visibility and over-privilege remain persistent weaknesses, and those weaknesses become more acute when the same plugin is reused across heterogeneous MCP runtimes.

Related resources from NHI Mgmt Group

• How should security teams govern AI agent actions across MCP, CLIs, Skills, and generated code?
• How should security teams govern machine identity credentials in agentic AI environments?
• How should teams govern AI agents that use MCP?
• How should security teams govern AI agents that use OAuth access?