Microsoft Foundry with Managed Identity consuming a MCP Server protected by Microsoft Entra ID

[Talles Destefani de Souza Valiattti (TallesValiatti)]

Introduction

Hello everyone 👋

I recently published an article showing how to protect a custom Model Context Protocol (MCP) server built with .NET using Microsoft Entra ID, so that only one specific Microsoft Foundry project identity is allowed to call it. Microsoft Foundry is at the center of the scenario: the agent lives in the Foundry Agent Service, and the MCP Server is connected as a tool using the Project Managed Identity authentication mode, where Foundry itself obtains an app-only token and presents it on every call.

The demo server, Books.Mcp, exposes book CRUD tools. On the API side, the authorization policy checks that the incoming token is app-only (oid equals sub), that the tenant matches, and that the object id is exactly the Foundry project identity. Any other caller in the same tenant gets rejected. The article walks through the App Registration, the Application ID URI, the ASP.NET Core authentication and authorization wiring, the deployment to Azure App Service, and the end-to-end test in the Foundry sandbox.

The article is available here:

https://www.azurebrasil.cloud/blog/microsoft-foundry-com-managed-identity-consumindo-um-mcp-server-protegido-pelo-microsoft-entra-id/

The post is written in pt-BR, since it was aimed at my local community here in Brazil 🇧🇷, but it translates easily to en-US. It is meant for developers who need to expose sensitive MCP tools to a Foundry agent with strong, identity-based access control instead of shared secrets or open endpoints.

Features and Screenshots

Technical Details

• Language: C# (.NET 10)
• AI Platform: Microsoft Foundry
• Agent Runtime: Microsoft Foundry Agent Service
• Model: gpt-5.6-luna
• Identity: Microsoft Entra ID, Project Managed Identity authentication for MCP
• Protocol: Model Context Protocol (MCP), streamable HTTP transport, stateless
• Hosting: Azure App Service (ZIP deploy via Azure CLI)
• SDKs and Libraries:
  • Microsoft.Identity.Web
  • ASP.NET Core JWT Bearer authentication
  • MCP C# SDK
  • EF Core (In-Memory provider)

Challenges and Solutions

Challenges and Solutions

The hard part was not exposing the MCP tools, it was proving that a request really came from the Foundry project and from nowhere else. A valid token from the same tenant is not enough, so the policy validates three things together: that oid and sub are equal, which is what identifies an app-only token instead of a delegated user token; that tid matches the configured tenant; and that oid matches the Foundry project identity's object id. Only when all three hold does the /mcp endpoint accept the call.

I also had to decide between Project Managed Identity and OAuth identity passthrough. Passthrough is the right answer when the agent must act on behalf of the end user and inherit their permissions. Here the agent represents the application itself, so app-only tokens with an ACL-style check on the object id were the more direct path, and AllowWebApiToBeAuthorizedByACL let me skip app roles entirely for a single trusted caller. Restricting ValidAudiences to the client id and the api://<client-id> URI, and keeping /health anonymous while the MCP endpoint stays behind the policy, kept the whole thing simple to deploy and easy to reason about.

[Ritesh Srivastava (riteshksriv)]

I am not able to do this for a Hosted Agent. My Project User Assigned Managed identity has access to call the MCP server when I am trying to explicitly use the project UAMI from inside the Hosted Agent: Invalid clientId. It should match either the AgentIdentityId or AgentBlueprintId.