Agent Plugins 1.0 leaves policy gaps that clients must now govern

At a glance

What this is: Agent Plugins 1.0 defines a portable packaging standard for agent skills and MCP servers, but leaves authorization and sandbox policy to each client.

Why it matters: IAM and NHI teams need to treat client-side policy as the control plane for agent plugins, or they will inherit inconsistent access, secrets exposure, and tool-use risk across environments.

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.

👉 Read Cakewalk's analysis of Agent Plugins 1.0 and MCP policy gaps

Context

Agent Plugins 1.0 standardises how AI agent skills and MCP servers are packaged, but it does not define a shared permission model for what an installed plugin may access. That leaves identity governance at the client layer, where policy is often inconsistent across tools and vendors.

For IAM and NHI programmes, this is not a packaging problem alone. It is a governance gap around runtime authorisation, secret handling, and tool-scoped access, especially where the same plugin can behave differently depending on which client loads it.

Key questions

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. 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.

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. That leaves the highest-risk decisions to client implementations, which are rarely uniform. The result is fragmented governance, inconsistent audit evidence, and a larger attack surface for compromised credentials and overbroad tool access.

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. 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.

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.

Technical breakdown

Package standardisation without a permission system

Agent Plugins 1.0 focuses on how a plugin is structured, shipped, and validated, not on a common authorization layer. The specification constrains files in the package, requires a single executable token in command fields, and blocks credentials in visible environment values. But it explicitly leaves sandboxing, trust model decisions, and permission enforcement to the client. That means the same plugin can be technically valid while still being overpowered at runtime if the client grants broad access.

Practical implication: Treat spec compliance as packaging hygiene, not a security decision, and enforce client-side policy for every plugin installation.

Why MCP tool calls still need identity context

MCP tool calls describe what the agent wants to do, but the protocol does not by itself answer who authorised the action or which identity should be accountable. The stateless transport model improves interoperability, yet it also means ordinary tool calls can still arrive without a durable authorization context. In practice, this creates a governance gap between the agent, the host account, and the human operator who may have approved the session. Without that context, privilege scoping becomes a client concern rather than a protocol guarantee.

Practical implication: Bind tool calls to explicit authorization events and preserve decision context at the client boundary.

Secrets handling moves from spec to operational discipline

The specification warns that runtime credentials may be needed, but it does not prescribe how narrowly they should be scoped or who should supply them. That matters because MCP ecosystems already show high secret exposure rates in configuration files and plugin-related assets. When secrets are treated as package data, they become visible to distribution, review, and loading workflows that were never designed as secret stores. The result is an NHI problem, not just a software packaging issue.

Practical implication: Keep credentials out of plugin packages and require separate secret delivery paths with narrow runtime scope.

Threat narrative

Attacker objective: The attacker wants to turn a portable agent plugin into a reusable path to secret access and tool misuse across multiple clients.

1. Entry occurs when a client installs a plugin package that is syntactically valid but operationally over-permissive because policy is deferred to the loader.
2. Escalation occurs when the installed plugin can invoke tools or reach secrets through client-specific allowances that were never centralised across the environment.
3. Impact occurs when the same plugin behaves differently across clients, creating fragmented access control, inconsistent auditability, and a wider blast radius for NHI compromise.

Breaches seen in the wild

• Meta AI Instagram Account Takeover — 20,225 Instagram accounts hijacked via compromised Meta AI support chatbot with overprivileged access.
• Replit AI Tool Database Deletion — Replit vibe coding AI assistant deletes live production database and creates 4,000 fake user records.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Runtime authorisation, not package validity, is the real control boundary. A plugin can pass schema checks and still be dangerous if the client grants broad host access or exposes secrets through runtime paths. That makes client-side policy the decisive control surface for NHI governance, because the package format itself does not define privilege.

Client-specific policy drift: the same plugin can inherit different access decisions depending on which vendor loads it, which means access review must shift from static package approval to runtime entitlement review. That is a governance operating model change, not a minor control tweak.

MCP ecosystems now resemble a shared supply chain with local enforcement, which is the worst of both worlds. Standardisation increases distribution speed, but decentralised policy increases the chance of inconsistent privilege, missed revocation, and invisible secret exposure. The practical conclusion is that teams must govern the loader, not just the plugin.

From our research:

• 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.
• For broader agent governance context, see OWASP Agentic Applications Top 10 for the control patterns behind tool misuse and identity abuse.

What this signals

Client-side policy will become the de facto control plane for MCP ecosystems. Once packaging is standardised, the differentiator is no longer what the plugin contains but what each client allows it to do. Teams that rely on a single approval gate for the package will miss the real variance introduced by runtime policy, especially where multiple clients coexist. For a broader control model, align this with the OWASP Agentic AI Top 10.

Package trust debt: if a plugin can be installed cleanly but still expose tools or secrets differently across clients, the organisation has deferred governance into runtime ambiguity. That is where audit evidence gets weak and revocation gets slow. With 24,008 unique secrets exposed in MCP configuration files in 2025 alone, according to The State of MCP Server Security 2025, the operational risk is already measurable.

Teams should expect agent plugin governance to move closer to workload identity and secrets lifecycle controls than to traditional software distribution checks. The right questions are now about entitlement scope, session context, and client-specific enforcement rather than package provenance alone.

For practitioners

• 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.
• Recertify per client, not per package Treat the same plugin as a different risk object in each client and recertify permissions wherever installation, execution, or tool scope changes.

Key takeaways

• Agent Plugins 1.0 standardises distribution, but it leaves the real security decision at the client layer.
• The exposed-secret problem is already concrete, and fragmented runtime policy makes it worse.
• Identity teams need to govern tool scope, secrets, and audit context where the plugin is loaded, not just where it is built.

Key terms

• Agent Plugin: An agent plugin is a packaged bundle of skills, tools, and MCP server configuration that can be installed into a client. In identity terms, it is not just software distribution, but a runtime access object whose risk depends on the client’s policy, secret handling, and tool-scoping decisions.
• MCP Client Policy: MCP client policy is the set of rules a local client uses to decide what a plugin may do after installation. It governs tool access, sandboxing, and secret retrieval at runtime, which means the client becomes the practical enforcement point when the protocol itself does not define permissions.
• Runtime Authorisation: Runtime authorisation is the practice of deciding access while a task is in progress, rather than only at provisioning time. It matters for NHIs because credentials and entitlements can change risk mid-session, especially when automation or AI agents interact with sensitive systems.
• Client-side Entitlement Drift: Client-side entitlement drift occurs when the same plugin or tool is granted different privileges across different clients or environments. It creates governance inconsistency, weakens recertification, and turns one installed package into multiple access profiles that security teams must manage separately.

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.

👉 Cakewalk's full post covers the specification details, client policy gaps, and operational consequences for agent plugins.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing identity controls across human and non-human estates, it is worth exploring.