MCP makes more sense when tool reuse, access scoping, and auditability matter more than fast prototyping. If multiple agents or teams need the same capability, or if the tool touches sensitive systems, server-based separation usually provides cleaner governance than embedding the logic in one app. Function calling remains acceptable for small, short-lived experiments.
Why This Matters for Security Teams
For agentic systems, the real decision is not just whether a tool can be called from code. It is whether the capability should live behind a governed protocol boundary that can be scoped, logged, and revoked across multiple agents and teams. That is why OWASP Agentic Applications Top 10 and the external OWASP Agentic AI Top 10 both treat uncontrolled agent tool use as a core risk area, not an implementation detail. Function calling can be sufficient for a narrow prototype, but once an AI agent has autonomous execution authority, the blast radius changes fast.
In practice, the governance problem is not speed of integration, it is the lifecycle of access. MCP becomes more attractive when a capability must be reused by different workloads, constrained by RBAC or JIT policy, and traced through audit logs without embedding secrets or permission logic into each app. That separation matters because static code-level integrations tend to age badly as prompts, tools, and team ownership change. Current guidance suggests the protocol boundary should be designed for control first and convenience second, especially when the agent can chain actions across systems.
Security teams usually discover the gap after an agent has already inherited more reach than intended, not during the initial build review.
How It Works in Practice
MCP makes more sense when the team needs a shared control plane for tools rather than a one-off function wrapper. A server-based model lets security define access scope once, then apply it consistently across agents, environments, and tenants. That is particularly useful when an agent needs to request a capability on demand, receive short-lived credentials, and be denied if the requested action exceeds its intent. In agentic environments, that aligns better with workload identity and runtime authorisation than with a static API key buried in application code.
For example, a data-retrieval tool may be safe in one context but dangerous in another if the agent can combine it with other tools to reach sensitive systems. MCP gives practitioners a cleaner place to enforce policy, log requests, and separate the tool provider from the agent runtime. That model also supports the emerging pattern of intent-based authorisation, where the decision is made at request time based on what the agent is trying to do, not just who called the library. The same logic appears in Analysis of Claude Code Security, where the operational lesson is that access control must keep pace with autonomous behaviour. It also maps closely to the external OWASP Top 10 for Agentic Applications 2026, which emphasizes misuse of tools, identity, and permissions.
- Use MCP when several agents need the same governed capability.
- Prefer JIT, ephemeral secrets over long-lived credentials exposed to the app layer.
- Bind access to workload identity, not to a human admin identity copied into automation.
- Evaluate policy at runtime so the same tool can be allowed, limited, or denied by context.
These controls tend to break down when the environment still relies on shared service accounts and ad hoc tool wrappers, because the agent can bypass the intended separation through chained actions and hidden state.
Common Variations and Edge Cases
Tighter protocol governance often increases operational overhead, requiring organisations to balance reuse and auditability against setup time and platform complexity. There is no universal standard for this yet, so current guidance suggests choosing MCP when the tool is security-sensitive, multi-tenant, or likely to be reused beyond a single prototype. For a throwaway internal demo, function calling may be simpler and perfectly acceptable.
The edge cases usually show up when teams assume the agent is “just another app.” Once the workload is autonomous, static RBAC alone is often too blunt because the agent’s behaviour is dynamic and goal-driven. Best practice is evolving toward short-lived secrets, explicit intent checks, and workload identity primitives such as SPIFFE or OIDC-backed assertions. The practical question is whether the system can prove what the agent is, what it is trying to do, and whether that action is still valid right now. That framing is consistent with OWASP Agentic Applications Top 10 and the external OWASP Agentic AI Top 10. It also reflects the governance themes in Analysis of Claude Code Security, where security depends on constraining autonomous execution, not merely authenticating the caller.
In highly dynamic environments with rapid prompt changes, shared tool registries, and multiple model vendors, function calling fragments governance faster than teams can document it.
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 | A2 | Tool misuse and overbroad agent permissions are central to this MCP vs function calling choice. |
| CSA MAESTRO | IAM | MAESTRO emphasizes identity and access control for autonomous agent workflows. |
| NIST AI RMF | AI RMF governs accountability and risk treatment for autonomous AI behaviour. |
Prefer governed tool boundaries, scoped access, and runtime checks before exposing agent actions.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on May 30, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
