New blog articles in Microsoft Community Hub

General Availability of the MySQL Flexible Server Quota Management Self-Service Experience

karlaescobar — Thu, 28 May 2026 05:58:27 GMT

What’s New?

The updated experience introduces a dedicated Azure Database for MySQL Flexible Server Quotas blade in the Azure portal, offering a streamlined and intuitive interface to:

View current usage and limits across the various SKU families and regions
Request quota increases tailored to your MySQL Flexible Server deployment needs

This new experience empowers developers, DBAs, and IT admins to proactively manage resources, avoid deployment failures, and optimize database performance — all without needing to file a support ticket for most scenarios.

Benefits at a Glance

Benefit	Description
Self-Service	Request quota increases directly from the Azure portal without filing a support ticket for most scenarios.
Real-Time Visibility	View current vCore usage and limits across all SKU families and regions at a glance.
Automatic Approval	Many quota increase requests are automatically approved within minutes — no waiting for manual review.
Inline Adjustments	Request increases directly from the quota table — no need to navigate to a separate page or form.
Proactive Management	Identify SKU families nearing their limits before they cause deployment failures.
Fraud and UPA as Safeguard	Requests that exceed limits or indicate risk are automatically escalated for review, not blindly approved.

How It Works

Each MySQL Flexible Server compute tier is represented as a separate SKU family. If you intend to scale up or down within a specific tier, ensure you have sufficient quota for each applicable SKU family in that tier.
You can filter by region, subscription, provider, or usage. Note that your portal will show "Azure Database for MySQL Flexible Server" for the Provider name.
You can also group the results by usage, quota (SKU family), or location (region).
Current usage is represented as vCores. This allows you to quickly identify which SKU families are nearing their quota limits.
Adjustments can be made inline: there is no need to visit another page. This is covered in detail in the next section.

Step-by-Step: Viewing Usage and Requesting a Quota Increase

Step 1: Navigate to the Quotas Blade

Sign in to the Azure portal at https://portal.azure.com.
In the search bar at the top, type "Quotas".
Select "Quotas" from the search results under Services.

Alternative navigation: You can also navigate via Subscriptions > select your subscription > Usage + quotas in the left-hand menu.

Step 2: Select the Azure Database for MySQL Provider

On the Quotas page, locate and select "Azure Database for MySQL" from the list of resource providers.

Use the Subscription filter at the top to select the subscription you want to review and apply additional filters for regions as needed.

Step 3: Review Your Quota Usage and Limits

The quota details page displays a table with the following information:
- Quota Name — The SKU family name (e.g., "Burstable BS Series vCores", "General Purpose DS Series vCores", "Business Critical DS Series vCores").
- Region — The Azure region where the quota applies.
- Current Usage — The number of vCores currently in use.
- Limit — The maximum quota limit for that SKU family.
- Usage Bar — A visual indicator showing how much of the quota is consumed.
Review the usage bars to identify quotas that are nearing their limits. Use the search box to find specific SKU families quickly.

Step 4: Request a Quota Increase

Clicking the pen icon next to a quota opens a fly-out window to capture the quota request.

Step 5: Enter the New Limit

The quota type (MySQL Flexible Server SKU family) is already populated, along with current usage. Note that your request is not incremental: you must specify the new limit that you wish to see reflected in the portal.
For example, to request an additional 10 vCores for Burstable Series (BS family), and your current limit is 35, you would enter 45 as the new limit.
- Enter the desired new limit in the "New limit" field.
- The portal will indicate whether the request can be automatically approved or if it requires manual review.

Step 6: Submit and Monitor the Request

Click Submit to send the request for automatic processing.
Immediately upon submitting a quota request, you will see a processing dialog:

If the quota request can be automatically fulfilled, then no support request is needed. You should receive confirmation within a few minutes of submission:

If the request cannot be automatically fulfilled, then you will be given the option to file a support request with the same information:

Step 7: Verify the Quota Increase

Navigate back to the Quotas blade and select the Azure Database for MySQL provider.
Confirm that the Limit column now reflects the new, increased value.
If you forget the region or SKU family that was requested, you can reference them in your notifications pane.

Filing a Support Ticket

When creating a support ticket, you will need to repopulate the Region and MySQL Flexible Server SKU family details; the new limit has already been populated for you.
If you choose to create a support ticket, you will interact with the capacity management team for that region. This is a 24x7 service, so requests may be created at any time. Once you have filed the support request, you can track its status via the Help + support dashboard.
If your deployment requires quota for many subscriptions, then we recommend filing a support ticket with issue type "Service and subscription limits (quotas)" and quota type “Quota increase”:

Known Limitations

Closing the quota request fly-out window will stop meaningful notifications for that request. You can still view the outcome of your quota requests by checking actual quota, but if you want to rely on notifications for alerts, we recommend leaving the quota request window open for the few minutes that it is processing.

Feedback

If you notice any aspect of the experience that does not work as expected or you have feedback on how to make it better, please share your thoughts! Your feedback is critical as we work toward an improved quota management self-service experience.

Access Your SRE Agent from Any IDE, Terminal, or AI Assistant

dbandaru — Thu, 28 May 2026 01:28:47 GMT

Your team already uses an SRE Agent — it monitors your services, learns your architecture, and handles operational tasks. Now developers can talk to that agent in natural language from the interfaces they already use every day: their editor, their terminal, their AI assistant. Check what the agent knows, ask it a question, search its memories, wire it into a workflow — all without leaving the tool where they're already writing code.

What we're announcing

Azure SRE Agent tools are now shipping in the Azure MCP Server. The azure/mcp package includes a full set of SRE Agent tools that let you manage and operate your SRE Agents from any MCP-compatible client — GitHub Copilot CLI, VS Code Copilot, Cursor, Claude Desktop, or any agent framework that speaks MCP. No separate CLI. No portal tab. No custom integration code. Your SRE Agent becomes accessible wherever you already think and work.

This is about meeting developers where they are. Your SRE Agent has deep context about your systems — incident history, architecture knowledge, operational patterns. Now that expertise is accessible from VS Code, from your terminal, from any MCP-compatible AI assistant. Just type a question in natural language and your agent responds, right inside the workflow you're already in. Your SRE Agent stops being a destination you visit and becomes part of how your team works every day.

This post walks through what you can do and how to get it running, using GitHub Copilot CLI as the example. The same setup works in VS Code Copilot, Claude Desktop, Cursor, and any other MCP-compatible client.

What this unlocks

Once the Azure MCP Server is connected to Copilot CLI, you can talk to your SRE Agent infrastructure the same way you'd ask a colleague:

"List my SRE agents in subscription <sub-id>"
"Create a Kusto connector named prod-logs on agent myagent pointing at cluster https://help.kusto.windows.net, database Samples"
"Search memories on agent myagent for 'deployment failures'"
"Pause the nightly scheduled task on agent myagent"
"Generate an architecture plan for a multi-region web app"

The full capability set breaks down into seven areas:

Manage SRE Agents. List, get, and create Microsoft.App/agents resources in your subscription. Discover which tools a given agent has access to. Resource groups are resolved automatically via Resource Graph.
Configure connectors. Create and manage Kusto connectors, MCP connectors (both http and stdio transports), Azure Monitor connectors, and more. Connectors go through ARM and show up in the Azure portal alongside anything you created there. MCP connectors default to system-assigned managed identity.
Run and inspect threads. Create and list conversation threads, get thread details, send messages, and manage hooks on a thread. This is how you talk to the agent programmatically or inspect what it's doing mid-run.
Schedule recurring work. Create, list, pause, resume, and delete scheduled tasks.
Manage incidents. List active incidents and run incident setup commands for PagerDuty and ServiceNow.
Knowledge and prompts. Manage common prompts like safety rules and standing instructions. Search, upload, and delete memories. List and delete skills. Fetch agent docs by topic.
Author workflows. Generate architecture plans from requirements. Generate, validate, and apply YAML workflows.

Safety

Giving an AI assistant broad management access to your SRE Agents means it's worth knowing what guardrails are in place:

Destructive operations require --confirm true. Any delete (connectors, hooks, memories, skills, scheduled tasks, sub-agents) refuses to run without the explicit flag. There's no way to accidentally tear something down through an autocompleted command.
Secrets are stripped before they reach your client. Bearer tokens, API keys, passwords, connection strings, and Authorization headers are redacted from connector and tool responses.
Error messages are sanitized. Upstream error bodies are scrubbed for secrets and truncated before surfacing, so credentials don't leak through error text.
Data-plane calls are pinned to *.azuresre.ai. HTTPS is required; the host suffix is enforced to prevent SSRF. http:// is only allowed for localhost.
Third-party hosts are pinned. ServiceNow connectors are restricted to .service-now.com and .servicenowservices.com. PagerDuty subdomains must be valid DNS labels.
MCP connector secrets must be env-referenced. Header and environment values for MCP connectors must use ${env:NAME} syntax — literal secrets are rejected so they never enter LLM context.

Prerequisites

Before connecting anything, make sure you have the following installed and authenticated.

Node.js LTS

node --version

If you're not on a current LTS, update via nodejs.org or your package manager. The Azure MCP Server is tested against the active Node.js LTS releases.

Azure CLI

The MCP server uses DefaultAzureCredential, which picks up credentials from az login. You need the Azure CLI installed and signed in.

Install: https://learn.microsoft.com/cli/azure/install-azure-cli

az --version
az login

If you work across multiple tenants:

az login --tenant <tenant-id>

If you have multiple subscriptions, set a default:

az account set --subscription <subscription-id>

GitHub Copilot CLI

Install Copilot CLI following the official instructions: https://docs.github.com/en/copilot/how-tos/use-copilot-agents/use-copilot-cli

Once installed, launch it and authenticate with your GitHub account.

Connect the Azure MCP Server to Copilot CLI

The Azure MCP Server runs as an npm package (azure/mcp) and launches via npx. The easiest way to add it is interactively from within Copilot CLI:

/mcp add

Follow the prompts: name it azure, set the command to npx, and args to -y azure/mcp@latest server start.

Or add it manually to your MCP config file (~/.copilot/mcp.json or .copilot/mcp.json in your repo):

{
  "mcpServers": {
    "azure": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "@azure/mcp@latest", "server", "start"]
    }
  }
}

Restart Copilot CLI after saving. On the next launch, npx fetches azure/mcp and starts the server automatically.

If you'd rather install globally:

npm install -g @azure/mcp
azmcp server start

Keeping it up to date

@latest means npx pulls the newest version on each launch, but npx caches aggressively. If you upgrade and the old version is still running:

npx clear-npx-cache
# or:
rm -rf ~/.npm/_npx

Then restart Copilot CLI. For environments where you want version stability, pin an exact version instead:

"args": ["-y", "@azure/mcp@0.x.y", "server", "start"]

Bump the version string when you're ready to upgrade.

Set up access to your SRE Agents

The MCP server doesn't pin to a specific agent. It discovers agents dynamically from your subscription and you target one per command. Two steps to get access working.

Assign RBAC

You need two roles on the Microsoft.App/agents resource (or at the resource group or subscription level):

Role	What it covers
Reader	Control-plane: list and get agents and connectors via ARM
SRE Agent Administrator	Data-plane: threads, memories, scheduled tasks, prompts, and everything on the agent's own endpoint

az role assignment create \
  --assignee <your-upn-or-objectid> \
  --role "Reader" \
  --scope /subscriptions/<sub>/resourceGroups/<rg>/providers/Microsoft.App/agents/<agentName>

az role assignment create \
  --assignee <your-upn-or-objectid> \
  --role "SRE Agent Administrator" \
  --scope /subscriptions/<sub>/resourceGroups/<rg>/providers/Microsoft.App/agents/<agentName>

On Windows PowerShell, use a single line or backtick continuations instead of \.

Find your agents

From Copilot CLI, ask:

"List my SRE agents in subscription <sub-id>"

This returns each agent's name, resource group, and endpoint. Once you have that, you're ready to work.

How the calls work under the hood

Two distinct layers, worth knowing which is which.

Control-plane (agents, connectors): goes through Azure Resource Manager at Microsoft.App/agents, API version 2025-05-01-preview. Anything you create or modify shows up in the Azure portal.
Data-plane (threads, memories, scheduled tasks, incidents, prompts, skills, hooks, docs, workflows): goes through the agent's own endpoint at https://<name>--<hash>.<region>.azuresre.ai.

The server handles the SRE Agent token audience automatically. You don't need to manage separate credentials for the data plane. Your az login session covers both.

When things go wrong

Symptom	What's happening	Fix
401/403 on data-plane calls	Missing SRE Agent Administrator role	Assign the role at the agent scope
403 on ARM calls	Missing Reader role	Assign Reader at subscription, RG, or agent scope
"No agent endpoint"	Agent not fully provisioned	Check `provisioningState` in the portal
`sreagent_*` tools not showing up	`npx` cache is stale	`npx clear-npx-cache`, restart Copilot CLI
Wrong tenant errors	Credentials from a different tenant	`az login --tenant <id>`, restart Copilot CLI

