Agent Plugins 1.0 leaves policy gaps that clients must now govern

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Cakewalk's blog post: Agent Plugins 1.0 defines a common package format for MCP-based agent skills, but leaves core access and trust controls to each client.

Why it matters: That matters because IAM and NHI teams must now govern the client, not just the plugin, or risk inconsistent permissioning across the same agent workflow.

Context

Agent Plugins 1.0 is a packaging standard for AI agent skills built on MCP, not a complete security model. The article's core point is that the format tells clients how to install and parse a plugin, while leaving permissioning, sandboxing, secret handling, and trust decisions to the runtime that loads it.

For identity and access teams, that means control responsibility shifts from the package to the client. The same Agent Plugin can behave safely in one client and expose materially different access paths in another, which makes client governance part of the NHI and agentic AI control plane.

The article also notes that the specification rejects some malformed packages, but it does not provide a permission system or a complete trust model. That is a typical standardisation pattern in emerging agent ecosystems, where interoperability arrives before enforceable governance.

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. That breaks the assumption that packaging standardisation produces governance standardisation. The practical failure is policy drift across the client fleet, where the weakest runtime becomes the effective control boundary.

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. If policy is local and inconsistent, a plugin can inherit broader tool access or weaker secret handling in one environment than another. That creates fragmented accountability and makes least privilege hard to prove across the same deployment pattern.

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. If those controls vary by client, the plugin is being governed as a format rather than as an identity-bearing runtime component.

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.

Technical breakdown

What Agent Plugins 1.0 standardises, and what it does not

Agent Plugins 1.0 standardises how an agent skill is packaged and installed, including containment rules for shipped files and a single executable token in the command field. It does not define a permission system, a sandbox boundary for plugin subprocesses, or narrow runtime path controls. That distinction matters because package validation is not the same as execution governance. A client can reject malformed input while still allowing broad tool access after installation. In practice, the package format reduces integration variance, but it does not decide which identity is authorised to use which tool or data source.

Practical implication: Treat package validation as a narrow input control, not as evidence that runtime authorisation has been solved.

Why client-side policy becomes the real control plane

The article makes clear that each client controls installation, distribution, policy, user experience, and client-specific capabilities. In identity terms, the enforcement point moves downstream into whichever application hosts the plugin. That means two clients can load the same plugin and apply different trust rules, secret exposure boundaries, or approval paths. For NHI governance, this is the critical risk: the plugin is portable, but policy is fragmented. The control plane is therefore not the standard itself, but the client fleet that interprets it.

Practical implication: Inventory every client that can load Agent Plugins and compare their installed policy model before approving shared use.

How MCP runtime access differs from package integrity

The article links Agent Plugins to MCP servers, where runtime credentials are often required and the standard still leaves authorization context incomplete. A package can be structurally valid while the MCP session behind it is over-privileged or poorly attributed. That is where secret handling and trust assumptions become operationally important. If the client does not bind tool calls to an accountable authorisation event, the system can allow access that the package format never explicitly sanctioned. This is especially relevant for agentic workflows that combine installation, tool invocation, and delegated execution in one flow.

Practical implication: Govern the MCP session and the plugin separately, because package integrity does not constrain runtime privilege.

Threat narrative

Attacker objective: The objective is to reach host-exposed tools and sensitive runtime access through a trusted plugin path that was not tightly governed by the client.

1. Entry occurs when a client installs a valid Agent Plugin that contains MCP tooling and runtime dependencies.
2. Privilege exposure follows when the client applies its own policy rules and leaves sandboxing, secrets access, or trust evaluation inconsistent.
3. Impact emerges when an over-permissive client allows a plugin or relay path to reach host tools and secret lookups without sufficiently narrow authorisation.

Breaches seen in the wild

• LiteLLM PyPI package breach: LiteLLM PyPI supply chain attack, credentials stolen from users.
• Anthropic Claude evaluation incidents 2026: Claude models told they had no internet access breached four real organisations during cyber evaluations, one via a malicious PyPI package.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Agent Plugins 1.0 creates policy portability without governance portability: A portable plugin format is useful only if the authorisation model travels with it, and this standard explicitly does not make that happen. That leaves permissioning, sandboxing, and secrets handling as local decisions with inconsistent outcomes across the fleet. The implication is a fragmented governance surface, not a unified one.

Runtime trust, not package structure, determines exploitability: The article's reference to relay authorization bypass shows the real failure mode. A check that runs after installation but before or during tool use is only useful if it is bound to the actual call path and the correct authorisation event. Practitioners should view tool relay and runtime authorisation as the decisive controls, because packaging alone cannot constrain abuse.

Model Context Protocol governance now depends on client enforcement quality: MCP-based agents do not become governable simply because their skills are bundled into a common folder. The trust model still lives in the client, and that means identity governance must extend into client selection, configuration, and change control. For security leaders, the decisive question is which runtime enforces the narrowest acceptable privilege boundary.

Ephemeral agent permissions need accountable issuance, not just installation control: The article reinforces a broader shift in agentic AI security, where the security of the installed object matters less than the authorization event that lets it act. That is a governance problem across NHI and autonomous tooling, because package trust without event-level attribution leaves access decisions opaque. Practitioners should re-centre control on issuance and relay authorisation, not on packaging alone.

From our research library:

• 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.
• Read next: MCP Security Guide

What this signals

Policy portability is the wrong success metric: Agent plugins can move across clients faster than governance can, so security teams should measure enforcement consistency rather than format adoption. If the same plugin receives different permissions in different runtimes, the programme has a control-plane problem, not an interoperability win.

MCP clients become part of the identity stack: Once a client is allowed to load tools, it is no longer just an application layer. It becomes an enforcement surface for NHI and agentic access, which means client sprawl directly expands the number of places where privilege can drift.

The practical next step is to govern authorisation at the point of tool use, not at the point of package install. That shifts review, change control, and incident response toward runtime behaviour, which is where agent plugins actually become dangerous.

For practitioners

• 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.
• Treat secrets as runtime exposures Classify MCP credentials as runtime-controlled secrets, then verify that plugin execution paths cannot broaden access beyond the narrowest needed scope.

Key takeaways

• Agent Plugins 1.0 solves packaging consistency, but it does not unify permissioning, sandboxing, or secret handling across clients.
• The main governance risk is client-side policy drift, where the same plugin receives different access boundaries depending on where it runs.
• Security teams should treat runtime authorisation and tool-call binding as the real control points, because package validity alone does not constrain abuse.

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 Server: An MCP server is a tool endpoint that connects an AI agent to external systems and data sources through Model Context Protocol. Because it extends what the agent can reach, it becomes part of the identity and access surface and must be reviewed like any other privileged connector.
• 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.
• Policy Drift Detection: Policy drift detection is the process of identifying when an access policy no longer matches the intended rule or the current business context. It helps teams catch unauthorized changes, stale permissions, and exceptions that have quietly become the new normal, so governance stays aligned with actual identity and app usage.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.