Function Calling, MCP, and the Authorization Gap

AI models don't execute code. They can't query Salesforce, file a ServiceNow ticket, or open a database connection. What they can do is ask your application to do those things, using a structured format that looks like an API call but isn't one. This mechanism is called function calling, and it's the plumbing underneath every "AI agent" capability your buyers are asking about. MCP standardized that plumbing into a protocol. But MCP standardized the pipes and left out the valves. Authorization, the part you've spent your career on, has no standard home in the protocol. That gap is now producing real, exploitable failures in production.

What function calling actually is

The mechanical sequence: you define a set of tools the model can request, each described with a name, a purpose, and a schema for its inputs. You send your prompt to the model along with those definitions. The model evaluates the prompt, decides a tool would help, and returns a structured tool_use block: a JSON object that says "I'd like you to call this function with these parameters." Your application code receives that block, decides whether to actually execute it, runs the function, and sends the result back. The model incorporates the result into its response.

The model is the requester. Your application is the executor. The model never touches the tool directly.

This matters because every function call passes through a layer you control. You can validate inputs, enforce permissions, log the request, or refuse it entirely. The model proposes. Your code disposes. That control point is the whole game, and it's the thing that gets complicated when you scale beyond a handful of tools.

• Function calling: The model emits a structured request for your application to execute an action; your code runs it, returns the result, and the model uses it to continue its response.

From function calls to a protocol

Function calling works fine when one model talks to one application with a handful of tools. It breaks when you need dozens of tools across multiple systems, each with its own connection logic, authentication requirements, and data formats. Every integration becomes bespoke.

Anthropic released the Model Context Protocol in November 2024 to solve this. MCP defines a standard way for AI models to discover and interact with external tools and data sources. Instead of writing custom integration code for every tool, you stand up an MCP server that exposes your system's capabilities in a standard format. Any MCP-compatible client can discover and use them.

The adoption was fast. OpenAI adopted MCP in March 2025. Google DeepMind followed in April. By December 2025, Anthropic donated MCP to the Agentic AI Foundation under the Linux Foundation. Co-founders include Anthropic, Block, and OpenAI. Platinum members include Google, Microsoft, AWS, and Cloudflare. Three months after launching, the AAIF had surpassed the Cloud Native Computing Foundation in membership size. The April 2026 Dev Summit in New York drew roughly 1,200 attendees. Enterprise tools now ship MCP servers the way SaaS once shipped REST APIs.

That's the momentum side.

• MCP: A protocol that standardizes how AI models discover and interact with external tools, now governed by the Linux Foundation's AAIF with backing from every major cloud provider.

The authorization gap

The November 2025 MCP spec made real progress on authentication. Remote MCP servers must implement OAuth 2.1 with PKCE. The spec mandates RFC 8707 Resource Indicators, which bind tokens to specific MCP servers so a token issued for Server A can't be replayed against Server B. Token passthrough, where an MCP server receives a user's token and forwards it directly to a downstream API rather than obtaining its own separate token for that service, is explicitly forbidden. The spec is categorical: MCP servers must not accept or transit any tokens other than ones issued for their own resources.

Your OAuth intuition is useful here. Audience binding, PKCE, token scoping. Familiar mechanisms doing familiar work. The spec's authentication requirements read like a competent OAuth implementation checklist.

This is where that intuition starts to mislead you. The spec mandates connection security but says nothing about enterprise authorization policy. It covers whether this client can connect to this server. The harder question, "is this agent allowed to read that customer record, under whose delegated authority, with what scope, and should it still be allowed to at 2 AM on a Saturday?", falls outside the spec entirely. The spec creates a socket where controls can be applied. The controls themselves are someone else's problem.

And the spec that does exist isn't the spec most people are running. Stack Overflow's engineering team noted in January 2026 that the older June 2025 spec version remains more widely deployed than the November hardening. The spec improved. The installed base hasn't caught up.

• Authorization gap: MCP's spec mandates authentication (who is connecting) but leaves authorization (what they're allowed to do) to the implementer, with no standard mechanism for enterprise policy enforcement.

The security surface is accumulating

The gap isn't theoretical. Four categories of real-world failure show the pattern.

Tool poisoning. This one has no clean IDAM analog, which is why it deserves attention. In MCP, every tool a server exposes comes with a description that tells the model what the tool does and when to use it. A malicious or compromised MCP server can embed hidden instructions in those descriptions that manipulate the model's behavior: exfiltrating data through subsequent tool calls, overriding user instructions, or steering the agent toward actions the user never requested. The attack surface is the tool definition itself. Your buyer's security team is used to thinking about who can access a system. Tool poisoning means they also need to think about whether the system's own self-description is trustworthy.