Verify it's working

Ask Copilot CLI: "List my Azure subscriptions" or "List my SRE agents." If sreagent_* tools appear in the tool list and return results, you're connected and on a version that includes this release.

Get started with Azure SRE Agent

If you don't have an SRE Agent yet, you can create one in minutes from the Azure portal or through the CLI. Connect it to your code, your logs, and your incident sources — and it starts building expertise from day one. Once you've added the Azure MCP Server to your editor, your agent is one sentence away in every session.

Resources

SRE Agent documentation — https://aka.ms/sreagent/newdocs
SRE Agent overview — https://aka.ms/sreagent/newdocsoverview
Azure MCP Server — https://aka.ms/azmcp
Azure MCP Server get-started — https://learn.microsoft.com/azure/developer/azure-mcp-server/get-started
Deep Context blog — https://aka.ms/sreagent/blogs/deepcontextblog

Windows 365 for Agents: run AI agents in Cloud PCs across real applications

JulieHersum — Thu, 28 May 2026 01:04:03 GMT

Copilot agents have been talking the talk—summarizing information, drafting content, and answering questions. But soon they’ll be walking the walk—executing workflows across systems in policy-controlled Cloud PCs.

With Windows 365 for Agents (now in public preview), you can run AI agents in a secure environment and use natural language to direct them to work across software and complete tasks, such as processing invoices or updating CRM data.

What’s changing?

It may sound like a small shift, but Windows 365 for Agents introduces a fundamentally different runtime model.

For the first time, you’ll be able to automate workflows that live outside APIs across real applications—including legacy and UI-based systems—without giving up enterprise security or control.

Much of today’s work still lives in browsers, desktop apps, and legacy systems—environments that assume intentional, human behavior. But agents behave differently:

Humans operate intermittently and with judgment
Agents can operate continuously and at scale

Agents depend on IT-defined boundaries, such as identity, policy, access, and monitoring, to keep execution aligned with intended workflows.

Without boundaries, agents can:

Access unintended systems
Act beyond their intended scope
Amplify small mistakes across workflows

Agents need a dedicated execution space designed for autonomous activity but governed by humans by default.

Windows 365 for Agents introduces the right execution environment

Windows 365 for Agents provides a dedicated Cloud PC environment that lets you define and control agents in various ways:

Independently and continuously, or on demand
Under your existing identity, policy, and management controls, such as Microsoft Entra ID and Intune
As repeatable, multi-step workflows across real applications, including legacy and UI-based systems, within the boundaries you set

Running agents in this controlled environment helps isolate risk and enforce security boundaries so act autonomously while remaining fully governed by your policies and without negatively impacting production systems.

Get started with Windows 365 for Agents

Interested in how this works and what Windows 365 for Agents unlocks for your environment? Read full blog, Windows 365 for Agents: run AI agents on secure cloud PCs, to learn more.

Microsoft Security Community Spotlight: Marcel Graewer

RenWoods — Wed, 27 May 2026 19:17:27 GMT

Globally, Marcel shares practical detection engineering insights on Microsoft Sentinel and Microsoft Defender XDR through forums and blog posts. Locally, he represents his employer in the IT-Security group of the Microsoft Business User Forum, where German companies using Microsoft technologies exchange real-world experience and expertise.

The work Marcel values most is helping people enter the IT field. In Germany, "Fachinformatiker" is a recognized IT profession learned through a multi-year apprenticeship, and he is proud to have trained apprentices. He also serves as an examiner for the IHK (the German Chamber of Industry and Commerce), evaluating the final exams of these IT apprentices.

This commitment also led him to support younger learners by teaching school cybersecurity classes and participating in Girls’ Day, where he introduced female students to the field. “I do this because most people don’t get an honest view of security work until much later in their education—if they see it at all. Showing someone early that this field is creative, varied, and genuinely interesting can change their path. Being part of that, even for a few people, means more to me than anything that fits neatly on a CV.”

Let’s hear more from Marcel about his Microsoft Security Community and product paths.

All responses to questions are direct quotes from Marcel.

What do you find most rewarding about being a member of the Microsoft Security Community?

The most rewarding part for me is how practical the exchange is. Microsoft security tooling moves fast - Microsoft Sentinel, Microsoft Defender XDR and Microsoft Security Copilot all change month to month- and no single person keeps up with all of it alone. The community is where that gap gets closed. When I read how someone else tuned a detection in their environment, or when someone responds to something I posted with a problem I hadn't considered, my own work gets better. It's a feedback loop you don't get from documentation. The other part I value is that it works in both directions: I started as a reader, learning from people more experienced than me, and now I'm at a point where I can give some of that back. Watching that shift happen has been genuinely motivating.

How long have you been working with Microsoft Security Products?

Over ten years! My way into Microsoft security ran through infrastructure rather than security itself. I started out administering Active Directory and VMware environments, the on-premises world, and that is where I first understood identity, endpoints and the quiet attack surface they create. At the time, security was something layered on top of infrastructure. What changed everything was the shift to the cloud.

As the environments I worked in moved into Microsoft Azure and Microsoft 365, the old separation between "running things" and "securing things" stopped making sense. In a cloud-first world, the identity is the perimeter, the sign-in log is the crime scene, and the telemetry that used to be scattered across servers suddenly lives in one place you could actually query. That was the moment Microsoft's security stack became less of a product set and more of a working environment for me.

As I moved from running infrastructure into roles centered on defending it, first leading IT infrastructure and security as a team lead, then as an IT Security Expert, and now as IT Security Manager focused on architecture and incident response in an Azure and M365 environment, Sentinel and Defender XDR went from tools I knew of to tools I work in every day. The infrastructure background turned out to be an advantage rather than a detour. Detection engineering makes far more sense once you have run the Active Directory and the endpoints that generate the very signals you are now writing detections against, and cloud security makes far more sense once you have felt the limits of the on-premises model it replaced. The part that keeps me engaged is that none of this stands still. The cloud security landscape changes constantly, the work is never quite finished, and that is exactly what I like about it.

What Microsoft Security features or products have provided the most impact?

The single biggest impact for me comes from Microsoft Sentinel as a cloud-native SIEM and SOAR platform. The move away from a self-hosted SIEM matters more than it first appears. A traditional SIEM is itself a piece of infrastructure that has to be sized, hosted, patched, and scaled, and that effort constantly competes with the actual security work. Microsoft Sentinel removes that layer. There is no platform estate to keep alive and no capacity planning for the SIEM itself, which frees attention for what actually matters: getting the right telemetry in and getting detection and response right.

What I value most is how naturally Sentinel fits into modern, cloud-first environments. When the landscape you are protecting already lives in Azure and Microsoft 365, a security platform that lives in the same place removes an entire class of integration friction. The other strength is the breadth of data onboarding. With a traditional SIEM, connecting a new log source was often a small project of its own, with connectors to build and parsers to maintain. With Sentinel, that friction is largely gone. Whether a source sits on-premises, in another cloud or in a third-party product, getting it in is straightforward, and the platform still provides the integration depth that genuinely matters rather than a shallow connection. Microsoft Sentinel handles almost anything you point it at.

Equally important is that SIEM and SOAR are not two separate platforms here. The orchestration and automation layer is built into the same solution, so response playbooks run on the same data that the detections are built on. For architecture, that is a real advantage: detection and response are designed as one system rather than stitched together afterwards. The central telemetry layer is one of the few decisions that is genuinely hard to reverse later, and Sentinel makes that an easy one to defend.

What advice do you have for others who would like to get involved in the Microsoft Community?

My advice is to start before you feel ready. I read Microsoft Tech Community (forums) for years before I posted anything myself, always with the feeling that I needed more experience first, that I would just be adding noise. That was the wrong instinct. The moment I actually started contributing, the feedback I got back made my own work better, and I realised the bar for being useful is far lower than it looks from the outside. You do not need to be the leading expert on a topic. You need a real problem you have worked through and the willingness to write down how you solved it. Someone else is stuck on exactly that problem right now. Start small, stay consistent, and treat the community as an exchange rather than a stage. Consistency matters more than any single brilliant post.

Alles rund um sein Buch (All About His Book)

Last year, I published "Die neue Realität der Cybersecurity" (2025). It tackles a question every security team is dealing with right now: “Where does AI genuinely strengthen security architecture and incident response, and where is it just noise?” Rather than staying abstract, the book takes the practitioner's side of that question, looking at how AI actually changes the work of designing defensible systems and responding to incidents, and where the limits and risks really are. It is written for the people doing the work, security architects, IR practitioners and the leaders who have to make decisions about AI without the marketing gloss. If that question is on your desk too, it is worth a look.

Connect with Marcel

Microsoft Tech Community: @marcel_graewer
Linkedin: https://www.linkedin.com/in/mgraewer/
Github: https://github.com/bifrost0x
Blogs: graewer.com and magra-sec.de
Book: Die neue Realität der Cybersecurity (ISBN: 9783695708833)

Marcel Graewer is currently an IT-Security Manager at Festool Group and holds the CISSP certification. Outside of work, he is happiest when experimenting with

technology on his own terms. He runs a Proxmox-based homelab with a range of self-hosted services and Docker containers, using it as both a playground and a testing ground. It gives him space to break things, learn, and explore without the constraints of formal change processes. He also spends time on Hack The Box and TryHackMe, believing that staying sharp on the offensive side makes him a stronger defender. Away from the keyboard, his life is refreshingly analog. He and his family, including two children, live in an old house that always seems to have one more project waiting. Between the homelab and the house, there is never a shortage of things to fix, and that suits him just fine.

Learn and Engage with the Microsoft Security Community

Follow = Click the heart in the upper right when you're logged in 🤍.

Join the Microsoft Security Community and be notified of upcoming events, product feedback surveys, and more.
Get early access to Microsoft Security products and provide feedback to engineers by joining the Microsoft Security Advisors.

Join the Microsoft Security Community LinkedIn Group and follow the Microsoft Entra Community on LinkedIn

Microsoft Entra Tenant Governance | Find Configuration Drift

Zachary-Cavanell — Wed, 27 May 2026 18:03:51 GMT

Capture configuration as code across 200+ resource types in Entra, Intune, Exchange, Teams, Defender, and Purview. Turn that snapshot into a Monitor. It scans for drift every six hours and flags every policy change.

Extend control to the tenants you don’t fully see today. Entra Tenant Governance surfaces them automatically through B2B, multi-tenant app, and billing signals. Request governance with role-based templates. Complete the secure approval handshake in the Entra admin center, then administer the governed tenant from a single browser using the roles forged in that handshake.

Jeff Staiman, Microsoft Entra Principal Product Manager, shares how to bring every tenant under one governance model.

More than 200 resource types. One baseline.

Configuration Snapshots in Microsoft Entra Tenant Governance lock in your tenant config across Entra, Intune, Exchange, Teams, Defender, & Purview. Start here.

Every tenant connected to your org, surfaced.

Entra Tenant Governance assembles a live Related Tenants list from B2B traffic, multi-tenant app config, and Microsoft Commerce billing signals. Check it out.

Same browser, same login.

Entra Tenant Governance authenticates you through the role assignments from your governance handshake. See how it works.

QUICK LINKS:

00:00 — Prevent tenant configuration drift

00:57 — Create a configuration baseline

02:23 — Detect configuration drifts

03:08 — Identify related tenants to govern

04:05 — Governed tenants

05:01 — Incoming request

06:17 — Set up monitoring

07:40 — Wrap up

Link References

Get started at https://aka.ms/EntraTenantGovernance

Restrict tenant’s connections at https://aka.ms/TenantQuarantine

Unfamiliar with Microsoft Mechanics?

As Microsoft’s official video series for IT, you can watch and share valuable content and demos of current and upcoming tech from the people who build it at Microsoft.

Subscribe to our YouTube: https://www.youtube.com/c/MicrosoftMechanicsSeries
Talk with other IT Pros, join us on the Microsoft Tech Community: https://techcommunity.microsoft.com/t5/microsoft-mechanics-blog/bg-p/MicrosoftMechanicsBlog
Watch or listen from anywhere, subscribe to our podcast: https://microsoftmechanics.libsyn.com/podcast

Keep getting this insider knowledge, join us on social:

Follow us on Twitter: https://twitter.com/MSFTMechanics
Share knowledge on LinkedIn: https://www.linkedin.com/company/microsoft-mechanics/
Enjoy us on Instagram: https://www.instagram.com/msftmechanics/
Loosen up with us on TikTok: https://www.tiktok.com/@msftmechanics

Video Transcript:

