Build Secure AI Agents with Microsoft Agent Framework and Auth0

A developer built an expense-approval AI agent using Microsoft Agent Framework with Auth0 handling identity and authorization, wiring Auth0 Universal Login into a Blazor Web App so every agent action is tied to an authenticated manager rather than a generic service account. The example pairs retrieval-augmented generation over expense data with Auth0 Fine-Grained Authorization, applying the permission check before the vector search runs so unauthorized records never reach the model. The work is documented in a four-part series on the Auth0 blog.

A few months ago, I started messing around with Microsoft Agent Framework https://learn.microsoft.com/agent-framework/overview/ , 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 https://learn.microsoft.com/agent-framework/overview/ on the backend and Auth0 https://auth0.com/ 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. 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 https://azure.microsoft.com/en-us/products/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. 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 https://auth0.com/blog/building-secure-ai-agents-with-microsoft-agent-framework-and-auth0-part-1-user-authentication 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. Read Part 1: User Authentication https://auth0.com/blog/building-secure-ai-agents-with-microsoft-agent-framework-and-auth0-part-1-user-authentication 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 https://en.wikipedia.org/wiki/Retrieval-augmented generation support, vector search over the expense data, and paired it with Auth0's Fine-Grained Authorization FGA https://auth0.com/fine-grained-authorization . 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. Retrieval is one thing. Taking action is a different level of risk. Part 3 gives the agent the ability to send email through Gmail https://auth0.com/blog/building-secure-ai-agents-microsoft-agent-framework-auth0-part-3-sending-email-with-token-vault/ , on the manager's behalf, to notify people about expense decisions. The obvious bad approach is storing a Gmail token somewhere the agent's code can grab it. Instead, this post uses Auth0's Token Vault https://auth0.com/docs/secure/call-apis-on-users-behalf/token-vault , so the agent can trigger a "send this email" action without ever holding, seeing, or touching the underlying Gmail token. The token stays completely out of the LLM's reach, and the code is written so the model literally never has a path to it, not even by accident. If a token ever ends up in a prompt, a log, or a variable the LLM can inspect, it doesn't matter how careful your prompt engineering is. I found this genuinely reassuring to build: the agent gets a capability, not a credential https://auth0.com/blog/want-ai-agents-that-don-t-spill-secrets-don-t-give-them-secrets . Read Part 3: Sending Email with Token Vault https://auth0.com/blog/building-secure-ai-agents-microsoft-agent-framework-auth0-part-3-sending-email-with-token-vault This is the part that ties the whole series together. Retrieval and email are one thing. Actually approving an expense report is a decision with real consequences, and " the user typed the word 'approved' in the chat " is not a security control. It's a string match. So Part 4 replaces that with CIBA https://auth0.com/blog/building-secure-ai-agents-microsoft-agent-framework-auth0-part-4-human-in-the-loop-approval/ , Client-Initiated Backchannel Authentication, which sends an actual push notification to the manager's phone asking them to approve or deny, with a binding message that says exactly what they're approving. Not a vague " an app requires access " prompt, and not an automatic, superficial approval typed into a chat window. If you're going to let an agent trigger something with financial consequences, the approval step deserves the same rigor as any other authentication or authorization event, not less. Read Part 4: Human-in-the-Loop Approval https://auth0.com/blog/building-secure-ai-agents-microsoft-agent-framework-auth0-part-4-human-in-the-loop-approval/ None of this is really about expense approvals. It's about the fact that agents are starting to do real things on people's behalf, and most of the AI agent content out there treats identity and security as an afterthought, something to be added at a later stage, just before release. It doesn't work that way. Every capability you give an agent, search, email, approval, comes with its own authorization question, and Auth0 turned out to have a purpose-built answer for each one rather than one generic "auth" checkbox. If you're building agents with Microsoft Agent Framework, or really any agent framework, I'd start with Part 1 and work through them in order. Each post builds on the last one, and by the end you'll have a working agent that can retrieve, act, and get approval, all without ever handing the LLM more trust than it actually needs. To recap, here are the links to the blog post series, Building Secure AI Agents with Microsoft Agent Framework and Auth0 : Enjoy your reading and share your feedback