Use a small number of layered tools for discovery, planning, and execution, then define which combinations are allowed within policy. That preserves flexibility for the agent while keeping the final action path auditable and bounded. The goal is controlled delegation, not unrestricted endpoint exposure.
Why This Matters for Security Teams
MCP is attractive because it standardises how agents discover tools and execute work, but that same flexibility can turn into uncontrolled reach if every server, tool, and connector is exposed by default. Security teams are not trying to eliminate MCP; they are trying to stop it from becoming an unbounded delegation layer. Current guidance suggests the control problem is less about the protocol itself and more about how permissions, tool chaining, and secrets are governed around it.
The risk is visible in real deployments. NHIMG research on The State of MCP Server Security 2025 found that only 18% of MCP server deployments implement any form of access scoping for tool permissions, while 53% expose credentials through hard-coded values in configuration files. That means flexibility often arrives before basic guardrails. The agentic risk is also broader than MCP: the OWASP Agentic AI Top 10 treats tool abuse, over-permissioning, and unsafe orchestration as core threats, not edge cases.
In practice, many security teams discover MCP overexposure only after an agent has already chained tools into an action path that nobody explicitly approved.
How It Works in Practice
The practical balance is to treat MCP as a discovery and orchestration interface, not a blanket trust boundary. Security teams usually get better results by allowing a limited catalog of approved tools, then applying policy to the combinations an agent can invoke, the data each tool can touch, and the time window during which access is valid. That keeps the agent useful while making the final action path auditable and bounded.
Implementation typically starts with three layers. First, define which MCP servers are approved and what each server can expose. Second, enforce tool-level scoping so the agent can only call the minimum actions required for a task. Third, add runtime checks so high-risk combinations, such as discovery plus export or read plus write, require stronger approval or are blocked outright. This aligns with the direction described in the Ultimate Guide to NHIs — Standards, which emphasises workload identity, policy enforcement, and credential discipline as the control plane for machine actors.
- Use workload identity for each agent or service, not shared credentials.
- Issue short-lived secrets per task, then revoke them automatically when the task ends.
- Log tool selection, parameter scope, and downstream calls for later review.
- Separate discovery tools from execution tools so a planning step cannot silently become a destructive action.
For policy decisions, current guidance suggests evaluating requests at runtime rather than relying on static RBAC alone, because agents behave dynamically and can change intent mid-session. That is consistent with the OWASP Top 10 for Agentic Applications 2026 view that tool misuse and privilege escalation should be addressed as live authorization problems. These controls tend to break down when teams give one MCP server broad upstream credentials, because the server then becomes a high-value pivot point for lateral movement.
Common Variations and Edge Cases
Tighter MCP control often increases integration overhead, so organisations have to balance developer speed against blast-radius reduction. That tradeoff is real, especially when teams want rapid experimentation with new tools or when multiple agents need different workflows for the same business process.
Best practice is evolving around a few common patterns. A small internal set of highly governed servers usually works better than many loosely reviewed servers. Read-only tools can often be exposed more broadly than write-capable tools, but there is no universal standard for that yet. Some teams also separate planning from execution so an agent can reason over data without being able to change systems directly. That distinction becomes especially important when an agent is connected to ticketing, code, or cloud administration workflows.
One important edge case is inherited trust from upstream systems. If an MCP server bridges into a legacy app, the agent may appear well controlled while still inheriting excessive backend permissions. Another is human fallback: if operators can bypass policy during incidents, that exception path must be logged and time boxed or it will become the real access model. NHIMG’s AI Agents: The New Attack Surface report shows why this matters, with 80% of organisations reporting agents have already performed actions beyond intended scope. Flexibility is useful, but only when every escape hatch is deliberate, visible, and reversible.
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 CSA MAESTRO address the attack and risk surface, while NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | TBD | Addresses tool abuse and unsafe orchestration in agentic MCP flows. |
| CSA MAESTRO | TBD | Covers governance for autonomous agents using shared tool ecosystems. |
| NIST AI RMF | Supports runtime risk management for dynamic MCP-driven agent behaviour. |
Constrain agent permissions, separate planning from execution, and validate each tool call.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 8, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