-To protect your organization, you need to ensure that your tenant configuration doesn’t drift from your defined security and compliance requirements. This needs to include all the Microsoft Entra tenants that you manage, whether for end-user collaboration, development and testing, mergers and acquisitions, or regional teams, as well as all the unsanctioned tenants set up by your employees, such as for testing or for shadow IT. Even a single configuration drift in one of your tenants can introduce vulnerability to your environment, and that’s where Microsoft Entra Tenant Governance comes in, to define configuration baselines as code in order to monitor configuration drift, to automatically find related tenants with existing B2B, billing, or multi-tenant app relationships, to request the permissions you need, to govern the tenants where you need visibility and control, and once approved by the related tenant admin, to monitor those configuration baselines in your governed tenants to detect drift from your desired state anywhere. Let’s start by creating a configuration baseline for our main tenant, Contoso Inc, to monitor for configuration drift.

-In the Microsoft Entra Admin Center, you can find Tenant governance under Entra ID. This tenant has several conditional access policies and cross-tenant access policies, as well as device compliance policies. We’ve already given the service permissions to read all the policies in this tenant, and that’s going to be required to run the snapshot process, and will be needed later to monitor for configuration drift. I’m going to give you a first look at the new configuration snapshots page, where you can capture the configuration of your existing tenant settings to detect drift or to use as a baseline for other tenants. I’ll create a new snapshot. I’ll begin by giving it a name, Contoso core compliance, and a description, Contoso core compliance May 2026. Then I select the resource types that I want to snapshot. You can use more than 200 resource types to monitor configuration across Entra, Intune, Exchange, Teams, Defender and Purview.

-First, I’ll select conditional access policies, then cross-tenant access policies, and external identity policies in Entra. Then in Intune, I’ll search for device compliance and I’ll choose iOS and Windows. I can review the resource permissions and expand out. Then I just need to confirm by clicking Create Snapshot. That’ll take a moment to query and write the configuration settings. Once it’s completed, I can click into it to view the details, and in the Configuration baseline tab, I can access adjacent representation of all the configuration settings.

-Now I want to set up monitoring so that I can automatically detect any configuration drift in any of these policies in my tenant that happens in the future. I can easily set this up by creating a monitor from this snapshot. In settings, it pre-populated the name and description. The monitors also pre-populate with the settings that were captured in the snapshot. We see that all the required permissions are in place. Monitoring a resource uses the same permissions as snapshotting it, so this is as expected. Now I can confirm and hit Create Monitor. It’ll run on a scheduled interval, currently every six hours. After the monitor has completed one or more runs in your tenant, you can check it for configuration drift. With our first run complete, I can check if there were any configuration drifts, and as you’d expect, everything looks good. No drifts.

-Now that I know I can keep the configuration of my main tenant healthy, let’s see how to identify other related tenants that I also need to govern. I’m still signed in as the admin for our main Contoso Inc tenant, and I’ll start from the related tenants list. It shows all tenants connected to my organization, including shadow tenants and external partner tenants. The list is automatically created and kept up to date by Entra’s tenant discovery signals, which look at B2B usage, multi-tenant app configuration, and Microsoft commerce billing. I see the Contoso 1 tenant in the list, which gets my attention since it has the Contoso name in it. I click on Contoso 1 to see the details. If I click into it and then I look at discovery signals, it shows B2B registration, B2B sign-in, admin app sign-ins, and multi-tenant apps, as well as billing relationships that were detected. I can get more detailed information in the Discovery Signals tab, where I can click to see the number of sign-ins for B2B and for admin apps. And in billing, it looks like our primary tenant is already paying for this one.

-Now let me show you how to establish governance over a related tenant. This is clearly a tenant that we need to govern, so I’ll close this view and I’ll move over to the Governed tenants view. Here you can see that I already have one governed tenant, Fabrikam, but not the Contoso 1 tenant. Let’s add it. So I click Request to govern. In the list of tenants, I can see the Contoso 1 tenant, and I’ll select it.

-To speed up the process, I’ve already created a few governance policy templates to define the access that my primary tenant needs over different types of governed tenants. Next, because this looks like a dev test tenant, I’ll choose the DevOps governance policy template, where I’ll request the global reader, security admin, and tenant governance admin rules. Templates are extensible to use your own multi-tenant resource management apps. This one contains the MegaMonitor app, which is a custom app that Contoso has written to monitor resources and govern tenants. From there, I just need to review and hit Create. The request gets sent via email. Now with the invitation sent, I’ll switch over to the perspective of the Contoso 1 tenant admin, who receives the incoming request. The email is sent from a Microsoft Security account in the microsoft.com domain and contains the details for the tenant governance request.

-For security, the request can’t be approved within the email directly. It needs to be approved in the Entra Admin Center. There’s a link in the email which takes you to the tenant governance relationship tab for pending requests. I see the request on the top of the list, and I click the request to see additional details. As I showed from the requester point of view, it contains the request for three roles: global reader, security admin, and tenant governance admin, and a request for that multi-tenant app called MegaMonitor to have permission to read audit logs and policies.

-From there, I can choose to accept or reject the request, and I’ll accept it. If the other tenant’s admin doesn’t approve your request, you can restrict their tenant’s connections to your primary tenant by blocking apps, preventing B2B access, stopping bill payment, or applying network blocks. To learn how, check out our documentation at aka.ms/TenantQuarantine. Once the request is accepted, the handshake between the tenants is complete and you can govern that other tenant.

-Now let’s switch back to the primary tenant admin’s point of view. Here I can see that the governance request was accepted and the governance status is now active.

-Now I can set up monitoring for that tenant to ensure that the conditional access policies and other policies meet Contoso Inc’s requirements. I need to create that new monitor while logged in as an admin in the newly governed tenant, and the good news is you don’t need to switch browser profiles or authentication contexts to do this. I copy the tenant ID from the Governed tenants page. Then I type entra.microsoft.com/ and I paste in the tenant ID from my clipboard. This signs me into the Entra Admin Center in the context of the governed tenant, Contoso 1. The authentication and authorization works using the Entra role assignment set up with a governance relationship, so there’s no need for a B2B account. You can see the authentication context in the user account area in the upper right corner of the admin center.

-Now I can go to the Tenant governance page. I navigate over to Monitors to create a new one. I start by giving it a name and description, and then I need to put in the configuration baseline for the monitor in Contoso 1. For that, I can go back to my primary tenant and go to my baseline and copy it. Now I’ll go back into the governed tenant and paste it in there.

-Next, there are the application permissions I showed before. A monitoring service in the Contoso 1 tenant needs the same permissions that it needed in the Contoso Inc tenant. To save time, I’ve added these read permissions in advance. Now all I need to do is review and hit Create. The monitoring service will run four times per day, and you’ll be able to review monitoring results from the governed tenant.

-And so that’s how tenant governance lets you keep all of your tenants securely configured on an ongoing basis, including related tenants that you don’t even know about today. To find out more and get started, check out aka.ms/EntraTenantGovernance. Keep watching Microsoft Mechanics for the latest tech updates, and thanks for watching.

Partner Blog | Leading the moment: How Azure partners are driving the Frontier shift

JillArmourMicrosoft — Wed, 27 May 2026 17:30:00 GMT

Something fundamental is shifting in how partners create value, and it is moving faster than many expected. That shift is creating new opportunities for those ready to lead. Across recent partner events and one-on-one conversations, we have heard a consistent message: customers are actively adopting AI and shifting toward becoming Frontier firms. They are moving AI from isolated experimentation to a core capability that drives execution, differentiation, and growth. Now customers are asking a more consequential question: how do we rewire our businesses to operate as a Frontier firm? That question can reshape how you deliver value.

In this blog, we share how Microsoft is investing in the platform and programs that enable the partner-led path to becoming Frontier, so you can turn AI ambition into durable transformation.

The Frontier shift partners are witnessing now

Frameworks set the direction, but markets move when partners lead. In conversations with partners around the world, one point is clear: AI has moved from exploration to execution. Customers are no longer asking whether to adopt AI. They are asking how fast they can put it to work safely, at scale, and with measurable outcomes.

Take TD SYNNEX, for example. TD SYNNEX is turning “AI-ready” into a repeatable channel motion by connecting devices, cloud, and security into its “Better Together” approach. Instead of letting customers buy pieces of the stack in silos, the motion guides partners to modernize endpoints, secure the foundation, and then adopt Microsoft AI with confidence, at the scale distributors can bring.

Across these conversations, a clear pattern is emerging: partners are thinking beyond any single workload or product to drive end-to-end business transformation built on Azure. This is the Frontier narrative coming to life in the market.

Continue reading here

Introducing PostgreSQL Hub for Azure Developers

ShreyaAithal — Wed, 27 May 2026 16:33:28 GMT

When you're building applications with PostgreSQL, finding the right resources can be harder than it should be. Documentation lives in one place, samples in another, tutorials scattered across blogs, and community discussions fragmented across forums. You end up with multiple browser tabs open just to piece together a working architecture for your project. Whether you're just getting started or you've been building for years, if all you want is a faster path from "I have an idea" to "this is running in production", then PostgreSQL Hub for Azure Developers is for you.

It brings everything together in one place. But it's more than just a content aggregator. Here's what makes it different:

Curated resources to help you build. From sample apps and solution accelerators to tutorials, videos, workshops, and relevant documentation, you'll find what you need to build core applications, AI-powered solutions, and multi-agent architectures on PostgreSQL. Resources are maintained and updated as new capabilities ship.
Structured learning pathways. Instead of navigating documentation on your own, you get guided paths that take you from fundamentals through intermediate patterns to advanced AI scenarios like vector search, AI functions, and building agents. The pathways are designed to help you develop a solid understanding at every stage.
Community space. Beyond content, the hub also includes a Developer Forum powered by GitHub Discussions where you can share product feedback, learn from fellow developers, and collaborate directly with Microsoft engineers on your use cases. Whether you want to discuss an architecture decision, share what you've built, or contribute a sample, the forum is the place for it. Real-time chat for quick questions and webinars is coming soon.

Who is this for?

No matter what stage you're at in building with PostgreSQL on Azure, there's something here for you. The hub is especially relevant if you are:

An application developer looking for curated resources, end-to-end guidance, and patterns to build or scale your projects on PostgreSQL
An AI builder exploring use cases like vector search, embeddings, AI functions, or agent architectures
A new learner looking for a clear starting point with structured content to guide you
An enterprise user with existing workloads on Azure looking to understand the full breadth of intelligent application development capabilities available with PostgreSQL

The sample apps, patterns, and learning content are valuable irrespective of whether you're already building on PostgreSQL or just exploring what's possible.

Get Started

The surface area of what you can build with PostgreSQL has expanded significantly, and finding the right resource at the right time shouldn't slow you down. That's exactly what this hub is here to solve.

Here's a quick walkthrough of the Postgres Hub:

Head over to aka.ms/postgres-hub to explore further! Browse the sample apps, pick a learning pathway that matches where you are, or join the community discussions to connect with other developers and Microsoft engineers.

We're actively growing this hub based on what the community needs. Your feedback, your questions, and your contributions will shape what comes next.

New Microsoft Certified: Intelligent Applications Builder Associate Certification

LibertyMunson — Wed, 27 May 2026 23:51:39 GMT

Design the next generation of AI‑powered business applications. Show you can combine apps, agents, automation, and Copilot into intelligent solutions in Microsoft Power Platform, with Exam AB‑410 (beta).

The way business solutions are built is changing fast. Today, it’s not enough to create an app or automate a task in isolation; builders need to bring together apps, agents, automation, data, and AI experiences into solutions that can adapt to real business needs. That’s why we’re introducing the Microsoft Certified: Intelligent Applications Builder Associate Certification, designed for professionals who are ready to use Microsoft Power Platform, Copilot, and natural language to build the next generation of intelligent business applications. To earn this new Microsoft Certification, you need to pass Exam AB-410: Building Intelligent Applications, currently in beta.

Is this the right Certification for you?

This Certification validates the skills of intelligent app builders who can confidently navigate the evolving AI and agent ecosystem, including how to:

Create a foundation for intelligent applications.
Create intelligent applications.
Build business application logic and automation.

Candidates for this Certification:

Build AI-powered solutions in Microsoft Power Platform by using Copilot, natural language prompts, and low-code tools.
Create apps, data models, and flows that connect agents, AI models and prompts, and visualizations.
Develop Dataverse data models and model-driven and canvas apps.
Integrate agents and Copilot features across apps and Power Pages.
Build cloud flows and business logic.

They partner with admins on security, identity, roles, and policies; governance teams on responsible AI, ALM, solutions and pipelines, and monitoring; builders and architects on solution design; and stakeholders on requirements, iteration, and adoption.

For this exam, candidates should have experience with Dataverse modeling, Power Automate cloud flows, Power Apps development, AI capabilities in Microsoft Power Platform, building solution assets with natural language, and Power Pages.

Before taking Exam AB-410, candidates should have:

Familiarity with Copilot in Power Apps, Copilot in Power Automate, Copilot in Power Pages, and Copilot in Dataverse.
Awareness of creating agents with Microsoft Copilot Studio.
Foundational knowledge of AI models and prompts in AI Hub.
Ability to map business processes to flows, agents, or app capabilities.
Ability to work with Dataverse as a core data platform.
Familiarity with low-code automation, including Power Fx.
Awareness of environment governance, roles, policies, and solution lifecycle steps.

