Topic starter
25/10/2026 11:07 am
TL;DR: MCP skills, servers and plugins can change after review, with Manifold Security arguing that one-time approval only covers admission, not later behavior. Runtime policy has to govern each action, because a static yes or no cannot limit what a live asset does after install.
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: 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.
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.
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.
Glossary terms: Runtime Authorisation, Prompt Fetching, Admission Controller, Per-Action Policy
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 7 days ago by NHI Mgmt Group
27/10/2026 7:16 pm
One-time approval is the wrong control plane for MCP assets: A review answers a provisioning question, not an execution question. Once a skill, server, or plugin can change behavior after install, the reviewed object is no longer the governed object. The implication is that identity governance has to move from asset admission to action-time policy.
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.
A question worth separating out:
Q: What is the difference between asset approval and per-action policy in MCP governance?
A: Asset approval decides whether something may enter the environment. Per-action policy decides whether each individual action may execute once the asset is running. In dynamic MCP environments, the second control matters more because behavior can change after install, which means the original approval no longer guarantees safe execution.
👉 Read our full editorial: One-time approval fails for MCP skills, servers and plugins
This post was modified 7 days ago by NHI Mgmt Group