Topic starter
26/08/2026 11:50 am
TL;DR: Agent Plugins 1.0 standardizes packaging for MCP-based agent skills but leaves permissioning, sandboxing, secrets handling, and trust policy to each client, according to Cakewalk. That pushes identity and access decisions back into fragmented runtime controls, where NHI and agent governance remain inconsistent.
Editorial analysis by NHI Mgmt Group, based on content published by Cakewalk: “Agent Plugins 1.0 Standardizes the Package and Leaves Policy to Each Client”.
Key questions
Q: What breaks when Agent Plugins rely on client-specific policy decisions?
A: The same plugin can behave differently across clients, so installation no longer guarantees consistent permissioning, sandboxing, or secret handling.
Q: Why do MCP-based plugins increase governance risk when trust is left to each client?
A: Because the runtime client, not the package, decides how access is enforced.
Q: How can security teams tell whether an Agent Plugin is being governed safely?
A: Look for evidence that the client binds each tool call to an explicit authorisation event, applies sandboxing consistently, and limits secrets exposure to the minimum runtime scope.
Practitioner guidance
- Map client policy variance Create an inventory of every client that can load Agent Plugins and compare how each handles installation, policy enforcement, sandboxing, and secret access.
- Separate package trust from runtime trust Review where your current approvals assume that a valid plugin package also implies safe tool use, then split that assumption into package validation and runtime authorisation.
- Bind tool calls to accountable events Require the client to tie each host tool invocation to a specific authorisation event and reject relay paths that cannot prove that binding.
Bottom line: Agent Plugins 1.0 solves packaging consistency, but it does not unify permissioning, sandboxing, or secret handling across clients.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
26/08/2026 11:51 am
Client-specific policy is now the governing layer for agent plugins: Standardised packaging does not solve identity risk when each client defines its own installation, distribution, and trust rules. The same plugin can therefore inherit different access boundaries depending on where it runs. For practitioners, the meaningful control question is no longer whether the package is valid, but which client is allowed to interpret it.
A few things that frame the scale:
- 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
- AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers, according to the State of Secrets Sprawl 2026.
A question worth separating out:
Q: Should organisations treat Agent Plugins as a packaging problem or an access control problem?
A: 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.
👉 Read our full editorial: Agent Plugins 1.0 leaves policy gaps that clients must now govern