Ready to prove your skills?

Take advantage of the discounted beta exam offer. The first 300 people who take Exam AB-410 (beta) on or before June 17, 2026, can get 80% off.

To receive the discount, when you register for the exam and are prompted for payment, use AB410KBMaui. This is not a private access code. The seats are offered on a first-come, first-served basis. As noted, you must take the exam on or before June 17, 2026. Please note that this discount is not available in Turkey, Pakistan, India, or China.

How to prepare

Review the Exam AB-410 (beta) page for training resources, exam registration and other details.
The Exam AB-410 study guide explores key topics covered in the exam.
Connect with Microsoft Training Services Partners in your area for in-person offerings.
Need other preparation ideas? Check out Just How Does One Prepare for Beta Exams?

Ready to get started?

You can take Certification exams online, from your home or office. Get the details in Online proctored exams: What to expect and how to prepare.
Remember, the number of spots is limited to the first 300 candidates on or before June 17, 2026.
Beta exam rescoring begins when the exam goes live, with final results released approximately 10 days later. For more details, read Creating high-quality exams: The path from beta to live.
Stay tuned for general availability of this Certification in July 2026.

Additional information

For more AI business solution Certification updates, read our recent blog post, The AI job boom continues: Build the skills that move business forward.

Follow our Microsoft Credentials news on The Skills Hub Blog as we roll out additional new Certifications in June and July 2026.

Join our Microsoft Worldwide Learning SME Group for Credentials on LinkedIn for beta exam alerts and opportunities to help shape future Microsoft learning and assessments.

If you’d like to learn more about Microsoft Credentials, go to AI Skills Navigator.

Recertified: How Microsoft 365 Copilot continues to earn trust and What Changed in a Year

Oliver_Bell — Wed, 27 May 2026 16:00:00 GMT

Recertification: ISO 42001 for the second consecutive year

Today, we are announcing that Microsoft 365 Copilot and Copilot Chat (Copilot) have achieved ISO/IEC 42001:2023 recertification independently validated for the second consecutive year.

First certified in March 2025, Copilot was among the first enterprise AI systems in the world to earn ISO 42001 certification. One year later, the recertification audit conducted in March 2026 confirmed: zero non-conformities and zero improvement observations, with back-to-back clean audits.

ISO 42001 requires annual recertification (called surveillance) audits that re-examine the AI management system across governance, risk assessment, data management, transparency, human oversight, and supplier management. An independent internal audit in late 2025 had already confirmed the system as effective across nine functional domains. The recertification audit by the certification body validated the same conclusion.

Microsoft 365 Copilot and Copilot Chat is joined by GitHub Copilot, Microsoft Copilot Studio, Microsoft Dragon Copilot, Microsoft Dragon Copilot (Radiologists), Microsoft Copilot Health, Microsoft Foundry, and Security Copilot in Microsoft's ISO 42001 certified portfolio, for a total of eight AI systems, including previously certified Microsoft Foundry and Security Copilot, spanning enterprise productivity, developer tools, healthcare, platform, and security.

Certificates, audit reports, and control alignment documentation are available on the Service Trust Portal.

What changed in a year

ISO 42001 recertification is not about maintaining the status quo. It is about demonstrating that the AI management system evolves with the technology it governs. Here is what changed between March 2025 and March 2026:

The model portfolio expanded and governance scaled with it. When Copilot was first certified in 2025, it relied primarily on a single model family from Azure OpenAI. One year later, the same governance framework now manages a multi-model, multi-provider portfolio: GPT-5 is the default model, and Anthropic Claude models are available as an additional option. Third-party model providers undergo Microsoft's supplier security and privacy review process before integration, and enterprise customers have full admin controls including the ability to enable or disable third-party models.

This is the proof that ISO 42001 scales. The management system designed for a single-model architecture governed the expansion to multi-model, multi-provider without requiring a fundamental redesign.

AI risk assessment processes matured. The responsible AI assessment workflow was streamlined consolidating review steps to reduce duplicative effort while maintaining rigor. A structured harm identification capability was added to strengthen pre-release risk evaluation. And a risk-tiered review model was implemented to ensure senior oversight is aligned with the highest-impact AI systems and features.

Product quality improved alongside governance. User satisfaction with M365 Copilot improved meaningfully over the year a sign that governance and quality reinforce each other. When responsible AI practices are embedded into development, the result is not just a safer product but a better one.

The AIMS scope expanded. Microsoft Copilot Studio was formally brought under the governance framework, expanding coverage from two AI systems to three under a single certified management system.

Using AI to govern AI

This is perhaps the most distinctive aspect of Microsoft's approach. Over the past year, Microsoft has deployed AI agents internally to scale responsible AI governance. These AI-powered tools empower engineering teams in conducting RAI assessments, streamline design review processes, without replacing human judgment.

The result is an improvement loop: the same AI technology Microsoft builds for customers is being used to strengthen the governance of that technology. AI agents help in drafting assessments; human experts review, challenge, and approve. Humans remain in the loop, but AI helps us scale.

Product teams across the Copilot organization now use AI-assisted governance tools as part of their responsible AI workflow. Responsible AI training is also enforced across governance leadership roles.

This is what continuous improvement looks like in practice: not just maintaining the AI management system, but using AI to make the management system itself more effective.

Customer confidence, validated

The impact of this governance investment shows up in customer decisions:

Quilter, one of the UK's leading wealth management firms, explicitly cited Microsoft's data protection policies and assurances as "key factors in our decision" to deploy M365 Copilot. In a regulated financial services environment where client trust is paramount, Quilter took a deliberately phased approach beginning with technology teams to manage compliance risk before expanding.

Clifford Chance, one of the world's leading "Magic Circle" law firms, deployed M365 Copilot at global scale after developing comprehensive AI governance principles grounded in fairness, transparency, accountability, and privacy. Every legal output generated by AI is identified as such and validated by a qualified lawyer. Clifford Chance now advises other organizations on building their own AI governance frameworks and chose Microsoft as the platform they trust enough to build on.

PwC deployed 200,000 Copilot licenses globally, generating $150 million in time savings and 40.8 million Copilot actions in six months. At this scale, governance is not optional it is what makes the deployment responsible.

For government customers, M365 Copilot is now available in GCC-High, built to meet FedRAMP High, DFARS, ITAR, and CMMC requirements with web grounding disabled by default and all data remaining within US-based data centers managed by screened US personnel.

A Forrester Total Economic Impact study found M365 Copilot delivers 116% ROI for enterprises and notably, 66% of respondents said Copilot improved or simplified their IT and data security posture.

As Drena Kusari, Microsoft VP & GM for Shared Services and Responsible AI, puts it: "Earning and keeping our users' trust is what gives us permission to build cutting-edge AI functionality. We put equal thought into the functionality of our features as we do into the responsible AI practices that encourage lasting interactions with Microsoft 365 Copilot."

What comes next

The AI landscape in March 2026 looks different than it did in March 2025, and it will look different again in March 2027. Models are becoming more capable, multi-agent architectures are emerging, and regulatory frameworks like the EU AI Act are moving from policy to enforcement, with high-risk system requirements taking effect in August 2026.

Our commitment is to evolve the AI management system with the technology. As Microsoft 365 Copilot continues to add agentic capabilities and expands multi-model support, the governance framework will scale accordingly. ISO 42001 recertification is not a destination; it is the annual proof point of continuous improvement.

Moreover, we have also achieved CSA STAR for AI Level 2 certification - pairing ISO 42001 with CSA's AI-specific transparency artifacts, and we are among the first organizations globally to do so.

Trust is not earned once; it is earned continuously, and it must be re-earned every year.

Additional resources

Trust should be verifiable. Here is where you can check the supporting information:

Service Trust Portal, ISO/IEC, ISO/IEC 42001 certificates, audit reports, and control alignment documentation
2025 Responsible AI Transparency Report, our annual report on AI governance, risk management, and implementation
Microsoft 365 Copilot Application Card, detailed documentation of capabilities, models, evaluations, limitations, and safety mitigations
ISO/IEC 42001 Compliance Offering, details of our ISO/IEC 42001 certification scope and services
EU AI Act Compliance, our EU AI Act compliance posture and GPAI Code of Practice signatory status
CSA STAR for AI Registry, our CSA STAR for AI Level 2 certification, achieved among the first organizations globally

Learn more about Microsoft’s approach to responsible AI at https://microsoft.com/ai/responsible-ai

Organize your multitenant view with Tenant Groups in Microsoft Defender

Simaya_Ouli — Wed, 27 May 2026 16:00:00 GMT

Managing security across many tenants shouldn’t mean drowning in a single, flat list. We’re excited to share a new capability, now in public preview in the Microsoft Defender multitenant (MTO) portal: Tenant Groups—a flexible way to organize the tenants you manage and switch your view between them with a single click.

If you’re a managed security service provider (MSSP), a cloud service provider (CSP), or a security team operating across multiple Entra ID tenants, this one’s for you.

What’s new

Tenant Groups let you create logical groupings of tenants (by customer segment, geography, criticality, onboarding stage—whatever fits how you work) and seamlessly switch the Defender MTO view to show data from only the tenants in that group.

NOTICE: The feature previously called Tenant groups—used for content distribution—has been renamed to Deployment profiles. The name “Tenant Groups” now refers to this new grouping experience.

Why it matters

Focus, faster – Investigate incidents, hunt threats, and review posture against just the tenants you care about right now—without noise from the rest.
Operational clarity – Group tenants the way your team actually works (e.g., Tier 1 customers, EMEA, Pilot rollout).
Permissions-aware – Even if a Tenant Group contains more tenants, you’ll only see the ones where you have B2B/GDAP (granular delegated admin privileges) access. Your existing access controls stay in charge.

Permissions you’ll need

To work with Tenant Groups, your account needs one of the following:

Entra ID roles

Security Administrator
Security Operator
Global Administrator

Product-specific (MDE, MDI, etc.) role-based access control (RBAC)

Global Administrator
Security Administrator
Plus, any custom RBAC roles required to see data across products

Unified RBAC (URBAC)

Security/read—to view Tenant Groups
Security/manage—to create Tenant Groups

Remember: A Tenant Group can include tenants you don’t have access to. You’ll only ever see the ones your permissions allow.

Getting started

1. Open Tenant Groups

Sign in to the Microsoft Defender portal with administrative credentials, then navigate to Multitenant Management > Tenant Groups.

You’ll find a built-in group called My private group that contains all the tenants from your previous setup. You can add or remove tenants from it, but it can’t be deleted.

2. Create a Tenant Group

Select + Create tenant group.
Give it a descriptive name (e.g., Healthcare customers, EMEA Tier 1).
Optionally, add a description so teammates know the group’s intent.
Select the tenants you want to include.

That’s it—your group is ready.

3. Switch between Tenant Groups

In the top-left corner of the portal, select Open multitenant management.
Choose the group you just created.

Navigate around the Defender MTO portal—incidents, alerts, devices, hunting—and you’ll see only data from the tenants in that group. Switch groups anytime to refocus.

Live change detection: If a teammate edits a Tenant Group (adds or removes tenants) while you’re viewing it, the portal surfaces a notification so you know the underlying scope has changed. No stale views, no surprises.

4. Edit a Tenant Group

Go back to Multitenant Management > Tenant Groups.
Select the group and choose Edit.
Add or remove tenants as your environment evolves, then re-test your views.

Tips for getting the most out of Tenant Groups

Start with how your team triages – Name groups after the workflows you actually run (On-call queue, Customer A—production).
Keep groups small and purposeful – Overlapping, focused groups beat one giant catch-all.
Pair with Deployment profiles – Use Tenant Groups for viewing, and Deployment profiles for distributing content—two clean, complementary concepts.
Audit access regularly – Because group membership is independent of B2B/GDAP access, periodic reviews keep expectations aligned.

We want your feedback

Tenant Groups are designed around real multitenant operations work—and we’d love to hear how you’re using them. Try it out in your environment, share what’s working (and what isn’t), and let us know what you’d like to see next.

New MRCA Diagnostic: Teams Premium License & Configuration Check

Carlos Farrica — Wed, 27 May 2026 15:36:31 GMT

As Microsoft Teams Premium continues to expand its capabilities ensuring proper license assignment and tenant configuration is critical for a seamless user experience. To support this, we're excited to introduce the Teams Premium License & Configuration Diagnostic — a comprehensive tool designed to validate license readiness, feature enablement, and tenant policy settings for Teams Premium.

Get Started

To access the diagnostic, navigate to Microsoft Remote Connectivity Analyzer, select Microsoft Teams, then click on "Teams Premium Details".

Why This Matters

The ability to leverage Teams Premium features is directly tied to proper license assignment and correct tenant configuration. Without the right setup, users may encounter issues such as:

