Spots 
A few months ago, I started messing around with Microsoft Agent Framework, and I found it to be very flexible for building AI agents. Like almost everyone, I built a working demo in a short time, but then I stopped and thought, "wait, what is this thing actually allowed to do?"
Most agent tutorials skip that question entirely. You get a smart chatbot that can search your database, send emails, maybe book a meeting, and the identity story is usually an afterthought. This is not how things work in production. You shouldn't implement an AI agent without stopping to ask who the agent is acting as, what it's allowed to see, or who's responsible when it does something wrong.
To answer these questions, I built a real example around it: an expense-approval agent for a fictional company, using Microsoft Agent Framework on the backend and Auth0 to handle every identity decision along the way. It turned into a four-part series published on the Auth0 blog, and here I want to explain why I think the whole thing is worth your time even if you skim the deep technical parts. What Could Go Wrong with the AI Agent?
The example app is simple on purpose: a manager chats with an agent, the agent pulls up expense reports, and eventually the agent can send emails and approve or reject expenses on the manager's behalf. It's built with Microsoft Agent Framework's AIAgent and tool-calling, wired into a Blazor Web App, and it uses Azure AI Foundry.
Building the AI agent is pretty straightforward and you can find plenty of tutorials on that. Actually, the interesting part of the series is what happens when you ask: what's stopping this agent from reading someone else's expense reports? Emailing the wrong person? Approving a $50,000 reimbursement because someone typed "looks good" in a chat window?
Turns out Auth0 has a specific answer to each of those, and they're not the same answer. Every capability I added to the agent turned out to need its own identity and authorization decision, with its own failure mode if you skip it. Part 1: Who Is This Agent Even Acting For?
Before the agent does anything, it needs to know who it's working for. That sounds obvious, but a lot of agent demos never actually establish this. The first post walks through wiring up Auth0 Universal Login on the Blazor app, so every action the agent takes is tied to a real, authenticated manager, not an anonymous session.
This is the part people skip because it's "just login," but it's the foundation everything else depends on. If you can't answer "who is this agent representing," none of the authorization questions later even make sense. And once you have that answer, every tool call the agent makes can carry that identity forward instead of acting as some generic service account. Part 2: What Is It Allowed to Retrieve?
Once the agent knows who's asking, the next problem shows up fast: it needs to search expense reports, and not every manager should see every report. This is where I added Retrieval-Augmented Generation (RAG) support, vector search over the expense data, and paired it with Auth0's Fine-Grained Authorization (FGA).
The detail I like most from this part: the filtering happens before the vector search runs, not after. Some RAG-plus-authorization setups fetch everything and filter the results, which means the LLM already saw the data it wasn't supposed to see. Doing the FGA check first, and only searching over the objects the user is actually allowed to read, means unauthorized data never enters the picture at all. Part 3: What Can It Do on My Behalf?
A few months ago, I started messing around with Microsoft Agent Framework, and I found it to be very flexible for building AI agents.