Function calling usually keeps tool definitions and execution inside the application, so the app carries most of the trust and credential risk. MCP moves tools behind protocol-based servers, which makes it easier to isolate credentials, scope access, and manage logging at the server boundary. For enterprise security, that difference is about control placement, not just developer convenience.
Why This Matters for Security Teams
Function calling and MCP can look similar at a developer demo level because both let an AI invoke tools, but the security boundary is very different. With function calling, the application often retains direct control over tool definitions, execution paths, and the credentials needed to make those calls. That concentrates risk inside the app runtime, where one weak integration can expose more than one system. With MCP, the tool layer can be moved behind a protocol boundary, which creates a cleaner place to apply logging, scoping, and isolation. That matters because enterprise risk is usually caused by uncontrolled authority, not by the protocol label itself.
This distinction becomes more important as AI systems behave more like agents than chat interfaces. Autonomous workloads can chain actions, retain context, and reach into multiple systems in ways that static IAM assumptions do not model well. Current guidance from the OWASP Top 10 for Agentic Applications 2026 and NHIMG’s OWASP Agentic Applications Top 10 points to the same operational concern: tool access must be governed as a runtime decision, not just a code-design choice.
In practice, many security teams encounter tool sprawl and credential exposure only after an agent has already been allowed to call too much, too broadly, for too long.
How It Works in Practice
For enterprise security, the practical difference is where trust is enforced. In a function-calling design, the app commonly embeds tool schemas, routes calls directly, and often handles secrets locally. That can be acceptable for low-risk internal automation, but it makes credential containment and audit separation harder. In an MCP design, the model talks to a protocol server that exposes tools through a defined interface, so the server becomes the right place to enforce authentication, authorization, rate limits, and logging.
That creates better options for NHI governance. Credentials can be kept out of the application and managed at the server boundary, which supports tighter secret scoping, better audit trails, and more consistent revocation. It also aligns better with workload identity patterns, where the caller proves what it is before getting access. NHIMG’s Ultimate Guide to NHIs — What are Non-Human Identities explains why this matters for machine actors, while the Ultimate Guide to NHIs — Why NHI Security Matters Now ties the identity problem to real enterprise exposure.
- Use function calling only when the app can safely own the entire trust chain.
- Use MCP when you need a separate control plane for secrets, logging, and tool authorization.
- Treat MCP servers like security boundaries, not just integration helpers.
- Evaluate access at request time, especially when agents can choose tools dynamically.
For implementation detail, the architecture guidance in the OWASP Agentic AI Top 10 reinforces least privilege, tool isolation, and abuse resistance at the agent boundary. These controls tend to break down when the MCP server is still backed by shared secrets, because protocol separation does not compensate for broad token reuse.
Common Variations and Edge Cases
Tighter tool isolation often increases implementation overhead, so organisations must balance security gain against integration complexity and operational maturity. That tradeoff is real, especially where teams want fast experimentation or have many legacy APIs that were never designed for protocol mediation.
There is no universal standard for how fine-grained MCP authorisation should be, so current guidance suggests starting with the most sensitive actions first: secrets access, data export, admin changes, and write operations. For lower-risk read-only tools, lighter controls may be acceptable if logging and rollback are strong. The best practice is evolving, and the control model should match the agent’s authority, not the novelty of the interface.
Edge cases also matter. A well-designed MCP layer can still be risky if the server delegates to shared service accounts, if tool permissions are broad, or if the agent can chain multiple low-risk tools into one high-risk outcome. That is why enterprise teams should pair protocol controls with intent-based authorization, short-lived credentials, and workload identity. NHIMG’s Analysis of Claude Code Security shows how code-centric AI security still depends on boundary design, not just model behaviour. In environments with highly dynamic agent workflows, heavily shared infrastructure, or unmanaged secrets sprawl, both function calling and MCP can fail if the identity and policy layer is not rebuilt around autonomous 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 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 agent autonomy are central to function calling vs MCP. |
| CSA MAESTRO | Covers agent governance, orchestration boundaries, and runtime controls. | |
| NIST AI RMF | GOVERN | Supports accountability and oversight for autonomous tool-using systems. |
Constrain agent tool access, logging, and abuse paths before exposing any execution capability.
