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.
Why install-time approval fails for MCP
Install-time approval treats the package or skill as if its risk were fixed at admission, but MCP systems are often dynamic. A benign initial review does not guarantee safe later behavior if the component can pull fresh prompts, alter tool calls, or expand its own execution path after it is already trusted.
The core problem is that the security decision is made before the full action set exists. In practice, the asset that was approved can become a different risk surface at runtime, so the control has to follow the behavior that actually executes, not the artifact that merely passed an onboarding check.
That is why MCP guidance needs to be anchored in runtime authorization, not just initial installation, as described in the MCP Security Guide and the Model Context Protocol: Authorization specification.
What changes after installation?
Once an MCP component can fetch new instructions or invoke new tools, the important question shifts from “Was this approved?” to “What is it allowed to do right now?” That distinction matters because approval at install time usually covers the package identity, version, or initial manifest, not later tool selection, prompt content, context changes, or remote updates.
If the component can self-modify, chain to new capabilities, or depend on external configuration, then the original admission decision no longer captures the real operational state. The security boundary moves from software admission to action-level control, where each request should be evaluated against policy, context, and least privilege.
For agent-like systems that can change goals, tools, or privilege use over time, this is the same class of problem covered by the OWASP Agentic AI Top 10 and NHIMG’s agentic AI applications guide.
How runtime policy changes the control model
Runtime policy changes the control model from “admit once” to “authorize continuously.” That means the system should check the specific action, target, and context at the moment of use, especially when a tool call can read data, write data, invoke downstream services, or cross a trust boundary.
The practical effect is that policy must be able to distinguish safe from unsafe behavior even inside an approved component. A tool that is acceptable for one workflow may be inappropriate in another, and a prompt, task, or update can change the risk profile without changing the installed artifact.
That is also why runtime evaluation should be paired with tight identity and privilege controls for the actor executing the action, as outlined in AI Agent Identity Security: The 2026 Deployment Guide and NHI Authentication Guide.
Risk and Threat Considerations
Install-time approval creates a stale trust decision. If the approved MCP component can later fetch instructions, reach new tools, or inherit broader credentials, an attacker who controls the update path, prompt source, or downstream dependency can turn a one-time review into a durable foothold.
Failure mechanism: The system trusts an initial package review while the effective behavior is determined later at runtime, so a changed instruction set or expanded tool path bypasses the original decision.
Impact: The component can make unauthorized tool calls, access data it was never meant to reach, or extend compromise through a trusted execution path that operators assume is already safe.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST SP 800-53 Rev 5, NIST Zero Trust (SP 800-207) and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | MCP approval breaks when runtime actions exceed the originally reviewed privilege scope. |
| ASI02 — Tool Misuse | The issue is unsafe tool invocation after install, not just trusted admission. | |
| Recommendation — Enforce per-action authorization so approved agents cannot exceed their current privilege scope. Restrict tool execution to policy-approved actions at runtime. | ||
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | Runtime MCP decisions depend on trustworthy service and agent authentication, not one-time install approval. |
| Recommendation — Require strong runtime authentication before allowing tool access or updates. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Install-time approval fails when later behavior needs tighter privilege scoping. |
| CM-7 — Least Functionality | A package that can later gain tools or behaviors violates the least-functionality expectation. | |
| IA-5 — Authenticator Management | Dynamic MCP use depends on controlling secrets and authenticators that can outlive install-time review. | |
| Recommendation — Limit each MCP action to the minimum permissions needed at runtime. Disable unnecessary tools and capabilities before permitting runtime use. Rotate and scope credentials so runtime authority cannot silently expand. | ||
| NIST Zero Trust (SP 800-207) | AC-4 — Information Flow Control | Runtime policy must govern each action and data flow, not just initial admission. |
| Recommendation — Apply continuous policy checks to every request that crosses a trust boundary. | ||
| OWASP ASVS | V8 — Authorization | The core failure is authorizing once instead of validating each privileged action. |
| V10 — OAuth and OIDC | MCP runtime authorization commonly depends on token-bound access and audience checks. | |
| V9 — Self-contained Tokens | Install-time approval can miss whether a token still authorizes current behavior. | |
| Recommendation — Verify authorization on every sensitive operation, not only at onboarding. Bind tokens to the correct audience and scope for each runtime request. Limit token lifetime and scope so stale approval cannot persist. | ||
Practitioner Guidance
What to verify: Confirm that approval is bound to runtime behavior, not just the package or skill name. If the component can update itself, fetch instructions, or choose tools dynamically, treat the install-time decision as a narrow admission control, not as a standing authorization grant.
Decision rule: If the component can change what it does after install, require per-action policy checks and scoped permissions for each tool invocation. If it cannot, a simpler admission-only model may be acceptable, but only if the runtime cannot expand authority through configuration or dependency changes.
Practitioner takeaway: The security mistake is confusing “approved to run” with “approved to act”; MCP needs policy that evaluates the current action and context every time, because the risk lives in execution, not installation.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 22, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org