Azure Container Apps

Introduction: The Identity Problem with AI Agents AI agents are moving beyond simple prompt-and-response. They’re calling APIs, reading databases, writing to storage etc. Doing actions on real resources with real consequences. This raises a question every platform team eventually asks: whose identity should the agent use? Today, most agents authenticate to Azure services one of two ways: Delegated (on-behalf-of-user): The agent acts as the signed-in user. This can work for interactive scenarios, but it means the agent inherits all of the user’s permissions. Which far more than a narrowly-scoped tool call should need. It also falls apart for background or autonomous agents that run without a user session. App-only (managed identity or client credentials): The agent authenticates as the hosting application. This solves the “no user present” problem, but now every agent running on the same compute shares a single identity. You can’t distinguish which agent accessed which resource in your logs. You can’t give one agent read-only access to Cosmos DB while another gets read-write. The agent is the app, as far as Azure is concerned. Neither option gives you what you actually want: a discrete, auditable identity for the agent itself. One that’s separate from the user, separate from the hosting infrastructure, and scoped to exactly the permissions the agent needs. ...

In Microsoft Entra Agent ID, we use agent identity blueprints to create agent identities and request tokens using those agent identities. These agent identities represent AI Agents within your tenant, and is usually provisioned when we create a new AI Agent. In this post, we’ll go through an end-to-end example of creating an agent blueprint using Microsoft Graph PowerShell, then we’ll create an Agent Identity using a ASP.NET Web API that we’ll deploy to Azure Container Apps. ...

I run various Container Apps as part of my personal health project. I want this project to be as low maintenance as possible, so I decided to take a look at Azure SRE Agent to see how it could help me reduce the operational toil required to operate my side project. As I’m writing this blog post (8th January 2026), Azure SRE Agent is still in Preview. There’s no mechanism to provision SRE Agents using Bicep, or any IaC for that matter, and I’m expecting to see things break or not quite work as nicely as they should, so consider everything that I’m writing here experimental, and expect that features will change as time goes by. ...

A couple of months ago, I wrote a blog post on how you can create Model Context Protocol (MCP) servers using C#. Using a basic API, I was able to create a MCP server that allowed me to call Australian Football League (AFL) data and supply that as context to LLMs so I can ask it question about AFL results, teams, stats etc. using that API. That blog post talked about how we can use MCP servers that run locally on our machines using stdio transport. In this article, I’ll talk about how we can use Server-Sent Events (SSE) transport to build remote MCP servers that we can host on Azure Container Apps. ...

A couple of years back, I built a Fitbit API token refresh service using Azure Functions. The purpose of that function was to refresh an access token that I can use to make calls to the Fitbit API and extract my own data using Azure Functions. This was before Azure Container Apps even existed, so Azure Functions was really the only option. WebJobs was an alternative (after all, Functions are essentially built on top of Azure WebJobs), but that wasn’t attractive since this was just an hobby project, and I didn’t want to break the bank. The problem with Azure Functions is that you’re restricted with the programming model. It’s fine if you just need the plumbing done for you for simple integrations, but if you want the flexibility, it’s not great. ...