MCP versus function calling: security and scale trade-offs

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Descope's blog post: MCP and function calling differ in architecture, security, portability, and scale, with MCP separating tool access into server-side components while function calling keeps it embedded in the application.

Why it matters: IAM, PAM, and NHI teams need this distinction because it changes where credentials live, how least privilege is enforced, and what auditors can actually trace as AI agent ecosystems expand.

Context

MCP and function calling are both ways for AI systems to reach tools and data, but they place trust in different parts of the stack. Function calling embeds tool definitions and execution logic in the application, while MCP moves that integration into separate protocol-driven servers. For identity teams, the real question is where credentials, authorization, and accountability sit when agents begin to act at production scale.

That architectural split matters because it changes the governance surface for non-human identities. In an application-centric model, credentials and permissions tend to accumulate alongside the code that invokes them. In a server-centric model, controls can be isolated, reused, and audited at the integration boundary rather than scattered across every agent implementation.

Key questions

Q: What breaks when tool access stays embedded in the application layer?

A: When tool definitions, credentials, and execution logic sit inside the same application, compromise or misconfiguration of that app can expose every function the model can reach. The result is a large blast radius, weak reuse, and harder offboarding. Separate governed boundaries are easier to audit and revoke than scattered in-line integrations.

Q: When does MCP make more sense than function calling?

A: 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.

Q: How do you know whether an AI integration is too tightly coupled?

A: If changing a tool means editing the main application, duplicating schemas, or reworking secrets handling in multiple places, the integration is too tightly coupled. That is a sign the permission model is embedded in code rather than governed at a reusable boundary. The cleaner the separation, the easier the control.

Q: What is the difference between application-level and server-level access control for agents?

A: Application-level access control ties tool use to the code that invokes it, so the app holds both the instructions and the credentials. Server-level access control puts the sensitive permissions behind a separate component that exposes only the approved capability. The second model is easier to scope, monitor, and retire.

Technical breakdown

How function calling binds tools to the application

Function calling exposes tools by embedding schemas directly in the model request, then relying on the application to execute whatever the model selects. That is simple for prototypes, but it means tool logic, credential handling, and request execution all live inside one trust boundary. From an identity perspective, the application becomes the control point for every permission the model can reach. The operational downside is that a change to any tool usually means touching the application code and its surrounding secrets handling, which increases coupling and weakens reuse across agents or models.

Practical implication: treat function calling as an application-local integration pattern, not a scalable identity boundary for shared or high-risk access.

Why MCP shifts credential and authorization control to the server

MCP uses a client-server protocol in which tools, resources, and prompts are exposed by separate servers, so credentials can stay isolated from the client application. That server-side separation is the core security difference: the agent does not need direct backend access, only the ability to call what the MCP server exposes. This makes least privilege easier to express because permission scope is attached to the server, not sprayed across the application. For NHI governance, that creates a cleaner audit trail and a narrower blast radius if the client is compromised.

Practical implication: place sensitive access behind MCP servers when you need credential isolation, narrower permission scope, and clearer auditability.

Why MCP becomes more maintainable as agent fleets grow

MCP’s modular design lets one server serve many clients, which reduces duplicated integration code and makes tools reusable across applications and model providers. That matters because AI estates rarely stay simple: teams add more agents, more tools, and more data sources, then inherit a maintenance problem when every connection is custom-built. MCP externalises the integration layer so it can be versioned, tested, and deployed separately. The result is less architectural drift and a governance model that is easier to standardise across multiple AI use cases.

Practical implication: standardise on protocol-based tool servers when you expect multiple agents, multiple models, or long-lived operational ownership.

Breaches seen in the wild

• CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.
• AI agent retail card theft campaign 2026: AI agents breached 27+ retailers for about $25 each, used cloud keys and a Secrets Manager dump, and stole 600,000+ payment cards.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Tool integration becomes an identity design decision once AI systems reach production scale. The article’s core comparison is not really about developer convenience. It is about whether trust, permissions, and auditability remain inside the app or move to an integration layer that can be governed independently. For identity programmes, that means tool integration patterns now belong in the same conversation as privilege model design and access boundary definition.

