When too many REST endpoints are exposed as MCP tools, the model gets a larger, less distinguishable action set and privilege becomes harder to reason about. Similar tools overlap, descriptions blur together, and the chance of unintended action selection rises. The result is not just clutter. It is an expanded agent-facing attack surface that is harder to review and govern.
Why This Matters for Security Teams
Exposing every REST endpoint as an MCP tool turns a narrow integration layer into a broad agent action surface. That matters because agentic systems are not static users: they are autonomous, goal-driven workloads that can chain tools, retry actions, and select paths a human operator did not anticipate. As OWASP Agentic Applications Top 10 and the OWASP Top 10 for Agentic Applications 2026 both emphasise, the security problem is not just the endpoint count, it is the loss of clear intent boundaries.
When a model sees dozens of similar tools, it may choose the nearest match rather than the safest match. That is how read-only functions become adjacent to write operations, and how a vague description can misroute a privileged call. The same pattern appears in broader agentic risk research: SailPoint reports that 80% of organisations have already seen AI agents act beyond intended scope, while only 44% have policies in place to govern them. That gap is why tool sprawl is not a cosmetic issue. It is a governance failure that expands the blast radius before anyone notices. In practice, many security teams encounter the misuse only after an agent has already taken the wrong branch of execution, rather than through intentional design review.
How It Works in Practice
The safer pattern is to expose fewer, higher-level MCP tools that map to business intents, not raw REST coverage. Instead of publishing every endpoint, teams should group actions by task, wrap them with policy checks, and require runtime authorisation for each request. Current guidance suggests pairing this with workload identity, short-lived credentials, and policy-as-code so the agent proves what it is, what it is trying to do, and whether that action is allowed at that moment.
This is where static RBAC often falls short. RBAC works when access patterns are known in advance, but autonomous agents behave dynamically. A better model is intent-based or context-aware authorisation, evaluated at request time with signals such as task, data sensitivity, environment, and tool chain. That model aligns with Analysis of Claude Code Security and with Anthropic — first AI-orchestrated cyber espionage campaign report, both of which underline how quickly tool access can become operationally dangerous once autonomy is introduced.
- Use JIT credentials that expire after the task, not long-lived secrets that survive across sessions.
- Bind each tool call to workload identity, not just an API token, so the system can verify the agent instance.
- Enforce explicit allowlists for tool groups and deny broad wildcard exposure.
- Log the prompt, tool selection, policy decision, and downstream effect for auditability.
For controls, the most useful mapping is to The 52 NHI breaches Report and the Ultimate Guide to NHIs — Why NHI Security Matters Now, because both reinforce the same operational lesson: credentials and permissions must be scoped to purpose, not merely to integration. These controls tend to break down when legacy APIs are exposed directly to agents without a policy layer, because the model inherits every accidental privilege baked into the endpoint surface.
Common Variations and Edge Cases
Tighter tool scoping often increases integration overhead, so organisations have to balance speed of adoption against control quality. That tradeoff is real, especially when teams want rapid prototyping or broad internal self-service. There is no universal standard for exact tool granularity yet, but current best practice is evolving toward intent-centric tools, not endpoint mirroring.
Some environments still need a larger tool set, such as developer platforms, incident response workflows, or multi-step automation pipelines. In those cases, the safest compromise is to separate low-risk informational tools from privileged action tools, then require step-up approval for writes, deletions, exports, and cross-system changes. This is also where zero standing privilege and ephemeral secrets matter most: if the agent only receives permission at the moment of execution, the exposure window is much smaller even when the catalog is large.
The governance frameworks all point in the same direction. OWASP Top 10 for Agentic Applications 2026, CSA MAESTRO, and NIST AI RMF all favour runtime controls, traceability, and bounded autonomy over blind expansion of capabilities. The edge case to watch is tool duplication: when several MCP tools do nearly the same thing, the model may select a weaker path because the descriptions are too similar. That is when naming discipline, intent labels, and policy evaluation matter more than endpoint completeness.
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 | A1 | Tool sprawl and unsafe action selection map to agentic application risk. |
| CSA MAESTRO | MAP-02 | MAESTRO addresses autonomous agent access and decision boundaries. |
| NIST AI RMF | AI RMF covers governance, accountability, and risk treatment for agent behaviour. |
Design agent controls around intent, identity, and step-up approval for sensitive actions.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 6, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
