Latest Securing Azure Apim Mcp Servers In Production 2025

Posted on Nov 25

• Originally published at itsrene.nl

In Part 1, I covered the good, bad, and ugly of Azure APIM MCP. Now let's talk about the security gaps you need to address before going to production.

Here's the reality: As a preview feature, Azure APIM MCP has permissive defaults that work great for prototyping but need hardening for production. You'll need to add security policies manually—Microsoft is actively working on better defaults, but let's not wait. Here's how to lock it down today.

Let's break down what's exposed by default and the patterns to secure it.

Let's start with the most obvious one. The /tools/list endpoint—used for tool discovery—doesn't enforce subscription key validation by default.

Anyone can enumerate your available tools without credentials:

This is information disclosure—tool names and descriptions can reveal business logic, which you'll want to lock down for production environments.

Add subscription key validation to your MCP server policy:

Here's the catch: APIM base policies might strip the Ocp-Apim-Subscription-Key header during policy processing, depending on your base policy configuration. This prevents inbound sensitive data from leaking to downstream services. But your backend APIs need that key for their own validation.

This is different from standard APIM patterns. Normally, APIM validates the request, strips sensitive headers, and calls the backend. Done. With MCP tool calls, the flow is different:

Source: Dev.to