Premium features not appearing despite having a license
Users activating self-service trials without admin approval
Feature-specific capabilities (Mesh, eCDN, Virtual Appointments) not functioning as expected

That's where our diagnostic comes in — helping you quickly validate license readiness, confirm feature availability, and identify configuration gaps before they impact users.

What the Diagnostic does?

The Teams Premium diagnostic is built to empower both customers and support engineers. It validates whether your tenant and users are properly configured for Teams Premium by checking:

License assignment and validity — Confirms that a valid Teams Premium license is assigned to the user
Self-service purchase policy (NEW) — Warns administrators if self-service purchase is enabled, meaning users can acquire Teams Premium without admin approval
Microsoft Entra ID attributes — Verifies user identity attributes are correctly configured
Feature-level enablement — Individually checks each Teams Premium feature: - Teams Premium core features

This diagnostic ensures that configuration issues are identified upfront proving actions to fix it and helping organizations maximize the value of Teams Premium.

Who Should Use It?

Note: The diagnostic can be run with either a Global Admin or standard user account.

IT Admins validating that users have the correct Teams Premium licenses and features enabled
Support Engineers troubleshooting Teams Premium feature availability
Adoption & Change Management Leads confirming tenant readiness ahead of Teams Premium rollouts

What's New: Self-Service Purchase Validation

The latest update adds a critical governance check. If self-service purchase is enabled for Teams Premium.

This helps administrators identify a potential governance gap without needing to file an ticket to Microsoft to investigate backend settings. To disable self-service purchases, a Global Administrator can follow the guidance in Manage self-service purchases and trials.

Introducing Microsoft Planetary Computer Pro Model Context Protocol Tools on VS Code

nelsontam — Wed, 27 May 2026 15:23:32 GMT

About Microsoft Planetary Computer Pro MCP Tools

The Microsoft Planetary Computer Pro MCP Tools introduces a natural language-driven interface that simplifies how users interact with geospatial data managed with Microsoft Planetary Computer Pro.

By integrating directly with GitHub Copilot in VS Code, our MCP exposes 35+ tools that connect directly to Microsoft Planetary Computer and Planetary Computer Pro, enabling users to perform data ingestion, STAC search, GeoCatalog management, visualization, and ingestion monitoring through natural language prompts. Instead of managing specialized APIs or stitching together multiple interfaces, MCP brings everything into a single, streamlined experience, reducing friction and accelerating time to insight.

Figure 1 - What is Model Context Protocol?

How Does it Work?

MCP brings Microsoft Planetary Computer Pro workflows directly into the developer environment by embedding a natural language interface within VS Code through GitHub Copilot. As shown in Figure 2, users can describe tasks conversationally on VS Code, such as querying geospatial imagery, ingesting data, analyzing regions, or preparing datasets, and MCP translates those prompts into executable geospatial operations. This eliminates the need to write code or switch between tools, enabling faster iteration, tighter developer workflows, and a more intuitive path from idea to insight. To get started, install the extension from VS Code Marketplace. Instructions and a full list of tools are documented on the Install page.

Figure 2 - Microsoft Planetary Computer MCP Tools on VS Code

Key Features within the Toolset:

STAC Search & Discovery

With Microsoft Planetary Computer Pro MCP tools, users can simply describe what they’re looking for or search for data from an area of interest through an interactive map. Across both Planetary Computer public datasets and Microsoft Planetary Computer Pro GeoCatalog private datasets, MCP and STAC search enables fast, intuitive discovery of data across space, time, and metadata.

GeoCatalog Management

Beyond discovery, MCP streamlines the full lifecycle of geospatial data management. Users can create, configure, and manage STAC collections with ease, moving datasets from the Planetary Computer, defining rendering options like natural color or NDVI, and setting up mosaics or thumbnails, all through conversational prompts. This eliminates the traditional complexity of API calls and manual configuration, making it significantly easier to operationalize geospatial datasets and tailor them to specific mission or analysis needs.

Data Ingestion

Data ingestion, often one of the most complex and time-consuming steps, becomes seamless with MCP. Users can ingest data from Planetary Computer collections, or access ingestion APIs using simple prompts. From ingesting a single item to bulk onboarding entire datasets, MCP handles the orchestration, monitoring, and status tracking of ingestion workflows. This enables teams to quickly move from raw data to analysis-ready collections without needing to manage underlying pipelines.

What Problem Does It Solve?

Working with geospatial data today often requires navigating fragmented tools, managing specialized APIs across systems, and authentication. This complexity slows down geospatial workflows and increases the operational burden on customers. With MCP, users can:

Eliminate the need for custom scripts and manual integrations
Reduce time spent managing ingestion pipelines and catalog configurations
Quickly move data between systems
Focus on generating insights instead of managing infrastructure

MCP orchestrates tasks behind the scenes, transforming complex geospatial workflows into a conversational experience that is intuitive and efficient.

Why this Matters

The release of the Microsoft Planetary Computer Pro Model Context Protocol marks a meaningful shift in how geospatial data and tasks are performed, accessed, managed, and operationalized. By unifying discovery, ingestion, catalog management, and troubleshooting into a single, natural language driven experience, MCP removes traditional complexity and empowers users to focus on what matters most, generating insight and driving outcomes.

As geospatial workloads continue to grow in scale and importance, simplifying access to these capabilities becomes critical. MCP enables Microsoft Planetary Computer Pro users to move faster, lower barriers to entry, and unlock the full value of Microsoft Planetary Computer Pro without needing deep expertise in underlying systems or building special connectors to access various tools.

As we continue to expand the Microsoft Planetary Computer Pro MCP toolset and integrate more automation of workflows and cross-pollinate between platforms, we envision a future where completing multi-step complex functions is as simple as having a conversation with GitHub CoPilot, accelerating innovation across GeoAI and enabling organizations to turn data into actionable intelligence at unprecedented speed.

Get started today by installing the MCP Tools in VS Code and experience a new, seamless way to work with geospatial data on Microsoft Planetary Computer Pro.

Resources

Update Health in Cloud Update is now Generally Available

BobClements — Wed, 27 May 2026 15:00:00 GMT

Keeping Microsoft 365 Apps up to date is essential for security, reliability, and access to new features. When an update does not complete successfully, however, identifying the issue and understanding its impact across devices can take time.

Today, we’re announcing general availability of update health in cloud update in the Microsoft 365 Apps admin center. Update health gives you clearer visibility into issues across cloud update-managed devices by surfacing descriptive error information, aggregated issue views, and device-level troubleshooting details in one place.

What update health helps you do

Update health builds on the existing monitoring experience in cloud update by helping you quickly understand why devices did not update as expected.

With this release, admins can:

See aggregated views of update issues across cloud update-managed devices

Review descriptive, easier-to-understand error messaging aligned to update error codes
Export device lists for follow-up and remediation workflows

Drill into affected devices for more detailed issue information

Use linked guidance to help with troubleshooting and resolution

As a result, you can spend less time identifying issues and interpreting logs, and more time taking action on the devices that need attention most.

Why this matters for IT admins

Managing updates at scale is not just about deploying the latest build. It also requires confidence that issues can be identified quickly and addressed efficiently.

Cloud update already provides a modern service management experience for Microsoft 365 Apps, including controls such as rollout waves, pause, rollback, and exclusion windows. Update health extends that experience by improving visibility into what happens after an update is offered to devices. Together, these capabilities help admins manage updates with greater confidence while reducing the effort needed to investigate failures.

Availability

Update health is now generally available for eligible organizations using cloud update. The feature is enabled by default, with no user impact and no changes required to existing update policies.

Getting started

No additional setup is required beyond using cloud update to manage Microsoft 365 Apps updates for your devices. Once the feature is available in your tenant, you can access update health by selecting one of the channel profiles in the left navigation.

Learn about Richtech Robotics' transactable partner solutions in Microsoft Marketplace

Nikhil_Viswanathan — Wed, 27 May 2026 20:15:43 GMT

Microsoft partners like Richtech Robotics deliver transact-capable offers, which allow you to purchase directly from Microsoft Marketplace. Learn about these offers below:

ADAM: AI Robotic Barista and Bartender: ADAM is a dual-arm beverage service robot designed to automate drink preparation while creating an engaging customer experience. Powered by AI and integrated with Microsoft Azure services, ADAM serves as a robot bartender, barista, and specialty beverage maker, helping businesses deliver high-quality beverages with speed, consistency, and novelty in customer-facing environments.

Scorpion: AI Robotic Bartender: Scorpion is an AI-powered beverage service robot designed to automate drink preparation while creating a memorable customer experience. Built for customer-facing environments and designed with a compact footprint and a single robotic arm, Scorpion helps businesses deliver fast, consistent, and visually compelling beverage service in settings where both operational efficiency and guest interaction matter.

TeleOp Robotics Data Platform: Richtech TeleOp Robotics Data Platform enables remote robot operation and high-quality data collection for industrial, research, and AI-driven applications. Designed for diverse environments, including where physical presence is limited or unsafe, TeleOp enables operators to perform remote teleoperation with precision and supports three control modes: VR headsets, handheld controllers, and auxiliary master arms.

Titan: Delivery Robot and Cloud System: Designed for automotive service centers, warehouses, manufacturing floors, and distribution hubs, Titan is an autonomous mobile robot platform that automates repetitive transport tasks so that employees can focus on higher-value work. Titan robots use AI-powered navigation and obstacle avoidance to move items efficiently through dynamic environments without requiring major infrastructure changes.

New dual-ID requirement for account linking APIs

garittar — Wed, 27 May 2026 12:46:23 GMT

We’re introducing an important security update to Microsoft Advertising account linking APIs to better protect customer accounts and prevent unauthorized access.

This change applies only to new linking requests. Existing links and pending requests aren't affected.

What’s changing

To create or accept an account linking request, you must now provide two identifiers instead of one:

For manager account linking (CID):

Manager account number (alphanumeric)
Manager account ID (numeric)

For account linking (XID):

Manager account number (alphanumeric)
Account number (alphanumeric)

Why this change matters

We’ve strengthened the account linking process to reduce the risk of unauthorized access and fraud.

Previously, linking could be initiated using a single identifier, which increased exposure to brute-force attempts. The new dual-ID requirement helps:

Improve overall account security.
Block most fraudulent linking attempts.
Maintain a high success rate for legitimate use cases.

What you need to do

Update your integration to ensure:

Both required identifiers are included in all linking API calls.
Values are validated to match the correct target account.
Your workflows handle errors for missing or mismatched IDs.

Timeline

Enforcement begins August 26, 2026, and will roll out gradually.

To avoid disruption:

Update your API calls to include both identifiers before August 26, 2026.

After enforcement begins, any new linking requests that do not include both IDs will be rejected.

Support

We recommend prioritizing these updates early to avoid disruption to your workflows.

If you have questions or need assistance, contact your Microsoft Advertising account team or reach out to Microsoft Advertising support.

Scaling the reach of finance: what’s next with Finance Agent in Microsoft 365 Copilot

April_Olson — Wed, 27 May 2026 12:00:00 GMT

In most organizations, finance is a small but mighty strategic partner to the business, supporting enterprise-wide decisions while managing core processes from record-to-report and source-to-pay to forecast-to-plan. The insights and guidance finance teams produce are more than just outputs of these processes; they form the foundation for critical decisions that shape how the business operates and grows.

On any given day, finance teams are expected to:

Deliver accurate and timely financial reporting, while maintaining controls and compliance. 
Guide business performance by proactively identifying opportunities and risks.
Support operational decisions across business units, regions, and functions.  
Enable planning and forecasting in fast-paced environments where assumptions change quickly.

As businesses grow and become more complex, expectations can become harder to meet. Finance teams must navigate increasingly fragmented data—pulling together insights across systems, reports, and stakeholders to form a clear picture. At the same time, they’re asked to support more stakeholders, make more decisions, and operate on faster timelines—without growing at the same pace. To keep up, finance teams must scale.

But scaling isn’t just about doing more with the same tools. It requires a fundamental shift in how finance operates. This is the shift that underpins Microsoft’s vision for agentic ERP, where enterprise systems move beyond just recording transactions and generating reports, to helping organizations reason over data, coordinating decisions, and taking action. In this model, AI agents work alongside finance teams to extend their capacity—handling routine work, surfacing issues, and helping them focus on what matters most.

Empowering finance at scale: Finance Agent in Microsoft 365 Copilot

Finance Agent in Microsoft 365 Copilot delivers on this vision by connecting financial data, insights, and actions directly in the flow of work, helping finance teams scale their impact.

First introduced as Copilot for Finance, Finance Agent is purpose-built for the structure and rigor of modern financial operations. Rather than requiring extensive customization like general-purpose AI tools, Finance Agent is designed around core finance workflows and grounded in ERP data—so organizations can move from insight to action faster, without compromising financial controls, governance, or auditability.

