Rbac

How an AI agent reaches Microsoft Graph as the signed-in user through MCP — why token passthrough fails, and how on-behalf-of, Conditional Access, and RBAC secure the chain.

The first design decision for any Azure AI agent is which identity it uses. A decision matrix across managed identity, Entra Agent ID, on-behalf-of, and service principals.

The governance case for keyless Azure: why shared keys are a liability, how managed identity plus RBAC fixes it, and how security, network, and platform teams enforce it.

Revised, split, and expanded — The two halves of this article are now separate chapters in the MAF v1: Python and .NET series: the auth + hardening half is covered by MAF v1 — 20c production hardening (with the password reset, refresh-token rotation, and graceful secret rotation that the original missed), and the deployment half is covered by MAF v1 — 25 deployment (with the .NET twin Dockerfile and a dev.sh that polls instead of sleeping). The architecture below is still the canonical reference for the combined story.

Introduction # Static role checks ([Authorize(Roles = "Admin")]) fall apart the first time someone asks you to add a permission without a redeploy. Once roles and permissions have to change at runtime, hard-coded role attributes become a liability. The Contact Management Application takes a different route: a dynamic policy provider that builds authorization policies from the database at request time, covering both the backend API and the Angular frontend, wired into JWT authentication without breaking the separation of concerns Clean Architecture expects.