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.
What asset approval actually decides
Asset approval is a pre-admission control. It answers whether a connector, server, bundle, or integration is acceptable to bring into the MCP environment in the first place, based on its provenance, intended scope, and expected trust boundary. That makes it a useful gate for supply chain hygiene, packaging review, and baseline policy decisions, but it is still only a snapshot at approval time.
In practice, asset approval is strongest when the asset is relatively stable and the main question is whether it should be allowed to exist in the environment at all. It does not, by itself, guarantee that the asset will continue to behave safely after updates, configuration changes, or new tool bindings are introduced.
How per-action policy changes the control model
Per-action policy evaluates each request at runtime. Instead of trusting the asset because it was approved earlier, it asks whether the specific action, tool call, data access, or side effect should be allowed now. That is a better fit for MCP because a trusted asset can still become dangerous once it starts chaining tools, broadening scope, or acting on new inputs.
The important shift is from static trust to contextual authorization. A runtime policy can apply different decisions based on the action, target resource, user context, risk score, or delegated authority. In a dynamic MCP environment, that is what prevents an approved asset from becoming an overly capable execution path.
Why the difference matters in dynamic MCP governance
The distinction is not just procedural. Asset approval reduces the chance that a clearly untrusted component gets deployed, while per-action policy reduces the blast radius after deployment. When behavior can change after install, the original approval no longer proves that every later action is safe, so governance must treat execution as a separate decision point.
This is why a mature MCP governance model usually needs both: approval to control what enters, and action policy to control what happens next. A system that relies only on admission review can miss privilege expansion, unexpected tool use, or changes in how the asset interacts with downstream systems.
Risk and Threat Considerations
Approved MCP assets can still become a security problem if their runtime behavior expands beyond what was reviewed. The risk is that an attacker, a malicious update, or a legitimate but unsafe code path turns a trusted asset into a path for unauthorized tool use, data exposure, or privilege abuse.
Failure mechanism: A one-time approval creates false confidence, while the asset later executes actions that were never separately checked against current context, permissions, or intended scope.
Impact: Organisations can end up with approved components that still perform harmful or excessive actions, especially when the MCP environment allows new tools, new data sources, or new execution paths after initial onboarding.
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 API Security Top 10 address the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Runtime action control prevents approved agents from overstepping scope. |
| Recommendation — Enforce per-action authorization before agents invoke tools or sensitive operations. | ||
| OWASP API Security Top 10 | API5 — Broken Function Level Authorization | Per-action policy is the control that blocks unauthorized functions after admission. |
| Recommendation — Check each action against function-level authorization before execution. | ||
| NIST SP 800-53 Rev 5 | AC-3 — Access Enforcement | MCP action decisions require enforcement at the point of use, not only at admission. |
| AC-6 — Least Privilege | Dynamic MCP behavior needs least privilege per action, not broad standing trust. | |
| CA-3 — System Interconnections | Asset approval aligns with onboarding and boundary review of connected MCP assets. | |
| Recommendation — Enforce access decisions at runtime for each MCP action. Limit each action to the minimum privilege needed at execution time. Review and approve interconnections before allowing new MCP assets into the environment. | ||
Practitioner Guidance
What to verify: Treat approval as the entry gate and verify that per-action policy exists wherever an MCP asset can invoke tools, touch sensitive data, or trigger side effects. If the runtime decision point is missing, the approval process is carrying too much weight.
Decision rule: If the asset’s capabilities can change after install, rely on per-action authorization for safety-critical operations and use asset approval only as a prerequisite, not as evidence of ongoing trust.
What good looks like: The environment can explain why an asset was admitted, but every meaningful action is still independently authorized at runtime and can be denied without removing the asset entirely.
Practitioner takeaway: Asset approval manages entry, per-action policy manages behavior, and MCP governance is only defensible when those two decisions are separated.
Related resources from NHI Mgmt Group
- What is the difference between attack surface management and NHI governance?
- What is the difference between role-based access and API key governance for NHI security?
- What is the difference between human IAM controls and NHI governance?
- What is the difference between using MCP for cloud governance queries and using it for policy execution?
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