MCP versus function calling: security and scale trade-offs

At a glance

What this is: This comparison explains how MCP and function calling differ in architecture, implementation, security, portability, and scale, with the central finding that MCP reduces coupling and improves credential isolation.

Why it matters: IAM and NHI teams need to understand where identity, permissioning, and secrets handling move when AI agents depend on external tools.

By the numbers:

• Only 18% of MCP server deployments implement any form of access scoping for tool permissions.

👉 Read Descope's comparison of MCP and function calling for AI tool integration

Context

MCP and function calling are both ways to let AI agents use tools, but they place identity, authorization, and secrets in very different parts of the system. That difference matters for NHI governance because the security boundary shifts from the application itself to a protocol-governed server model, which changes how least privilege, auditability, and blast radius are enforced.

For practitioner teams, the real question is not which pattern is easier to demo, but which pattern keeps access scoped when agents move from prototypes to production. Once non-human identities begin acting across APIs, databases, and internal services, the trust model around tool use becomes an IAM design issue, not just an engineering convenience issue.

Key questions

Q: How should security teams govern AI agents that need access to multiple tools?

A: Security teams should treat each tool as a separately governed entitlement, not as a generic extension of the agent. The practical goal is to isolate credentials, scope permissions narrowly, and make revocation possible without rebuilding the whole application. That approach reduces blast radius and keeps audit trails usable when agents scale.

Q: What is the difference between function calling and MCP for enterprise security?

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

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: Why do AI agents complicate least-privilege design?

A: AI agents complicate least-privilege design because their tool use can change dynamically while the underlying permissions remain persistent. The system may need broad enough access to complete a task, but that same access can overshoot if scope is not tightly controlled. The fix is task-scoped authorisation with clear boundaries, not wider standing access.

Technical breakdown

How function calling concentrates trust in the application

Function calling embeds tool schemas in the same request flow that the application uses to talk to the model. The application then executes the requested action with its own credentials, which means the LLM, orchestration logic, and secrets often share one operational boundary. That design is simple, but it couples permissions to application code and makes every tool expansion part of the same trust domain. In NHI terms, the tool runner becomes a high-value identity surface because compromise of the app can expose multiple credentials and actions at once.

Practical implication: Treat function calling as an application-level trust model and reduce the number of credentials exposed to that process.

Why MCP changes the identity and authorization boundary

MCP uses a client-server model where tools and resources live behind a dedicated server, and the client connects through a standardized protocol. That separation lets the server own its own credentials, access checks, and logging, rather than inheriting them from the application that invokes the model. From an IAM perspective, this is closer to a least-privilege service boundary: each server can expose only the actions it should support, and the client never needs direct backend access. The result is a cleaner way to scope non-human identities that need tool access without overexposing the host application.

Practical implication: Place sensitive tools behind isolated MCP servers and enforce permissioning at the server boundary.

What portability and scale mean for NHI governance

Function calling is convenient when a small number of tools live inside one codebase, but it becomes brittle as tool count, provider diversity, and lifecycle demands increase. MCP pushes integrations toward reusable components that can be versioned, tested, and deployed separately, which matters when access reviews, revocation, and change control need to be consistent across multiple agentic workflows. The governance value is not abstract modularity. It is the ability to manage NHI access as a set of independently controlled capabilities instead of a tangle of embedded function definitions.

Practical implication: Standardize tool integrations where you need repeatable lifecycle control, not just fast prototyping.

Threat narrative

Attacker objective: The attacker wants to turn one compromised agent application into a multi-tool execution path with broad credential reuse.

1. Entry occurs when an AI application with function calling is compromised and the attacker inherits the application's embedded tool credentials.
2. Escalation follows when those shared credentials permit multiple backend actions through the same process boundary.
3. Impact is broad because the attacker can use the agent's allowed tool set to query data, invoke APIs, or trigger downstream actions with little additional friction.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.

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

NHI Mgmt Group analysis

MCP creates an identity boundary, not just a developer convenience layer. The real shift is that tool access becomes a separately governed control plane instead of a hard-coded extension of the main application. That matters because NHI governance fails fastest when secrets, permissions, and execution all live in one process. Practitioners should treat protocol separation as a security architecture decision, not a coding preference.