The mcp-remote CVE. In July 2025, JFrog's security research team disclosed CVE-2025-6514 (CVSS 9.6) in mcp-remote, a widely used proxy that lets clients like Claude Desktop connect to remote MCP servers. The attack: a malicious MCP server responds with a crafted OAuth authorization endpoint URL. The proxy passes it unsanitized into an OS command to launch a browser. On Windows, that's full shell execution. The package had been downloaded over 437,000 times at disclosure, according to Docker's security analysis. The vulnerability was patched. The architectural assumption that enabled it, that agents must trust external services to tell them how to authenticate, remains embedded in how agent authorization is being built.

The Asana cross-tenant leak. In June 2025, Asana's MCP integration leaked customer data across organizations. A tenant isolation flaw allowed AI requests from one organization to receive cached results from another. Asana pulled the integration offline from June 5 through 17. Roughly 1,000 customers were affected. (The Register and BleepingComputer provide the most detailed public accounts; Asana has not published a post-mortem.) The root cause was a confused deputy bug: the MCP server failed to re-verify tenant context for cached responses. Audience-bound tokens handle the wrong-server problem. The wrong-tenant problem is a different animal entirely, and that distinction matters in every multi-tenant environment your buyers operate.

The architectural STDIO vulnerability. In April 2026, OX Security disclosed a vulnerability in MCP's official SDKs across every supported language: Python, TypeScript, Java, and Rust. Any process command passed to the MCP STDIO interface can execute on the host system regardless of whether it initializes a valid MCP server. Researchers estimated up to 200,000 vulnerable instances. Anthropic's response, per OX Security's account of private communication with Anthropic (not a public Anthropic statement): the behavior is "expected," and input sanitization is the developer's responsibility. Anthropic declined to modify the protocol's architecture. Fourteen CVEs have been assigned to vulnerabilities stemming from the same root cause.

That last point is worth sitting with. The protocol maintainer was told about an architectural vulnerability affecting 200,000 servers and responded that the behavior is by design. Whether you find that reasonable depends on whether you think protocol designers or application developers should own the security boundary. Reasonable people disagree. American Banker reported, in a piece focused on regulatory implications, that under 2023 bank regulatory guidance on third-party risk, banks using MCP own the risk regardless of what Anthropic fixes.

• Security surface: Real-world incidents demonstrate that MCP's authorization gap produces predictable, exploitable failures across four distinct attack categories: tool poisoning, OAuth trust exploitation, tenant isolation failure, and architectural execution flaws.

Will MCP persist?

Honest answer: nobody knows, and the people who sound most certain tend to have the most invested in a particular outcome.

MCP has serious institutional weight behind it. Linux Foundation governance. Every major cloud provider as a member. Ninety-seven new AAIF members in February 2026 alone, according to the AAIF Governing Board Chair's Dev Summit keynote. Enterprise tools shipping MCP servers as a default integration surface. Protocols with this much backing don't usually vanish. They harden.

But MCP's security surface is structural, a consequence of standardizing connection without standardizing authorization. The STDIO execution model that OX Security flagged is a design choice Anthropic has explicitly defended. Integration protocols have died under their own security weight before. CORBA had institutional backing too.

MCP probably survives as a connection-layer standard while authorization gets solved by a different layer, potentially by identity providers who already know how to do policy enforcement at scale. The spec stabilizes the plumbing. Someone else supplies the valves.

• Durability: MCP has massive institutional momentum but unresolved architectural security gaps. The most probable outcome is persistence as a connection standard, with authorization solved by a separate layer.

The layers keep forming

Even as MCP governance stabilizes, the layers around it keep forming. Anthropic released Agent Skills as an open standard in December 2025, now adopted by 26+ platforms including OpenAI Codex, Gemini CLI, and GitHub Copilot. Skills are reusable instruction packages that teach an agent how to handle specific task types. They interact with MCP in a specific way: skills teach an agent how to do things; MCP gives it access to things.

The practical pressure driving this: a typical multi-server MCP setup (GitHub, Slack, Sentry, Grafana, Splunk) can consume roughly 55,000 tokens in tool definitions alone, according to Anthropic's API documentation. That's context window consumed before the model does any actual work. MCP's success created a resource consumption problem that required yet another architectural layer to solve. Anthropic's Tool Search Tool, which discovers tools on demand instead of loading all definitions upfront, didn't exist six months ago. Neither did Skills. Neither did the AAIF. The layers keep forming.

Any buyer building their AI strategy around a specific protocol version is building on ground that hasn't set.

When a CAIO asks about MCP, the productive conversation centers on how they're managing the authorization layer that MCP leaves open.

Your IDAM background equips you to help with that conversation. The unsolved problem in agentic AI is the problem you've been working on for years: who is allowed to do what, under whose authority, and how do you enforce it when the requester is a model emitting JSON at machine speed instead of a human clicking through a browser.

• Rate of change: Agent Skills and Tool Search Tool show that architectural layers around MCP are still forming rapidly. Buyers need an authorization strategy that outlasts any single protocol version.