As innovation with AI accelerates, Finance Agent continues to evolve. Today we’re announcing new Finance Agent experiences in Microsoft 365 Copilot, designed to give both finance teams and the stakeholders who rely on them the insights they need to act with confidence.

Announcing new ways to experience Finance Agent in Microsoft 365 Copilot

At Gartner Finance Symposium/Xpo™ 2026, we’re showcasing a new Home workspace and Chat experience for Finance Agent in Microsoft 365 Copilot, in public preview today. These new experiences make it easy for finance teams and their stakeholders to get a centralized, role-aware view of financial performance and activity. Instead of relying on static reports or ad hoc requests, users can access up-to-date financial insights tailored to their role with the appropriate permissions and context built in.

The Home workspace acts as a financial command center, proactively surfacing key metrics, emerging risks, and areas that require attention. For example, a finance leader can quickly identify variances impacting forecast accuracy, while a business unit leader can monitor performance against targets without needing to request or reconcile multiple reports.

The Chat experience lets users interact with financial data and processes using natural language, moving seamlessly from question to insight to action.

Whether investigating performance, resolving issues, or executing next steps, users can work directly in the flow of work. For example, they can enter prompts in Microsoft 365 Copilot like:

Analyze this project report and help me identify the key drivers for the variance between budget to actuals.
Help me respond to this customer’s question about an unpaid invoice by pulling their transaction history and identifying unmatched invoices.
Help me assess this new vendor’s compliance with our onboarding guidance and update the vendor record if approved.

Together, these experiences help finance teams scale how insights are delivered across the organization—reducing ad-hoc requests, improving consistency, and enabling faster, more informed decision-making. 

Speed, clarity, and control across core financial workflows

Alongside these new experiences, Finance Agent continues to support the core processes that define finance operations, helping teams move from analysis to action with greater speed and confidence.

Financial reconciliation streamlines one of the most time-intensive aspects of the close cycle. By identifying unmatched transactions, surfacing exceptions, and guiding resolution, Finance Agent reduces manual effort while maintaining financial control and auditability. 

Variance analysis accelerates the path from actuals to explanation. When performance deviates from expectations, Finance Agent identifies key drivers and produces structured summaries that support faster decision-making and stakeholder alignment. 

Financial data preparation accelerates the path from raw data to reliable insight. When financial data is inconsistent or incomplete, Finance Agent automatically cleanses, standardizes, and enriches datasets—ensuring they’re ready for reconciliation and analysis, while reducing manual effort and improving confidence in outcomes.

These capabilities are purpose-built for finance and designed to deliver outputs that reflect the structure, precision, and context required for financial decision-making, while operating within defined latency constraints to ensure timely responses. We’ve recently run evaluations to measure the outputs and found that Finance Agent scored meaningfully higher on Accuracy, Depth, and Structure compared with OpenAI and Anthropic.

In addition to the strong results in our core metrics, we also demonstrate clear differentiation in metrics for citations, clarity, relevance, recency and groundedness.

Get started with Finance Agent and see it in action at Gartner Finance Symposium/Xpo™ 2026

If you haven’t already explored Finance Agent, now is a great time to get started. The solution is generally available, ready to connect to your existing ERP environment, and continually evolving with new capabilities and experiences.

To learn more: 

Explore Finance Agent in Microsoft 365 Copilot by visiting Agent Store and clicking “All Agents” within Microsoft 365 Copilot.
Review Microsoft Learn documentationfor setup and administration guidance. 
Discover more about Microsoft 365 Copilot and how role-based AI agents across Sales, Service, and Finance are transforming business processes.
Connect with us at the Gartner Finance Symposium/Xpo^TM, where we’ll be sharing our vision for agentic ERP and demonstrating the latest innovations, including Finance Agent in Microsoft 365. Add our session to your agenda.

We’re excited about the opportunity to reshape finance with AI and agents, and how Microsoft 365 Copilot can help you scale your organization, accelerate decision making, and empower your team to achieve more.

Finance Agent Benchmark: evaluating and improving AI for Finance

Sigita_Cepaitiene — Wed, 27 May 2026 12:00:00 GMT

As business complexity accelerates, finance organizations are being asked to support more stakeholders, guide more decisions, and operate at unprecedented speed, often without additional resources. As these demands outpace traditional tools and processes, AI presents an opportunity to reshape how finance teams scale their impact. Finance Agent in Microsoft 365 Copilot is purpose-built for this shift, helping finance teams extend capacity, improve speed and accuracy, and deliver insights that support decision-making.

Today, we’re announcing the Finance Agent Benchmark, a benchmarking framework comprising an evaluation dataset and an evaluation harness, designed to assess how effectively AI-powered finance agents perform across real-world finance scenarios. It combines purpose-built metrics with finance-specific scenarios and a scoring methodology designed to produce meaningful, real-world assessments.

Our first release in the Finance Agent Benchmark includes tasks like preparing finance business briefs and researching financial performance, based on both reputable data sources (including public SEC filings and financial market data via MSN Money) and synthetic internal Accounts Payable and Accounts Receivable data.
This technical deep dive describes how Finance Agent is designed, how the benchmark is structured and scored, and compares results of Finance Agent on the benchmark against those of OpenAI Responses API with GPT 5.5 and Anthropic Claude CLI with Claude Opus 4.7.

Finance Agent in Microsoft 365 Copilot architecture

Finance Agent is built on a modular, agentic architecture designed to help organizations derive value from financial data while leveraging Microsoft’s AI ecosystem, including enterprise security and compliance controls such as identity-based access (Microsoft Entra ID), tenant-level data isolation, encryption in transit and at rest, and Microsoft Purview governance capabilities (e.g., sensitivity labels, data loss prevention, and audit logging). Its design centers on a unified, agentic backend that orchestrates finance-specific capabilities such as finance business brief generation, entity financial performance research, entity financial obligations with the user company research.

Finance Agent’s architecture includes a run-time generated dynamic, context-aware UI experience. Rather than relying on static interfaces, the system generates UI elements at runtime based on the user’s role, workflow stage, and current task context. The platform composes tailored experiences dynamically adapting to where the user is in their workflow and what action they are trying to complete. This enables highly personalized, scenario-driven interactions (e.g. researching invoicing history), where UI elements, tools, and insights are assembled in real time to guide the user through finance processes such as analysis, reconciliation, or reporting.

The unified agentic backend integrates APIs, MCP applications, tools, and skills with a data access layer designed for enterprise scenarios, enabling seamless connectivity to work context with Microsoft 365, ERP systems, and external financial sources. This agentic framework allows the system to intelligently orchestrate both data retrieval and user experience in a tightly coupled manner.

Together, this AI-powered backend and dynamic UI layer delivers deeply embedded, workflow-centric experiences within Microsoft 365 Copilot, enabling finance professionals to access insights, perform analysis, and execute workflows within their natural flow of work.

Evaluation Methodology of Finance Agent in Microsoft 365 Copilot

We evaluated Finance Agent using a purpose-built benchmark designed to reflect real finance workflows, including ERP data retrieval and multi-entity financial analysis. The benchmark uses a transparent methodology, so results can be independently verified and reproduced. To keep the benchmark grounded in the day-to-day tasks and challenges finance teams face, we built it in collaboration with finance professionals across multiple industries. The benchmark is designed to execute repeatedly, enabling consistent measurement of improvements and producing results that remain comparable over time.

We constructed a dataset spanning three finance task areas: (1) finance business briefs preparation, (2) entity financial obligations with the user company research, and (3) entity financial performance research. This dataset includes approximately 300 questions spanning these areas, covering multiple industries, company types, and finance roles:

Finance business briefs preparation: A structured intelligence report on a company - combining financial performance, strategic context, and ERP history - of the kind a finance analyst would prepare before a negotiation or credit decision.
Entity financial obligations with the user company research: Answers to accounts payable and accounts receivable questions over Dynamics 365 Finance data, covering vendor balances, invoice aging, and payment obligations.
Entity financial performance research: Answers to time-bound factual questions about a company's financial health (e.g., revenue, margins, leverage, and latest reported results) grounded in public filings and market data.

The current release of Finance Agent focuses on providing quick answers in conversational experiences, therefore latency limits are applied for the responses: 60 seconds for entity financial questions and 300 seconds for business brief generation.

We compared Finance Agent with two alternative systems, to evaluate how it performed, both in user experience and results, against general-purpose agentic runtimes not specifically designed for financial tasks: OpenAI’s Responses API and Anthropic’s Claude Code CLI. Both were given the same tool access as Finance Agent, including a Dynamics 365 Finance MCP Server and web search, and operated under common system instructions designed to simulate the experience a finance professional would have when using an AI agent. We used the latency optimized models from each provider at the time of evaluation in May 2026: Anthropic’s Claude Haiku 4.5 and Claude Opus 4.7 and OpenAI’s GPT 5.5, all configured with low reasoning effort. Latency optimized models were selected to match the latency limits applied to Finance Agent: 60 seconds for entity financial questions and 300 seconds for business brief generation. In separate experiments using default reasoning settings, those systems often exceeded the time limits, resulting in a high rate of timeouts and lower performance. If we remove the latency constraints, models with high reasoning effort have substantial improvements at the cost of the extra latency. We will cover detailed performance with high reasoning effort for all three comparators in the next version of the Finance Agent Benchmark.

Evaluation Dimensions

We evaluated the AI agents along multiple metrics that were designed to measure alignment of responses with the expectations of finance professionals:

Accuracy - Measures whether the answer is factually correct and aligns with verified financial data or ground truth in the financial system of record, Dynamics 365 Finance.
Citation Rate - Checks whether the response properly references and cites sources to support its claims.
Clarity - Assesses how easy the response is to understand, including conciseness and readability.
Depth - Measures how thoroughly the response explores the topic, going beyond surface-level information.
Groundedness - Evaluates whether the response is supported by referenced sources and avoids unsupported or hallucinated claims.
Recency - Measures whether time-sensitive information is up-to-date and anchored to specific dates where relevant.
Relevance - Assesses whether the response directly answers the user’s question and stays focused on the task.
Structure - Evaluates how well the response is aligned with common finance workflow expectations, including logical flow and prioritization of key insights.

Outputs were scored automatically using a LLM as a judge (OpenAI GPT 5.2), with evaluations grounded in predefined, operationalized rubric assertions for each metric dimension, to reduce subjective interpretation, minimize bias, and improve scoring consistency and objectivity. Dimension scores were averaged within each task area and then weighted equally across the three finance task areas to produce an overall composite score. The result is a benchmark revealing where each agent excels or needs improvement. Additional details, including methodology, metrics, and definitions are described in our GitHub repository: https://github.com/microsoft/FinanceBenchmark

Results

Results reflect testing of Finance Agent completed on May 8th, 2026, against external systems, including OpenAI’s Responses API (GPT 5.5) and Anthropic’s Claude Code CLI (Claude Opus 4.7 and Haiku 4.5). The systems were configured with tools such as a Model Context Protocol server for finance and operations apps (exposing Microsoft Dynamics 365 Finance, version 10.0.48) and evaluated using instructions and latency constraints designed to approximate finance-user workflows. Testing was performed under controlled conditions using only synthetic or controlled datasets with no customer production data. Results may not reflect all real-world scenarios and may vary depending on factors such as operating system, hardware, network connection, datasets, evaluation methodologies, and usage.

Finance Agent leads across evaluation metrics because its instructions were explicitly tuned to align with the needs of finance professionals as reflected in those metrics. Its strong performance in factual accuracy is supported by access to structured financial data sources such as MSN Money, combined with instructions optimized to effectively leverage ERP data via the MCP server for Microsoft Dynamics 365 Finance. Beyond accuracy, consistent gains in depth, citations, clarity, relevance, structure, and groundedness¹ reflect deliberate design choices to produce outputs that are transparent, easy to validate, and directly actionable within finance workflows.

Sample Queries for the three finance tasks

Below are representative examples aligned to the three Finance Agent Benchmark task areas described above. Some examples are for illustration only and are fictitious. No real association is intended or inferred.

Finance business briefs preparation:

Query: "Corporate Profile report of Microsoft"

A complete response opens with a concise executive summary - ticker, sector, headquarters, market cap, and key financial highlights - then expands into sections covering business model and lines of business, leadership, competitive positioning, financial performance (FY revenue, EBITDA, margins, EPS, YoY trends), strategic priorities, and risk factors. Accuracy requires that financial figures - market cap, revenue, employee count, leadership names and titles - match the most recent official filings; mismatches on CEO identity or key metrics count against the score. Depth requires each section to be backed by a specific, traceable source, with gaps explicitly acknowledged rather than papered over with approximations. Structure is evaluated on whether the response leads with the most critical facts, uses a clear heading hierarchy, and is organized for a finance professional to use without reformatting.

Entity financial obligations with the user company research:

Query: Of the customers in Group 90 in USMF that have past due balances for more than 90 days, what are the top 10 based on past due balances as of March 2, 2026?

