Organisations should require an explicit deny-by-default rule for high-risk tools and then add approval or step-up checks before any destructive or infrastructure-changing action can run. That should be paired with argument inspection and response filtering so a valid agent session cannot silently convert into a high-impact change operation.
Why This Matters for Security Teams
When an MCP tool can change data or infrastructure, it stops being a convenience layer and becomes a privileged execution path. That means the real control problem is not whether the model is “trusted,” but whether each tool invocation is safe at the exact moment it is requested. The strongest current guidance points to denying risky actions by default, then forcing explicit approval, step-up checks, and tight scoping before any destructive operation proceeds. This is especially important because MCP deployments often accumulate broad permissions faster than teams can review them, as shown in The State of MCP Server Security 2025.
Security teams often underestimate how quickly a benign read-only workflow can turn into a write-capable one once the tool is connected to live infrastructure. The issue is not only privilege, but also timing, because an approved session can be reused in ways the original operator never intended. In practice, many teams discover this only after an agent has already made a high-impact change rather than through deliberate access design.
How It Works in Practice
The immediate response should be to classify every MCP tool by blast radius and then treat any write path as a privileged operation. For tools that can modify production systems, databases, cloud resources, or configuration state, the default posture should be deny unless the request is explicitly authorised at runtime. Static role assignment alone is too blunt for this problem, because an agent’s behaviour is goal-driven and can shift from harmless retrieval to operational change in a single conversation.
Practical controls usually need four layers. First, scope the tool so it only reaches the minimum object set, environment, or resource class required. Second, inspect arguments before execution to block destructive flags, unsafe payloads, and target expansion. Third, require step-up approval for high-risk actions, especially in production or when changes are irreversible. Fourth, filter the response channel so a tool cannot leak secrets, tokens, or confirmation data back into the model loop.
- Mark write-capable MCP tools as high-risk by default.
- Separate read-only and change-capable tools into different trust tiers.
- Use runtime policy checks, not only pre-assigned roles.
- Require human approval for destructive, privileged, or environment-wide actions.
- Log arguments, approvals, and final tool output for review.
These controls align with the direction reflected in OWASP Top 10 for Agentic Applications 2026 and the control expectations in NIST SP 800-53 Rev 5 Security and Privacy Controls. They are also consistent with NHIMG research on agentic risk in OWASP Agentic Applications Top 10, which stresses that tool exposure and execution authority must be evaluated together.
These controls tend to break down when a single MCP server is allowed to reach both low-risk and production-grade systems, because the policy boundary becomes too coarse to stop privilege escalation cleanly.
Common Variations and Edge Cases
Tighter tool controls often increase friction for operators and platform teams, so organisations have to balance safety against workflow speed. That tradeoff is real, but current guidance suggests it is better to absorb the delay than to allow an agent to inherit broad, reusable change rights.
One common edge case is the “read-only” tool that can still trigger side effects through indirect actions, such as status refreshes, cache writes, or linked automation hooks. Another is the tool that is safe in a sandbox but dangerous in production because the same command targets different systems at runtime. There is no universal standard for handling every MCP change path yet, so the practical answer is to apply the strictest interpretation until the tool’s side effects are fully understood.
Organisations should also be careful with chained actions. A single apparently safe prompt can lead to a sequence where the model reads state, forms a plan, and then uses a second tool call to apply changes. That is why approval should attach to the specific action, not just the session. Where the environment includes infrastructure-as-code, policy-as-code, or auto-remediation, teams should validate whether a human approval is still required for the final apply step. If not, the tool is effectively operating with standing change authority, even if the interface looks constrained.
For teams building out governance, the safest pattern is to treat any tool that can modify data or infrastructure as if it were a production admin interface with machine speed and human ambiguity. That is the real risk profile.
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 | A2 | High-risk tool execution is a core agentic privilege escalation risk. |
| CSA MAESTRO | T2 | MAESTRO covers tool governance for autonomous agent actions. |
| NIST AI RMF | AI RMF applies to controlling and monitoring autonomous system impact. | |
| OWASP Non-Human Identity Top 10 | NHI-03 | Over-privileged machine identities often enable unsafe MCP tool actions. |
| NIST CSF 2.0 | PR.AC-4 | Least privilege and access governance directly apply to tool-capable systems. |
Classify write-capable tools as high-risk and require runtime approval before execution.
