Install-time review fails because the real risk appears when the agent executes a tool call. A server can be approved in name yet expose disallowed tools, unexpected arguments, or changed behaviour later. Execution-time controls are needed because tool identity and tool behaviour can diverge after installation.
Why This Matters for Security Teams
Install-time approval creates a false sense of control because MCP tool risk is not fixed at deployment. The security decision that matters is whether a specific tool call is appropriate at the moment it executes, with the arguments, context, and upstream data that exist right then. That is why static review often misses tool drift, hidden capabilities, and later configuration changes. Current guidance from the OWASP Non-Human Identity Top 10 and NHIMG research on Ultimate Guide to NHIs both point to the same operational reality: identity and authorization must be managed as live controls, not one-time paperwork.
The issue becomes sharper in agentic environments because tools are chained, prompted, and reused in ways that are hard to predict in advance. An MCP server may look acceptable during onboarding, then later expose a new action, a broader scope, or a dangerous parameter path that was never present in the original review. In practice, many security teams encounter the breach only after the agent has already invoked the wrong tool, rather than through intentional pre-deployment validation.
How It Works in Practice
Execution-time control means the agent is not trusted just because the tool was approved once. Instead, each tool invocation is evaluated against current policy, current context, and current risk. That usually involves three layers: tool inventory, runtime authorization, and short-lived credentials. The inventory tells the team what the MCP server claims to expose. Runtime authorization checks whether the agent may use that tool for this specific task. Short-lived secrets limit what can be abused if the tool or agent is compromised.
For MCP and agentic workloads, static role assignment is usually too coarse. A tool may be safe for read-only lookups but unsafe for write actions, destructive operations, or cross-system chaining. Policy needs to ask what the agent is trying to do, not only which server it installed yesterday. Standards-oriented controls in OWASP Agentic AI Top 10 and NIST SP 800-53 Rev 5 Security and Privacy Controls support the broader principle: authorisation should be traceable, contextual, and revocable.
- Evaluate every MCP tool call at request time, not only when the server is installed.
- Scope permissions to the exact tool, action, and data domain the task requires.
- Use ephemeral credentials and automatic revocation after task completion.
- Log tool name, arguments, decision context, and downstream effects for auditability.
NHIMG research on the Analysis of Claude Code Security shows why runtime scrutiny matters: even a trusted agent can become unsafe when tool behavior and surrounding context change. These controls tend to break down when MCP servers are self-updating or multi-tenant, because tool catalogs and permissions can change faster than review processes do.
Common Variations and Edge Cases
Tighter runtime review often increases latency and operational overhead, requiring organisations to balance stronger containment against developer productivity and automation speed. That tradeoff is real, especially in fast-moving environments where tools are added frequently and teams want minimal friction. Best practice is evolving, but current guidance suggests that install-time approval can still exist as a baseline inventory control, provided it is not mistaken for an authorization decision.
There are also edge cases where a tool looks harmless but becomes dangerous only through composition. A read-only MCP action may feed a write-capable downstream system. A harmless metadata lookup may reveal secrets in arguments or logs. A server may pass review, then later change its manifest, dependencies, or authentication path without a fresh security review. NHIMG’s AI Agents: The New Attack Surface report highlights how often agents already act outside intended scope, which makes post-install monitoring and exception handling essential.
Where organisations rely on human ticketing for every change, execution-time control can become too slow to use. In those cases, policy-as-code and risk-based allowlists are the practical middle ground. The approach breaks down when tool output is unstructured, when agents can chain multiple tools without mediation, or when security teams cannot see the full MCP inventory before execution.
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, CSA MAESTRO and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST AI RMF and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A3 | Tool misuse at runtime is a core agentic application risk. |
| CSA MAESTRO | T1 | MAESTRO addresses runtime trust and control for autonomous agents. |
| NIST AI RMF | GOVERN | Governance is needed for changing AI behavior and tool risk. |
| OWASP Non-Human Identity Top 10 | NHI-03 | Static credentials and weak scoping are common NHI failure modes. |
| NIST CSF 2.0 | PR.AC-4 | Least privilege must apply to each tool invocation, not just onboarding. |
Review each agent tool call at execution time and restrict unsafe actions by context.
