Notifications
Clear all
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.
NHIMG editorial — based on content published by Cakewalk: Agent Plugins 1.0 Standardizes the Package and Leaves Policy to Each Client
By the numbers:
- Only 18% of MCP server deployments implement any form of access scoping for tool permissions.
- 53% of MCP servers expose credentials through hard-coded values in configuration files.
Questions worth separating out
Q: How should security teams govern agent plugins across different MCP clients?
A: Treat each client as the real policy boundary and review plugin access per runtime, not just per package.
Q: Why do agent plugin standards still leave NHI risk unresolved?
A: Because packaging standardisation does not define who authorises tool use or how secrets are scoped at runtime.
Q: What breaks when plugin permissions are handled by each client separately?
A: Access reviews lose consistency, revocation becomes slower, and the same plugin can behave differently in each environment.
Practitioner guidance
- Centralise plugin approval at the client layer Require every approved plugin to be mapped to a named client policy, with explicit review for tool access, sandboxing, and secret retrieval paths.
- Separate secrets from plugin packages Deliver credentials through a governed runtime secret path rather than package metadata, environment fields, or bundled configuration files.
- Bind tool calls to authorization events Preserve the approval event, actor identity, and session context for every MCP tool invocation so audit and revocation can follow the decision path.
What's in the full article
Cakewalk's full analysis covers the operational detail this post intentionally leaves for the source:
- The specification clauses that govern package structure, command tokens, and extension handling.
- The client-side enforcement decisions that determine which tools, secrets, and paths a plugin can reach.
- The interoperability trade-offs between standardised packaging and local policy control.
- The implementation implications for teams running multiple MCP clients with different permission models.
👉 Read Cakewalk's analysis of Agent Plugins 1.0 and MCP policy gaps →
Agent Plugins 1.0 and MCP policy gaps: are your clients ready?
Explore further
26/08/2026 11:51 am
Policy left to each client creates identity fragmentation, not portability. Agent Plugins 1.0 solves packaging consistency, but it does not solve authority consistency. If installation policy, sandboxing, and tool scoping differ by client, then the same plugin has different identity meaning in different runtimes. Practitioners should read this as a governance split between what is distributed and what is actually authorised.
A few things that frame the scale:
- 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, according to The State of MCP Server Security 2025.
- 53% of MCP servers expose credentials through hard-coded values in configuration files, according to the same research.
A question worth separating out:
Q: How can teams reduce secret exposure in agent workflows?
A: Use a vault for third-party OAuth tokens and static API keys, then retrieve credentials only when a tool call needs them. That keeps raw secrets out of the model context and out of application code. The goal is not just storage, but controlled retrieval with narrow scope and short lifetime.
👉 Read our full editorial: Agent Plugins 1.0 leaves policy gaps that clients must now govern
