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.
At a glance
What this is: This analysis says one-time approval of MCP skills, servers and plugins does not govern what they do after install, because runtime behavior can change after review.
Why it matters: IAM and NHI teams need to treat admission and action as separate controls, or they will approve assets that later execute outside the reviewed security posture.
Context
MCP governance breaks when teams confuse admission control with runtime control. A one-time review can tell you whether a skill, server, or plugin should be installed, but it does not govern what that component does after installation or what data and credentials it can reach once active.
The problem is especially sharp for MCP because the execution environment can change after approval. Some assets fetch instructions from outside sources after install, which means the reviewed version is not necessarily the version that runs, and the governance model has to account for that drift.
That leaves a gap between policy and behavior that ticket-based approvals rarely close. The right question is not only whether the asset was approved, but whether the platform checks its permissions, source, and runtime actions every time it is used.
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. If the asset can fetch new instructions, update its own logic, or invoke new tools after install, the original decision becomes stale. Governance has to move to runtime policy checks that evaluate each action, not just the initial admission.
Q: Why does runtime instruction fetching create governance risk for MCP assets?
A: Runtime instruction fetching changes the governing object after review. The reviewer approves one artifact, but the live asset can retrieve new instructions or code from elsewhere and act on them without a fresh decision. That breaks the assumption that version control and approval are the same thing, so provenance and execution must be governed separately.
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. If a plugin can access API keys, tokens, or delegated permissions after installation, the important control is whether each action is authorized in context. Static approval is not enough because it cannot limit what the plugin does once the session begins.
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.
Technical breakdown
Why one-time approval misses runtime behavior in MCP
A one-time approval process evaluates an asset snapshot, not a living execution path. In MCP environments, a skill or plugin can be approved in one version and later change behavior through a remote instruction source, an updated package, or a new execution path that was not visible during review. That means the control is validating admission, while the risk appears during runtime. The governance mistake is treating version approval as equivalent to behavior approval. For identity teams, the real control boundary is not the package record but the agent action that happens after the package is loaded. See the AI Agent Authorisation Guide.
Practical implication: Shift governance from asset approval to per-action authorization so the platform evaluates behavior at runtime, not only at install time.
How instruction fetching creates review bypasses
Instruction fetching is a structural bypass because the reviewed artifact can become a loader for new instructions rather than a fixed unit of behavior. If an MCP skill can retrieve instructions from an external server after install, the review cannot prove what it will do tomorrow from the metadata alone. This is not just a patching problem. It is a governance problem where the authoritative behavior source moves outside the reviewed bundle. That makes static approval incomplete, especially when the asset can also request broader credentials or tools once the agent starts executing. See the MCP Security Guide.
Practical implication: Treat any runtime instruction source as part of the trust boundary and require policy checks before each instruction-bearing action.
Why namespace trust and plugin trust are not the same thing
Namespace trust says everything published under a trusted account or scope is acceptable by default. Plugin trust says a specific component has been reviewed and approved. Those are not equivalent. A namespace can contain later additions, altered behavior, or even malicious uploads that inherit the same trust label, while a plugin can expose new behavior after approval through updates or remote dependencies. The important distinction is that the trust decision applies to provenance, not to every future action. That is why governance has to be continuous if the execution environment is dynamic.
Practical implication: Use namespace approval only as a provenance filter and pair it with runtime policy enforcement for every privileged action.
Threat narrative
Attacker objective: The attacker wants the approved asset to keep working inside the environment while silently expanding what it can access or do after review.
- Entry occurs when a developer installs an MCP skill, server, or plugin that passes a one-time review but later behaves differently after deployment.
- Credential access follows when the asset requests or reuses tokens and API keys that were never intended for the full runtime behavior.
- Escalation happens when the asset fetches fresh instructions or executes new actions outside the original approval scope, turning the install-time review into stale evidence.
- Impact is achieved when the agent acts with valid credentials and the approved asset can leak data, contact external infrastructure, or perform harmful actions without a new gate.
Breaches seen in the wild
- Smithery.ai MCP hosting breach 2025: A Smithery.ai build flaw gave GitGuardian a live fly.io token controlling 3,000+ hosted MCP servers and the API keys their clients sent.
- JetBrains Marketplace AI Plugin Campaign: 15 malicious JetBrains Marketplace plugins steal AI API keys from 70,000+ developers via supply chain attack.
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
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.
The assumption that least privilege is fixed at approval time has broken: That assumption only holds when the asset's behavior is stable between review and use. MCP assets that fetch instructions or expand behavior after installation invalidate that premise because privilege is exercised later under different conditions. Practitioners have to rethink the decision boundary itself, not just add more review steps.
Approval lists create a false sense of governance because they only measure declared assets: The asset someone submitted is not always the asset that is running, and the board metric can look healthy while unreviewed behavior remains active. identity governance for AI agents becomes meaningful only when it tracks runtime authorization, ownership, and offboarding together.
Runtime policy is the named control shift this category needs: The useful control is not another faster queue, but a rule that is evaluated whenever the agent acts. That change makes governance visible at the point of use, which is where MCP abuse actually occurs. For practitioners, the governing unit is the action, not the approval record.
Tool and plugin governance now needs a trust boundary around provenance, update path, and execution context: A trusted source does not guarantee trusted behavior if the component can rewrite its own instructions or pull code at runtime. That is why MCP security has to join source trust with runtime enforcement, rather than treating them as separate problems. The practitioner conclusion is simple: review alone is not governance.
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.
- Read next: AI Agent Authorisation Guide
What this signals
Approval lists are becoming an incomplete control for MCP environments: If a skill can change behavior after install, the approved object and the running object are no longer the same thing. Security programmes should expect their governance metrics to move from admission counts to runtime enforcement coverage, because the old metric can look healthy while the real exposure grows.
Ephemeral governance only works when it is enforced at action time: The operating model now has to assume that some MCP assets will mutate, fetch instructions, or inherit broader permissions after review. That means future programmes will measure whether a policy was present at the moment of execution, not just whether an asset was once approved.
24,008 unique secrets were exposed in MCP configuration files in 2025 alone, according to the State of Secrets Sprawl 2026: That figure shows how quickly MCP sprawl can turn configuration and runtime trust into a credential exposure problem. Teams should expect secrets governance to become inseparable from policy enforcement as MCP adoption expands.
For practitioners
- 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.
- Run new controls in alert mode before blocking Let the policy generate violations for a week, review the unapproved assets in real use, and only then switch to enforcement.
Key takeaways
- One-time approval does not govern MCP behavior after install, which is why runtime enforcement matters more than a static yes or no.
- The core failure is an assumption gap: teams approve an artifact, but the live asset can fetch new instructions or change behavior later.
- Practitioners need per-action policy, tighter provenance checks, and a clear separation between admission review and runtime authorization.
Related NHI Mgmt Group resources: MCP Security Guide · AI Agent Authorisation Guide · AI Agent Observability, Audit and Incident Response Guide · Identity Governance for AI Agents Guide
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | The article shows assets being trusted to act after review without a strong runtime trust check. |
| NHI-05 — Overprivileged NHI | Approved assets can keep acting with more access than the original review can safely justify. | |
| NHI-10 — Human Use of NHI | Developers are currently using manual review processes to govern machine actions that need automated enforcement. | |
| Recommendation — Require stronger runtime authentication and authorization checks before MCP assets execute privileged actions. Reduce MCP asset permissions to the minimum required for each action and session. Remove human-only approval from the critical path and enforce policy where the NHI acts. | ||
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | The article describes agent-side use of approved access to perform actions beyond what review covered. |
| Recommendation — Bind agent privileges to each action so approved access cannot be reused outside its intended scope. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The core issue is whether permissions and entitlements are still valid at the moment the agent acts. |
| Recommendation — Review and enforce entitlements at execution time instead of relying on a single approval event. | ||
Key terms
- 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.
- Prompt Fetching: Prompt fetching is the practice of storing prompts outside application code and retrieving them at runtime. This allows teams to update, compare, and roll back prompts without redeploying services. It is especially useful when prompt versions need to be managed as part of an AI delivery workflow.
- Admission Controller: An admission controller is a Kubernetes control that validates or changes workload requests before the cluster admits them. It acts as a deployment-time policy layer, which makes it useful for blocking unsafe images, rejecting risky configuration, and enforcing runtime standards that build-time scans may miss.
- Per-Action Policy: Per-action policy is a governance pattern where each agent step, API call, or delegated operation is checked before execution continues. It is stronger than a one-time login decision because it evaluates the agent's behaviour as it unfolds, not just its initial access grant.
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 an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on October 22, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org