MCP creates a more governable non-human identity boundary than function calling. When credentials stay on the server and the client only speaks through the protocol, the access decision becomes easier to scope, inspect, and reuse. That is exactly the kind of boundary IAM and PAM teams need when agent estates begin to span multiple tools and workloads. Practitioners should read MCP as an architectural control point, not just a transport choice.

Least privilege is easier to operationalise when permissions are attached to a reusable server. Function calling pushes tool access into each application instance, which makes permissions harder to standardise and harder to retire cleanly. MCP centralises the exposure surface so access can be governed once and reused many times. For NHI programmes, that shifts emphasis from per-app credential sprawl to protocol-level governance and lifecycle control.

Protocol standardisation is becoming the decisive factor in agentic identity governance. The article points to a broader market reality: as AI agents multiply, the winner is not the simplest integration but the one that can be governed consistently across environments. That aligns with OWASP-NHI and zero trust thinking, where the question is not whether an integration works, but whether it can be scoped, monitored, and revoked without rebuilding the stack. The practitioner conclusion is to favour architectures that make policy repeatable, not just possible.

Named concept: server-side trust isolation. This article shows that the most useful architectural shift is not the protocol itself but the relocation of trust away from the application and into separately governed MCP servers. That reduces coupling between model behaviour and credential exposure, which is the practical prerequisite for scaling agentic systems without multiplying unmanaged access paths. Identity teams should treat this as the default design goal for shared AI integrations.

From our research library:

• 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, according to the 2026 Infrastructure Identity Survey.
• 40 percent of financial and software companies have already deployed agentic AI systems, and deployments are expected to double by 2028.
• Read next: AI Agent Authorisation Guide

What this signals

Server-side isolation is the main governance advantage MCP offers over function calling. Once tool credentials and authorization live behind a reusable server boundary, teams can manage access at the point where capability is exposed rather than inside every application that consumes it. That matters because AI estates tend to accrete tool paths quickly, and scattered permissions become difficult to certify or revoke.

Server-side trust isolation: this is the design pattern that matters most for agentic tool access. Instead of letting each application own its own credential path, separate servers provide a boundary where scope, logging, and lifecycle controls can be standardised across clients and models. The practical effect is less identity sprawl as agent usage grows.

For practitioners

• Define the trust boundary for tool execution Map which credentials, data sources, and approval paths remain inside the application and which should move behind a separate MCP server boundary.
• Separate credentials from client code Keep backend secrets in the server process rather than in the model-facing application so compromise of the client does not expose every downstream permission.
• Standardise reusable tool servers Package shared integrations as protocol-based servers so multiple agents and multiple models can reuse the same governed capability set.
• Review auditability at the integration layer Verify that server-level logs can show which tool was called, by which client, and under what authorization scope before expanding usage.
• Limit application-local function calling to small scopes Reserve in-app function calling for narrow prototypes or one-off tools where the overhead of a separate server would outweigh the control benefit.

Key takeaways

• MCP and function calling differ most at the trust boundary, not just in developer ergonomics.
• Function calling keeps credentials and tool logic close to the application, which increases coupling as environments grow.
• MCP makes reusable, server-side control easier, so identity teams should prefer it when auditability and least privilege matter.

Key terms

• Function Calling: A model integration pattern where the application embeds tool definitions in the request sent to the LLM and executes the chosen function itself. It is simple to implement, but the same process often carries the credentials and permissions for every exposed action.
• Model Context Protocol: Model Context Protocol is an open protocol that lets AI agents connect to tools and data sources. It expands what an agent can reach, so governance has to cover not only the model and its prompts, but also every system that can receive or return agent-driven data.
• Server-Side Trust Isolation: A design approach that keeps sensitive credentials and authorization logic in a separate service instead of in the model-facing application. For AI systems, this reduces blast radius and makes audit, revocation, and reuse easier across multiple clients.
• Agentic Tool Execution: Agentic tool execution is the pattern where an AI system does more than generate text and instead calls APIs, reads data, runs functions, or changes state. This creates security risk because legitimate operations can be manipulated into unintended actions, making intent harder to distinguish from normal behavior.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.