A correct response identifies the top 10 customers in USMF customer group 90 with balances past due more than 90 days, ranked in descending order: The Phone Company (SYNCUS-0025, $182,539.15), Northwind Traders Europe (SYNCUS-0327, $173,961.25), Fourth Coffee Pro (SYNCUS-0629, $171,810.59), A. Datum Retail (SYNCUS-0477, $169,758.98), Northwind Traders (SYNCUS-0019, $167,513.61), City Power & Light Europe (SYNCUS-0985, $166,496.40), Adventure Works Americas (SYNCUS-0282, $166,147.50), Adventure Works Europe (SYNCUS-0310, $166,057.25), Tailspin Toys Global (SYNCUS-0919, $165,614.07), and Coho Vineyard & Winery Wholesale (SYNCUS-0512, $158,547.55). What makes this question hard is that the agent must apply two independent filters simultaneously — customer group 90 and the 90-day aging threshold — before ranking, and most AR aging tool calls return all customers or all aging buckets; a model that omits either filter will pull the wrong population entirely. Completeness is the primary accuracy signal: group 90 has many customers, several with large balances that sit in younger aging buckets and therefore don't qualify, so including a near-miss or dropping a true top-10 entry both count as failures. Arithmetic precision matters at the margin — the 10th entry ($158,547.55) is close to several non-qualifying customers, so off-by-one errors in filtering or sorting will swap the right answer out. Depth rewards responses that go beyond the ranked list to note the aggregate past-due exposure across the 10 accounts, flag that the top entries have balances nearly 15% larger than the 10th, and observe whether the concentration is in a small number of accounts or spread evenly. Structure requires each entry to include the account ID alongside the name and balance in a table or consistent list — IDs are essential for unambiguous identification since several customer names share prefixes (Adventure Works Americas vs. Europe).

Entity financial performance research:

Query: "Compare UnitedHealth Group and CVS Health in Medicare Advantage for 2024: membership by top five states, year-over-year growth, and how 2024 and 2025 CMS rate updates influenced their guidance and medical loss ratios. Present findings in a side-by-side table."

A complete response delivers a properly formatted side-by-side table with companies as columns, specific metrics as rows, all monetary amounts and percentages to two decimal places, and explicit as-of dates for enrollment figures. Accuracy requires state-level membership counts - not just a ranked list of states - and actual FY2024 medical loss ratios cited from GAAP filings or earnings releases rather than approximate ranges from secondary sources. Depth requires the CMS rate narrative to be specific to each company's guidance and MLR, with gaps flagged where data was unavailable rather than implied complete. Structure is evaluated on whether the table is well organized and easy to interpret, the summary synthesizes rather than restates the table, and the CMS rate analysis is distinct prose - not collapsed into table cells.

¹Groundedness is inherently difficult to evaluate for the external AI agents because they only partially return retrieved sources they used for answering queries. While we attempted to reconstruct those sources for offline evaluation, we were not able to consistently achieve complete coverage.

Event Guide - Digital Workplace Conference 2026 - Melbourne, Australia

HeatherCook — Wed, 27 May 2026 09:57:19 GMT

Join us in Melbourne for the Digital Workplace Conference 2026 — Australia's premier in-person event for Microsoft 365 professionals, business leaders, power users, and technical roles. Across two packed days at the Sofitel Melbourne on Collins, you'll connect with industry leaders, customers, and peers shaping the future of digital work, with deep dives into Microsoft 365, AI, Copilot, SharePoint, governance, and real-world adoption.

Huge shoutout to event founder and producer Debbie Irelandand the team at Digital Workplace Results (DWR). DWR has delivered 35+ events across Australia, New Zealand, and Southeast Asia since 2009 — thank you for the partnership, your passion for community, and the welcoming home you create for this industry every year. Microsoft is proud to sponsor this event and join the incredible community of sponsors supporting it.

We're grateful for everyone in this community who brings their energy and expertise to make DWC a must-attend highlight on the Australian tech calendar.

DWC 2026 at a glance

What	Digital Workplace Conference 2026 — Australia's premier Microsoft 365 conference
Where	Sofitel Melbourne on Collins, Melbourne, Australia
When	Thursday 28 and Friday 29 May 2026
Theme	One Change. Big Impact
Format	In-person, 2-day conference with 3 parallel tracks and an exhibition area
Speakers	30+ speakers from 5 countries — Microsoft, MVPs, customers, and partners
Audience	M365 power users, business leaders, IT pros, adoption and change managers

Theme: One Change. Big Impact — the idea that the right single change, well chosen and well executed, can transform how an organisation works.

Follow along: #DWCAU | Digital Workplace Conference

Be part of what's next

Get ready for what's next and learn what you can put into action today. With Microsoft program managers, Microsoft MVPs, customers, and partners all in one place for two days, you'll choose from sessions and case studies led by the experts who build and implement these tools every day. DWC is sized so that you can actually meet the speakers, ask hard questions, and leave with practical answers.

By the numbers:

30+ speakers

247+ combined years of digital workplace experience

5 countries represented • 3 parallel tracks • 2 days • 1 community

Three themes shaping the agenda

Productivity

Using the tools you already have to deliver more ROI. Discover what you didn't know was possible, and learn to work smarter, not harder.

AI and Copilot

Everything from governance to implementation to adoption. Move from novice to expert and understand the tools, the agents, and the reasons why.

Customer Journeys

We learn best by hearing how others did it — the trials, the tribulations, and the lessons you can take back to your own projects.

Keynote: From AI Hype to Everyday Impact

Conference Opening and Welcome: Debbie Ireland reveals how AI is quietly reshaping our behaviour, our workplaces, and even our children. From rising dependency to hidden cognitive shifts, this talk challenges audiences to rethink what it means to stay human in an AI‑saturated world.

Heather Cook shares a Humans‑First approach to adopting and using AI, building habits that drive confidence, productivity, and meaningful impact at work. Learn how individuals and teams can turn Microsoft 365 Copilot into a practical, trusted part of their daily workflow.
Brett Gilbertson presents a critical look at how AI is reshaping education—and where it falls short. This is a call to prioritize digital skills training focused on human relationships and future needs.

For a list of all sessions and the agenda: Agenda

Building connections

Building connections at DWC is the heart of the experience. Whether you're swapping notes in the Exhibition Area, comparing prompt strategies between sessions, or sharing a drink at the Thursday networking event, every interaction is a chance to learn from peers, exchange ideas, and expand your network. From first-time attendees to seasoned MVPs, DWC is a welcoming environment where meaningful relationships and lasting collaborations begin.

#CommunityEvents #CommunityLuv #DWCAU #Melbourne

Multi-Tenant Architecture: Real Challenges and an Azure Design Walkthrough

pranav_pratik — Wed, 27 May 2026 07:00:00 GMT

Azure Multi-Tenant Architecture (B2C Scenario)

Let’s start with a reference design commonly used in Azure-based systems.

A pretty standard setup looks something like this:

Microsoft Entra External ID (Azure AD B2C) for authentication
Azure API Management as the entry layer
App Service or Functions for the compute layer
Cosmos DB or SQL for storage
Redis for caching
Service Bus for async processing
Application Insights for monitoring

If you’ve worked on Azure systems, nothing here is surprising.
On paper, this architecture is clean, scalable, and “multi-tenant ready”.

But once traffic starts flowing and tenants behave differently, things start breaking in subtle ways.

1. Tenant Context Propagation Across Services

A request doesn’t stay in one place. It moves across:
- API layer
- queues/topics
- background workers

What I’ve seen happen multiple times:

tenant ID is present in the API, but missing in async flows
background jobs process data without knowing which tenant it belongs to
logs become useless because you can’t tie actions back to a tenant

The fix is simple in theory, but often missed in implementation:

Every message should carry tenant context. No exceptions.

If you rely on “it will be available somewhere”, it won’t be, especially in distributed systems.

Ensure tenant context is explicitly carried everywhere:

public class TenantMessage { public string TenantId { get; set; } public string Payload { get; set; } }

Every message, event, and async operation should include tenant scope.

2. Data Isolation in Shared Databases

Most teams start with a shared database model with tenant-based partitioning.
It works well initially.

Problems start creeping in later:

- someone forgets to add a tenant filter in a query
- a query suddenly scans across partitions
- one large tenant starts slowing down others

A simple query like this becomes critical:

var query = container.GetItemQueryIterator<Order>( new QueryDefinition("SELECT * FROM c WHERE c.tenantId = @tenantId") .WithParameter("@tenantId", tenantId) );

The tricky part is not writing it once, it’s making sure it’s applied everywhere, every time.

3. Authorization Beyond Tenant Boundaries

At the beginning, access control is simple:

“Users can access data from their own tenant.”

But then requirements grow:

admin access
cross-tenant visibility
reporting across firms or regions

And this is where things usually get messy.

Different services start implementing their own logic, and over time you end up with inconsistent behavior.

A simple check:

public bool CanAccess(string userTenant, string resourceTenant, bool isGlobalAdmin) { if (isGlobalAdmin) return true; return userTenant == resourceTenant; }

becomes much harder to manage when duplicated across multiple services.

One thing that helps a lot here is centralizing authorization logic early.

4. Caching as a Hidden Risk

Caching is usually added later for performance.

And that’s exactly why it becomes risky.

I’ve seen scenarios where:

cached data from one tenant is returned to another
because the cache key didn’t include tenant information

Fixing it is straightforward:

public string BuildCacheKey(string tenantId, string key) { return $"{tenantId}:{key}"; }

Cache keys must always include tenant boundaries

5. Resource Contention (Noisy Neighbor Problem)

All tenants share resources:

compute
database throughput
messaging

What happens in practice:

one high-load tenant impacts others
latency becomes unpredictable
system behavior differs per tenant

You start adding controls like:

if (RequestsPerTenant[tenantId] > 100) { return StatusCode(429); }

And gradually move towards:

throttling
workload isolation
prioritization

This is less of a design problem and more of an operational reality.

6. Observability in Multi-Tenant Systems

Logging works great, until you scale.

Then suddenly:

logs from all tenants are mixed
debugging becomes slow
it’s hard to answer basic questions like “which tenant failed?”

A small change makes a huge difference:

_logger.LogInformation( "Tenant={TenantId} Action=ProcessOrder OrderId={OrderId}", tenantId, orderId );

It sounds obvious, but it’s often inconsistent across services.

7. Backup and Restore Considerations

Taking backups is easy.

Restoring a single tenant isn’t.

In most shared database setups:

restore is done at database level
which affects all tenants

So if one tenant has a problem, recovery is not straightforward.

This is one of those areas where decisions made early in design matter a lot later.

Final Thoughts

Designing a multi-tenant system is not just about choosing Azure services.

The real challenges come from:

how tenant context flows
how isolation is enforced
how systems behave under uneven load

Most issues don’t show up on day one.
They appear gradually as tenants grow, scale, and behave differently.

References and Further Reading

If you want to explore these concepts in more depth, here are some useful official resources:

Hybrid AI Agents in Python: Routing Between Foundry Local and Microsoft Foundry

Lee_Stott — Wed, 27 May 2026 07:00:00 GMT

Why hybrid, and why now

If you build AI features today, you are caught between three forces. Users want low latency and strong privacy. Product teams want frontier reasoning capability. Finance teams want predictable cost. No single model satisfies all three. Run everything on a small on-device model and you bottleneck on complex questions. Send everything to a frontier cloud model and you pay for trivial requests, leak sensitive data across a network boundary, and add hundreds of milliseconds of latency to greetings.

The pragmatic answer is hybrid inference: a lightweight local model classifies every request first, simple or sensitive ones stay on the device, and only the genuinely hard or frontier-capability requests escalate to the cloud. Microsoft now ships both halves of that pattern as supported Python SDKs — foundry-local-sdk for on-device inference and azure-ai-projects for Microsoft Foundry cloud models. This post walks through a working reference implementation that combines them behind a single ask() call.

The full source is at github.com/leestott/fl-mixedmodel. It is Python-only, secretless by design, and ships with a Gradio diagnostics UI, a CLI demo mode, and a full pytest suite.

The contract: one schema, two paths

The most important architectural decision is that callers never know which path served a request. Every response, local or cloud, returns the same dataclass:

class InferencePath(str, Enum):
    LOCAL = "local"
    CLOUD = "cloud"
    LOCAL_FALLBACK = "local_fallback"   # cloud attempted, fell back to local
    CLOUD_FALLBACK = "cloud_fallback"   # local attempted, fell back to cloud

@dataclass
class AgentResponse:
    answer: str
    path: InferencePath
    model: str
    reason: str
    confidence: float
    latency_ms: float
    correlation_id: str
    prompt_tokens: Optional[int] = None
    completion_tokens: Optional[int] = None
    fallback: bool = False
    fallback_reason: Optional[str] = None
    metadata: dict = field(default_factory=dict)

