Access reviews lose consistency, revocation becomes slower, and the same plugin can behave differently in each environment. Teams may approve a package once and assume the decision holds everywhere, but client-specific policy changes alter real privilege. That creates governance drift across the agent and MCP estate.
Why This Matters for Security Teams
When plugin permissions are split across each client, the problem is not just duplication. It is control loss. Security teams no longer have a single policy decision point, so package approval, scope limits, and revocation timing can diverge by environment. That makes the same MCP tool or plugin effectively different identities depending on where it runs, which undermines consistent governance and auditability. The OWASP Non-Human Identity Top 10 calls out the risk of weak lifecycle control for machine identities, and NHI Mgmt Group’s Ultimate Guide to NHIs — Key Challenges and Risks shows why fragmented oversight creates exposure across the estate. In practice, teams often discover the drift only after an incident review shows one client still trusted a plugin that another client had already blocked.
Client-specific permission handling also creates false confidence. A plugin can appear vetted because one workstation, tenant, or agent runtime accepted it, while another silently grants broader tool access or inherits stale exceptions. That is especially dangerous for agentic systems because plugins often mediate secrets, API calls, and lateral tool chaining. Guidance from OWASP Non-Human Identity Top 10 and NIST’s NIST SP 800-53 Rev 5 Security and Privacy Controls both support centralized, auditable control ownership rather than distributed trust decisions. NHI Mgmt Group’s research also notes that only 5.7% of organisations have full visibility into their service accounts, which helps explain why fragmented plugin governance is so easy to miss. In practice, many security teams encounter permission drift only after a blocked plugin is still operational somewhere else.
How It Works in Practice
The safer pattern is to treat plugin access as a governed entitlement, not a local client preference. Security teams should define one approval record, one scope model, and one revocation path for the plugin’s workload identity, then propagate that decision to every client that can invoke it. Where current guidance suggests runtime context matters, the policy engine should evaluate who is calling, what action is requested, and whether the agent context justifies the access, rather than relying on a one-time install approval. That aligns with how agent and MCP estates actually operate: permissions are not static, and the same plugin may be invoked by different agents with different trust levels.
Practical controls include:
- Centralise plugin inventory so every client reports the same package, version, and scope state.
- Bind plugin permissions to workload identity and runtime policy, not to a local allowlist alone.
- Use short-lived tokens or JIT grants for sensitive actions, then revoke on task completion.
- Synchronise revocation so a deny decision reaches every client before the next invocation window.
- Log approvals, scope changes, and execution events to a single audit trail for review.
That operational model is consistent with the NHI lifecycle guidance in Ultimate Guide to NHIs and with threat scenarios documented in JetBrains GitHub plugin token exposure, where tool trust and token handling became the control boundary. These controls tend to break down when clients are offline, because revocation and policy synchronisation cannot reach every local cache at the same time.
Common Variations and Edge Cases
Tighter plugin governance often increases operational overhead, requiring organisations to balance consistency against rollout speed. Some teams allow local exceptions for testing, embedded development, or isolated tenant pilots, but current guidance suggests those exceptions need explicit expiry and central review. Otherwise, temporary client-level permissions become permanent shadow policy. A separate edge case appears when a plugin is shipped inside a vendor-managed client: local administrators may believe they are only approving software, while the embedded plugin is actually capable of tool execution and secret access. That distinction matters because the effective privilege is defined by runtime behaviour, not the install screen.
Another common mismatch is cross-environment parity. A plugin approved in one agent runtime may be denied in another because the latter uses stricter scopes or different identity bindings. That is not a bug if it is intentional, but it becomes governance drift if the difference is undocumented. The JetBrains Marketplace AI Plugin Campaign is a useful reminder that plugin trust must include supply chain review, not just permission review. In short, distributed approval models can work only when policy, identity, and revocation are still centrally governed; otherwise the estate fragments into inconsistent trust zones.
Related resources from NHI Mgmt Group
- What breaks when vendor or device access is handled separately from workforce IAM?
- What breaks when de-provisioning is handled separately in each cloud?
- What breaks when certificate prerequisites are handled separately from brand governance?
- What breaks when API permissions are managed separately for every service?