Function calling scales poorly when agent privilege needs to be auditable. The more tools you embed in the application, the harder it becomes to answer who can do what, under which conditions, and with which credentials. That is exactly where IAM and PAM controls start to matter for non-human identities. Teams should assume application-level orchestration will accumulate access debt unless they deliberately split trust domains.

Ephemeral tool access still leaves trust assumptions behind. Short-lived execution reduces exposure time, but it does not solve the question of whether the agent should have the permission in the first place. MCP improves the mechanics of isolation, yet the governance problem remains one of scope, approval, and revocation. Practitioners should measure control quality by blast-radius reduction, not by integration elegance.

Named concept: identity blast radius. In agentic systems, the blast radius is the set of systems, data, and actions reachable through one non-human identity or tool boundary. MCP can shrink that radius by isolating servers, but only if permissions are narrowly scoped and reviewed as lifecycle controls. Teams should design every agent integration around the smallest defensible identity blast radius.

The market is moving toward reusable identity-aware tooling layers. The article reflects a broader shift away from one-off tool wiring and toward standardised control points for agent access. That trend validates NHI governance approaches that emphasise scoped permissions, server isolation, and lifecycle management. Practitioners should expect tool integration patterns to become more standard, while governance expectations become less forgiving.

From our research:

• Only 18% of MCP server deployments implement any form of access scoping for tool permissions, according to The State of MCP Server Security 2025.
• Only 52% of companies can track and audit the data their AI agents access, according to AI Agents: The New Attack Surface report.
• For a governance lens on this pattern, see OWASP NHI Top 10 and how scoped permissions map to agent risk reduction.

What this signals

Identity blast radius: as agent fleets grow, the programme risk is not just whether a tool works, but how far one compromised NHI can reach. With 96% of technology professionals identifying AI agents as a growing security threat, per AI Agents: The New Attack Surface report, teams should expect governance pressure to shift from experimentation to containment.

MCP-style isolation gives practitioners a better place to enforce access boundaries, but it does not remove the need for approval workflows, reviews, and revocation. The next control gap will be operational, not architectural: teams that cannot see tool permissions clearly will struggle to defend them during incident response or audit.

For organisations aligning agentic systems to external standards, the most relevant move is to map tool access to least-privilege and zero-trust principles rather than treating every integration as a bespoke exception. That is where protocol choice becomes a governance signal as much as a technical one.

For practitioners

• Map each agent tool to a distinct trust boundary Document which credentials, APIs, and data sources each tool can reach, then decide whether the boundary belongs in the application or in an isolated server. Keep the mapping tied to access review and revocation workflows so tool scope stays visible.
• Move sensitive capabilities behind separate servers Separate high-risk database, secrets, and administrative actions from the main agent application so one compromise does not expose every backend permission. Use server-level controls for least privilege and logging.
• Treat tool permissions as lifecycle controls Review who can grant, change, and revoke tool access for non-human identities, and align that process with joiner-mover-leaver style governance. The goal is to make agent permissions auditable from request to retirement.
• Limit shared credentials in agent orchestration code Keep secrets out of the orchestration layer wherever possible and prefer server-side credential isolation for tools that touch sensitive systems. Shared credentials increase the size of the compromise if the application is breached.

Key takeaways

• MCP changes the security boundary for AI tools by separating credentials and permissions from the main application process.
• Function calling is workable for small prototypes, but it concentrates trust and makes NHI governance harder as tool counts rise.
• Practitioners should judge agent integration patterns by blast radius, auditability, and revocation speed, not by implementation simplicity alone.

Key terms

• Model Context Protocol: An open protocol that lets AI clients connect to tools and data sources through a standard server interface. In practice, it separates model interaction from tool execution so access can be governed at the server boundary instead of inside application code.
• 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.
• Identity Blast Radius: The total set of systems, data, and actions reachable through one non-human identity or tool boundary. For agentic environments, it is a useful way to judge whether an integration is narrowly scoped or capable of causing broad downstream impact if compromised.
• Tool Permission Scoping: The practice of limiting what a non-human identity can do with each tool, including which data sources it can reach and which actions it can trigger. Strong scoping is a core control for agent governance because it reduces overreach, improves auditability, and supports revocation.

Deepen your knowledge

MCP versus function calling, identity isolation, and agent tool governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are designing controls for agentic tools or reviewing an existing integration model, it is worth exploring.

This post draws on content published by Descope: MCP vs. Function Calling: How They Differ and Which to Use. Read the original.