This is what makes the design honest. The router can change, the cloud model can be swapped from gpt-4o to gpt-5.4, fallback policies can flip — and the calling code never breaks. The four InferencePath values give you full observability without leaking implementation details into the API surface.

Architecture in one diagram

┌─────────────┐   prompt    ┌──────────────────────────┐
│   caller    │ ──────────► │   HybridAgentService     │
└─────────────┘             │      .ask(prompt)        │
                            └────────────┬─────────────┘
                                         │
                            ┌────────────▼─────────────┐
                            │     RoutingPolicy        │
                            │  1. Heuristic gate       │
                            │  2. Local router LLM     │
                            │  3. Hard policy gates    │
                            └─────┬─────────────┬──────┘
                                  │             │
                          LOCAL  ◄┘             └► CLOUD
                                  │             │
                       ┌──────────▼──┐   ┌──────▼───────┐
                       │ Foundry     │   │ Microsoft    │
                       │ Local SDK   │   │ Foundry      │
                       │ (phi-4-mini)│   │ (gpt-5.4)    │
                       └─────────────┘   └──────────────┘

Best practice: the two-stage router pattern

Before walking through the implementation, it is worth stating the design pattern explicitly, because it is the part that generalises beyond this specific repo. The cleanest design for hybrid inference is a two-stage router.

Stage 1 — local router. A small local model performs intent and complexity classification first. It does not answer the question; it decides where the question should go.
Stage 2 — route the answer.
- If the prompt is simple, private, latency-sensitive, or clearly within local capability, route to a local task model on the device.
- If the prompt is complex, needs deeper reasoning, a larger context window, or a capability unavailable locally, escalate to a cloud frontier model in Microsoft Foundry.

Microsoft's current guidance for the cloud side is to use the Responses API and choose one of two control modes:

Pass a specific deployment name (for example gpt-5.4) when you want deterministic control over which model serves the request, which is the right choice for regulated workloads, repeatable evaluations, or cost ceilings.
Pass model-router as the deployment when you want Microsoft Foundry to automatically select the best available cloud model for each request. This is a sensible default for general-purpose agents where you would rather let the platform optimise the model choice as new ones are released.

The reference repo exposes both as environment variables so you can switch without code changes:

# .env.example
FOUNDRY_CLOUD_MODEL_DEPLOYMENT=gpt-5.4        # deterministic
FOUNDRY_CLOUD_ROUTER_DEPLOYMENT=model-router  # auto-select

Best practice: pin the right SDK versions

Two SDKs do the heavy lifting and both have had recent breaking changes, so version discipline matters.

Local development — foundry-local-sdk. The current public guidance is to use the Foundry Local SDK package foundry-local-sdk, which provides model discovery, download, cache, load, unload, chat completions, embeddings, audio transcription, and an optional built-in web service. Use version 1.1.0, released on 5 May 2026. Earlier versions used an OpenAI-compatible client surface that has since been replaced by the FoundryLocalManager → load_model → get_chat_client → complete_chat chain shown above. Pin it explicitly:
```
# requirements.txt
foundry-local-sdk>=1.1.0
```
Cloud orchestration and agents — azure-ai-projects. For cloud-side orchestration, Microsoft's current Python guidance is to use azure-ai-projects, which the docs describe as part of the Microsoft Foundry SDK and as the entry point for agents, deployments, connections, datasets, evaluations, and an OpenAI-compatible client returned by get_openai_client(). The current PyPI listing shows azure-ai-projects 2.1.0. Pin it explicitly:
```
# requirements.txt
azure-ai-projects>=2.1.0
azure-identity>=1.17.0
```

If you find yourself reading old samples that import azure.ai.inference as the cloud entry point, or that initialise Foundry Local through a raw openai.OpenAI(base_url=...) client, you are looking at pre-2026 patterns. The current shape is what the reference repo uses: FoundryLocalManager.initialize(Configuration(...)) for the device and AIProjectClient(...).get_openai_client() for the cloud.

Stage 1: a deterministic privacy gate

Before any model touches a prompt, a deterministic heuristic classifier scans for sensitive patterns — passwords, API keys, SSN/NHS numbers, PII signals, explicit "do not share" flags. If the heuristic returns PrivacyClass.RESTRICTED, the prompt is forced local. The router LLM is not called. The cloud provider is not called. The decision is auditable from a single regex pass.

# app/routing/policy.py
def decide(self, prompt: str, correlation_id: str = "") -> RoutingDecision:
    hint, privacy, complexity, h_reason = self._heuristic.classify(prompt)

    # Hard gate: restricted content never leaves the device
    if privacy == PrivacyClass.RESTRICTED:
        return self._make_decision(
            target=RouteTarget.LOCAL,
            confidence=1.0,
            reason=f"Policy hard-gate: {h_reason}",
            privacy=privacy,
            complexity=complexity,
            deterministic=True,
            correlation_id=correlation_id,
        )

    # Hard gate: very high complexity always goes to cloud
    if complexity == ComplexityBand.VERY_HIGH:
        return self._make_decision(
            target=RouteTarget.CLOUD,
            confidence=1.0,
            reason="Policy hard-gate: very_high complexity requires frontier model",
            ...
        )

This is the most important responsible-AI control in the whole system. If your privacy review depends on an LLM correctly classifying every prompt, you do not have a privacy control — you have a probability distribution. Deterministic gates first, model judgement second.

Stage 2: a local LLM as the router

For everything that passes the privacy gate, a small local model classifies whether the prompt needs frontier capability. This is the bit that surprises most engineers: you can do useful routing with a 4B parameter model running on a laptop CPU. The router does not need to answer the question. It only needs to classify it.

The reference implementation uses phi-4-mini via Foundry Local. Initialising it is two lines:

# app/providers/local_provider.py (excerpt)
from foundry_local import FoundryLocalManager
from foundry_local.models import Configuration

self._manager = FoundryLocalManager.initialize(
    Configuration(app_name="hybrid-agent")
)
self._router_model = self._manager.load_model(self._config.local_router_alias)
self._chat_client  = self._router_model.get_chat_client()

response = self._chat_client.complete_chat(
    messages=[
        {"role": "system", "content": ROUTER_SYSTEM_PROMPT},
        {"role": "user",   "content": prompt},
    ],
)

The router prompt asks for a strict JSON response: { "target": "local|cloud", "confidence": 0.0-1.0, "complexity": "low|medium|high|very_high", "reason": "..." }. The application parses it, applies the confidence threshold from config (default 0.6), and falls back to the heuristic decision if the router LLM is unsure or its JSON is malformed. The router never blocks the answer path — that is a deliberate reliability choice.

Cloud inference via Microsoft Foundry

When the policy returns RouteTarget.CLOUD, the request goes through AIProjectClient, which gives you an openai.OpenAI-compatible client wired to your Foundry project with DefaultAzureCredential. No API keys. No secrets in .env.

# app/providers/cloud_provider.py (excerpt)
from azure.ai.projects import AIProjectClient
from azure.identity import DefaultAzureCredential

self._project = AIProjectClient(
    endpoint=self._config.foundry_project_endpoint,
    credential=DefaultAzureCredential(),
)
self._openai_client = self._project.get_openai_client()

response = self._openai_client.chat.completions.create(
    model=self._config.foundry_cloud_model_deployment,  # e.g. "gpt-5.4"
    messages=messages,
    max_completion_tokens=max_tokens,
)

A subtle gotcha worth flagging: gpt-5 and o-series deployments reject the legacy max_tokens parameter and require max_completion_tokens. They also reject custom temperature values. The reference repo handles this by trying the new parameter first and falling back to the legacy one only when the API returns the specific unsupported parameter error. That keeps the same code working against older deployments without forking the provider.

Graceful degradation: the fallback paths

Hybrid systems fail in interesting ways. The cloud can be down. The local model can throw because the GPU ran out of memory. A reasoning model can return an empty completion. The service handles all of these by attempting the alternative path and labelling the response so observability stays honest:

Cloud route fails → local fallback. The response carries path=LOCAL_FALLBACK, fallback=true, and a populated fallback_reason. The user gets an answer instead of an error.
Local route fails → cloud fallback, but only if privacy class is not RESTRICTED. A sensitive prompt that the local model could not handle never leaks to the cloud as a fallback. It returns a clear error instead. This is the second hard gate in the system.
Both fail. A structured error response with a correlation ID, never a stack trace.

That last rule — fallback respects privacy class — is the kind of decision that is easy to skip and impossible to bolt on later. Encode it once in the service layer and your privacy reviewers will thank you.

What it looks like in practice

The diagnostics panel in the Gradio UI shows the routing decision live: path, model, confidence, latency, privacy class, complexity band, and the full JSON response. Five canonical scenarios shake out the entire decision tree:

"hello" → path=local, confidence=1.0, complexity=low. Heuristic only. No router LLM call. ~3 seconds end-to-end with phi-4-mini cached.
"explain transformer self-attention in depth with maths" → path=cloud, model=gpt-5.4, complexity=high. Router LLM classifies, hard gate confirms.
"my password is hunter2, suggest a stronger one" → path=local, privacy=restricted, deterministic=true. Privacy gate fires before any model sees it.
"summarise this 8 KB document" with cloud unavailable → path=cloud_fallback (local handles it, response is labelled).
Complex prompt with local model error → path=local_fallback, fallback_reason populated.

You can reproduce all five without any models installed by running python -m app.main --demo. The demo mode swaps the providers for deterministic stubs so you can validate the routing logic and the response schema in under a second on any machine.

Operational lessons learned

Some things the reference implementation only gets right because it got them wrong first:

Pick a non-reasoning model for the router. Reasoning-tuned local models (Phi-4-reasoning, o-style) wrap their output in <think> blocks and blow your JSON parser. phi-4-mini is faster and more reliable for classification.
Cache the local model. First load can take 30–60 seconds while Foundry Local downloads weights. Initialise the service once at process startup, not per request.
Use correlation IDs everywhere. The service attaches one per request and the structured JSON logger emits it on every event. When you are debugging a fallback path across two model providers, this is the difference between five minutes and five hours.
Run the privacy heuristic on every fallback path too. A naive implementation might route locally, fail, and then send the same sensitive prompt to the cloud as a "graceful" fallback. That is not graceful, it is a data leak.
Keep configuration in .env and out of code. Privacy mode, fallback toggles, confidence threshold, model aliases — all environment-driven. The config.py module is the only place that reads them.

Responsible AI in a hybrid topology

Hybrid does not make responsible AI harder, but it does make it different. Three controls earn their keep:

Data residency by default. The local path keeps prompts and answers on the device. For RESTRICTED content this is mandatory; for everything else it is a free latency and cost win.
Auditability. Every routing decision is logged with the deterministic reason, the heuristic class, the router LLM output, the confidence, and the correlation ID. You can answer "why did this prompt go to the cloud?" months later.
Keyless auth. DefaultAzureCredential means there is no API key to leak, rotate, or commit by accident. The repo's .gitignore, SECURITY.md, and pre-push checklist enforce this end-to-end.

Try it

Five minutes, no Azure account needed for the demo:

git clone https://github.com/leestott/fl-mixedmodel.git
cd fl-mixedmodel

python -m venv .venv
.venv\Scripts\activate          # Windows
# source .venv/bin/activate     # macOS / Linux

pip install -r requirements.txt
python -m app.main --demo       # all five scenarios, no models required

To run with real models, install Foundry Local, copy .env.example to .env, set your FOUNDRY_PROJECT_ENDPOINT, then:

az login
python -m app.main --ui --port 7860

Where to go next

Repository: github.com/leestott/fl-mixedmodel — full source, tests, specification, screenshots.
Foundry Local SDK: pypi.org/project/foundry-local-sdk and the Foundry Local docs.
Azure AI Projects SDK: pypi.org/project/azure-ai-projects and the Microsoft Foundry docs.
Azure Identity: DefaultAzureCredential reference.
Phi-4-mini: Phi-4-mini on Hugging Face.

Key takeaways

The best-practice pattern is a two-stage router: local model classifies first, then either a local task model or a Microsoft Foundry cloud model answers.
For cloud control, use the Responses API with either a named deployment (deterministic) or model-router (auto-select).
Pin foundry-local-sdk >= 1.1.0 (5 May 2026) and azure-ai-projects >= 2.1.0. The 2026 SDK surfaces are not backwards-compatible with pre-2026 samples.
Hybrid inference is a routing problem, not a model problem. A small local model is enough to classify the request.
Deterministic privacy gates beat probabilistic ones. Code the rules; let the LLM judge only what is left.
Return the same response schema from every path. Label fallbacks honestly. Carry a correlation ID everywhere.
Keep auth keyless with DefaultAzureCredential and your .env out of git.
Test the routing decisions, not just the model outputs. Demo mode and a strong pytest suite pay back every time you swap a model.

Hybrid AI is not a compromise between local and cloud. It is the supervisor pattern applied to inference — fast and private where you can be, frontier where you have to be, observable everywhere. The hard part is the contract, not the models.