MCP skills and plugins: what breaks when approval is one-time?

TL;DR: One-time review of MCP skills, servers and plugins only answers whether an asset was allowed in, not what it does after install, especially when behavior can change through runtime instruction fetching or unreviewed updates, according to Manifold Security. That assumption collapses once access and execution are separated, so governance has to move to per-action policy enforcement.

Editorial analysis by NHI Mgmt Group, based on content published by Manifold Security: “Your Review Approved Version 1.0. Your Agents May Be Running Whatever Shipped This Morning.”.

Key questions

Q: What breaks when MCP approval is only done once at install time?

A: One-time approval breaks because it only validates the package or skill that was reviewed, not the behavior that runs later.

Q: Why does runtime instruction fetching create governance risk for MCP assets?

A: Runtime instruction fetching changes the governing object after review.

Q: How should teams handle MCP plugins that can use credentials after installation?

A: Teams should treat credential use as a runtime authorization problem, not a packaging problem.

Practitioner guidance

• Implement standing policy checks for every agent action Move the decision out of a ticket queue and into the execution path so unapproved behavior is blocked or alerted before it completes.
• Treat remote instruction sources as part of the trust boundary Inventory every skill or plugin that can fetch instructions, rules, or code after install and require explicit approval for those sources.
• Separate admission approval from runtime authorization Keep a narrow allowlist for install-time admission, then enforce per-action authorization on the agent session itself.

Bottom line: One-time approval does not govern MCP behavior after install, which is why runtime enforcement matters more than a static yes or no.

Explore further

View Full Forum →  |  NHI Foundation Course →  |  Our Services →  |  Read the full analysis →