rss.livelink.threads-in-node

Partner Blog | Time to market wins: Building the Frontier partner practice

JillArmourMicrosoft — Mon, 18 May 2026 17:30:00 GMT

Customers are clear about what they want from AI now. They want to move from ideas to outcomes faster, and at enterprise scale. The experimentation phase is giving way to production expectations, and time to market is becoming a competitive advantage in how organizations transform.

That shift creates opportunity for AI practice leaders in services partner organizations. Partners who can repeatedly take agentic solutions from concept to production, while addressing governance and security considerations, can earn a bigger role in customers’ most critical transformation work.

Earlier this spring, Nicole Dezen shared the direction for our partner ecosystem, including our framework for Frontier Transformation and updates to the Microsoft AI Cloud Partner Program, such as the Frontier Partner specialization. This blog is the follow-up, with clear guidance on how to build the partner business behind Frontier Transformation and how to position your practice to win on time to market.

Move confidently from pilots to production

AI has moved from experimentation to real-world impact. Customers are transforming business processes, products, and employee experiences with AI, and they expect solutions that operate reliably in the real world. That means production-grade delivery, governance, and the ability to scale.

continue reading here

Launched: Microsoft 365 Adoption Hub Redesign

Karuana_Gatimu_MSFT — Mon, 18 May 2026 17:11:51 GMT

Driving successful adoption of Microsoft 365 Copilot is both art and science. This community is dedicated to taking your feedback and continuing to provide tools that support you in that role.

Today we've done just that with the first release of our updated Microsoft 365 Copilot adoption hub that simplifies the experience and provides content for AI business users, AI Champions and AI Leaders. Explore the content and let us know your thoughts.

This builds on our original hub and also our Essentials of Copilot Adoption experience that was previously launched. We will continue to enhance this hub with content for Copilot Cowork and agent building tools over the coming weeks.

Advanced content like our Copilot Success Kit remains as well as technical guidance for IT Professionals in the advanced guidance section. We also continue to provide information about upcoming events and connections to our communities.

Of special interest to AI Champion leaders will be our redesigned Prompt Gallery which will now open a selected prompt directly in the person's Microsoft 365 Copilot experience so they can directly get work done. Filters by functional area, product and task are also included.

Prompt Gallery on Microsoft 365 Copilot adoption hub

Check out our launch blog, visit the site and share with your colleagues. We will also review this in our June Microsoft 365 Champion call. If you aren't signed up for our monthly calls where we review the roadmap, share tools and learning specific to adoption and share our content for you to reuse then visit this page to register today.

As always we value your feedback. Let us know how we are doing at aka.ms/amc/feedback.

EVENT | Drive Frontier Transformation: Attend the engineer summit and work toward your badge

JillArmourMicrosoft — Mon, 18 May 2026 17:07:06 GMT

Accelerate your capabilities delivering Frontier Transformation with two exciting opportunities: the Frontier Transformation Engineer badge and the Frontier Transformation Engineer Summit.

The Frontier Transformation Engineer badge validates your expertise in building AI agents across the Frontier stack, which includes Microsoft Foundry, Microsoft Copilot Studio, Microsoft 365 Copilot, GitHub Copilot, Microsoft Fabric, and Agent 365. This applied skilling journey equips solution engineers and architects to design, build, and operate production-ready agentic AI solutions—so you can lead customers from AI experimentation to secure, real-world agentic implementation. Earn the badge through certifications, project-ready execution, and advanced training.

As you work toward the badge, join us for the Frontier Transformation Engineer Summit on June 9, a live, expert-led skilling experience designed to fast-track badge completion. Gain insights on how to use Microsoft Agent Factory at scale, building individual expertise, showcasing organizational readiness, and leading Frontier Transformation for your customers.

These are exciting opportunities to drive Frontier Transformation—both for your organization and for customers who are looking to adopt agentic AI at scale. And as we get ready to enter FY27, the year of Frontier Transformation, we strongly encourage you to join us at MCAPS Start for Partners on July 22. You'll get insights from Microsoft leaders on where we’re investing, our shared priorities, and how to activate AI-led opportunities to drive growth this year.

Say goodbye to planning bottlenecks with Microsoft Azure Migrate

JillArmourMicrosoft — Mon, 18 May 2026 17:00:00 GMT

Every migration starts with the same questions: what do we have, and where should it go? Getting from those question to a clear, execution-ready answer has historically taken weeks. From exporting spreadsheets and manually classifying workloads to running assessments, conducting cost analyses, and stitching everything together into a deck that feels outdated by the time it's presented, the process slows teams and even limits pipeline.

Azure Migrate collapses that entire process into a single workflow—reducing migration planning from weeks to hours.

How to get started with Azure Migrate

Start with Azure Migrate Collector to scan a customer's entire IT estate offline, enrich the inventory with tags and application groupings, and generate a stakeholder-ready Microsoft PowerPoint presentation with migration and modernization recommendations. The output includes lift-and-shift options, security posture guidance, and cost insights so you can move from assessment to customer conversation faster.

Follow these steps for a speedy migration planning process:

Set up Collector: Download and configure the Azure Migrate Collector on a Windows Server in your datacenter.

Choose your discovery method: Compare Collector, appliance, and import-based approaches for your scenario.

Tag your workloads: Follow tagging best practices for accurate recommendations.

Organize applications: Define and manage applications from your discovered inventory.

Generate your report: Build an Azure Migrate report and export to PowerPoint.

Dive deeper: View application assessments for application and workload-level migration plans.

From discovery to execution, this repeatable workshop-to-deck motion is built to empower partners to streamline their migration and modernization planning. Start exploring Azure Migrate and learn how to turn weeks of manual research and planning into more time for customer outreach and efficiency that expands your pipeline.

Start exploring Azure Migrate today

Launched: Microsoft 365 Copilot Adoption Hub Redesign

Karuana_Gatimu_MSFT — Mon, 18 May 2026 16:45:25 GMT

One of the biggest barriers to Copilot adoption is people don’t always know where to start.

Today, we released the first version of our redesigned Microsoft 365 Copilot business user hub. Take a look.

We set out to simplify adoption by making the experience more practical and focused on key roles: AI Business User, AI Champion and AI Leader.

Microsoft 365 Copilot adoption hub

What you’ll find:

Prompts you can apply immediately in your work.
• Real examples of how Copilot helps across tasks.
• Clear guidance based on your role.

What's the same:

Connection to what’s new, communities and event information.
Advanced guidance for User Enablement and IT Professionals.
Content from Microsoft Learn to advance your skilling through the AI Skills Navigator and learning paths for certification.

Your feedback was essential in crafting this evolution of how to learn and use AI experiences from Microsoft. Keep sharing your insights via our feedback form at aka.ms/amc/feedback. The entire team reads what you submit and innovates to support your needs.

That’s really the focus here; helping people get started and keep going to get work done.

We’d love your input! What do you think, and what content would you like to see us build next?

#Copilot #AIAdoption

Don’t Start Your Application Upgrade by Changing Code

PabloLopes — Mon, 18 May 2026 16:34:57 GMT

The first step of a .NET upgrade isn't code, it's assessment!

That sounds obvious, but it isn't. When somebody tells you to upgrade an app, the instinct is to open the repo, bump the TargetFramework, update a few NuGet packages, and start chasing build errors, that feels like progress, but you're working without knowing what you signed up for. As we wrote at our previous posts, the Copilot modernization agent runs in three steps: assess, plan, execute. At each step it writes a Markdown file you can read and edit before it moves forward, and this time we will deep dive to learn about the assessment step!

Look at the app before you touch it

Jeff Fritz recorded a walkthrough of the Copilot modernization agent assessing the eShop reference app, upgrading from .NET 8 to .NET 10. The interesting part isn't that it upgrades the code. It's that it doesn't, not at first. The agent runs an assessment pass first, reading the solution, walks the dependency graph, and writes a Markdown report you can actually open and read. No commits, no `.csproj` edits. Just a file.

What's in that report? In the eShop run: 10 projects that all need to move. 24 NuGet packages requiring updates, 5 of them incompatible. 52 APIs with behavioral changes that'll need testing. And every project marked "low difficulty," which tells you this particular upgrade is an afternoon, not a sprint, Knowing which project is going to be the hard one before you start changes how you plan the whole upgrade. That's what the assessment actually produced on a real codebase, and you can see it generated in about minutes with the agent running in autopilot mode in VS Code.

The order matters

The workflow the agent encourages is straightforward, first, assess the app as it is today, plan the upgrade based on what assessment found, lastly, implement the changes to modernize the app. The order is the whole point, if you jump straight to step three you discover the dependency conflicts and the missing test coverage live, while you're already mid-upgrade. By the time you find them, you're committed. You've already burned the easy rollback.

The point to do the assessment is to move all of that to the front, when it's still cheap to change your mind. The Markdown report isn't meant to sit there untouched. You can open it, edit it, add notes, mark the projects you know are fragile, assign owners, flag the services that have a release freeze next month. Turn it into something your team will actually use to run the upgrade. Remember that Copilot doesn't know that the payments service is owned by a team that's mid-reorg, or that the reporting module is the one the CFO looks at on Monday mornings. That context still has to come from you.

When you move to the planning step, the plan builds on whatever you left in that assessment. If you added constraints or flagged a project as "don't touch until Q3," that's what Copilot works from. You're setting direction, not just reviewing output.

Watch it in action

If you want to see the full assessment flow running on eShop, Fritz's video walks through it start to finish in VS Code with autopilot mode enabled: Modernize .NET Apps with GitHub Copilot!

Test with just one app you've been putting off, run the assessment, and read the Markdown file it gives you, edit the parts that need editing, and hand it around to the two or three people who actually know that codebase. See what they push back on.

Easy Auth Configuration for Logic App Standard through CI/CD

Arpit_MSFT — Mon, 18 May 2026 16:32:46 GMT

Problem Statement

When Easy Auth (Azure App Service’s built-in authentication and authorization) is enabled on a Logic App Standard, users frequently report that they cannot open the run history. Specifically, the inputs and outputs of the trigger and actions fail to load on the run details page, even though the workflow itself runs and the user has access to the resource.

Background — How Easy Auth Interacts with Logic Apps

Easy Auth is a feature of Azure App Service. Every request that reaches a Logic App Standard is first routed through the App Service layer, and only then handed off to the Logic App runtime for further processing. When Easy Auth is enabled, App Service authenticates each incoming request and decides whether it should be allowed or blocked — before the Logic App runtime ever sees it.

This dual-layer model is what causes the run-history symptom:

The Logic App runtime authenticates run-history requests using a SAS token specific to that run, generated from the Logic App access keys.
The portal calls that load the inputs and outputs of historical runs do not carry a bearer token — they carry the SAS.
Because App Service only knows how to validate Easy Auth tokens (not SAS), it blocks these requests whenever unauthenticatedClientAction is set to disallow unauthenticated traffic.
The request never reaches the runtime, so the runtime cannot apply its SAS validation, and the inputs/outputs panel stays empty.

Solution

There are two ways to fix this, depending on what your security policy allows.

Option 1 — Allow unauthenticated requests

The simplest fix is to configure Easy Auth to allow unauthenticated requests. This does not mean anyone can invoke the workflow. Instead, all calls (failed and successful) are routed through to the Logic App runtime, and the runtime decides how to handle them:

A workflow trigger call with no token → the runtime applies its own auth (SAS, AAD, etc.) and rejects unauthorized invocations.
A run-history call carrying a valid SAS → App Service marks it as “failed Easy Auth” but still forwards it; the runtime sees the valid SAS and returns the data.

The underlying App Service platform has no knowledge of SAS or any other Logic-App-specific auth scheme, so letting the runtime arbitrate is what makes the run-history experience work.

Option 2 — Keep Easy Auth strict, but exclude the runtime paths

In many enterprises the security team will not permit “Allow unauthenticated requests.” For those cases, you can leave authentication required but add the runtime endpoints to the excludedPaths list, so App Service skips Easy Auth specifically for those calls. The Logic App runtime continues to authenticate them via SAS.

Important: The Azure portal lets you toggle Easy Auth, but it does not expose the excludedPaths setting. You must configure it through ARM, Bicep, the REST API, or CLI — which is exactly why this needs to live in your CI/CD pipeline.

There are two ways to apply this through CI/CD.

Approach 1 — ARM Template (`Microsoft.Web/sites/config`)

Add a Microsoft.Web/sites/config resource of type authsettingsV2 to the same ARM template that deploys the Logic App. Below is the sample template:

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "parameters": {
    "logicAppName": { "type": "string" },
    "location":     { "type": "string", "defaultValue": "[resourceGroup().location]" },
    "tenantID":     { "type": "string" },
    "ClientID":     { "type": "string" }
  },
  "variables": {},
  "resources": [
    {
      "type": "Microsoft.Web/sites",
      "apiVersion": "2022-03-01",
      "name": "[parameters('logicAppName')]",
      "location": "[parameters('location')]",
      "kind": "functionapp,workflowapp",
      "identity": { "type": "SystemAssigned" },
      "properties": {
        "serverFarmId": "<App Service Plan ID>",
        "siteConfig": {
          "appSettings": [
            { "name": "FUNCTIONS_EXTENSION_VERSION", "value": "~4" },
            { "name": "FUNCTIONS_WORKER_RUNTIME",    "value": "dotnet" },
            { "name": "AzureWebJobsStorage",         "value": "<Storage Account Connection String>" },
            { "name": "APP_KIND",                    "value": "workflowApp" }
          ]
        },
        "httpsOnly": true
      }
    },
    {
      "type": "Microsoft.Web/sites/config",
      "apiVersion": "2021-02-01",
      "name": "[concat(parameters('logicAppName'), '/authsettingsV2')]",
      "location": "[parameters('location')]",
      "properties": {
        "platform": {
          "enabled": true,
          "runtimeVersion": "~1"
        },
        "globalValidation": {
          "requireAuthentication": true,
          "unauthenticatedClientAction": "Return401",
          "excludedPaths": ["/runtime/*"]
        },
        "identityProviders": {
          "azureActiveDirectory": {
            "enabled": true,
            "registration": {
              "openIdIssuer": "[concat('https://sts.windows.net/', parameters('tenantID'), '/v2.0')]",
              "clientId": "parameters('ClientID')",
              "clientSecretSettingName": "OVERRIDE_USE_MI_FIC_ASSERTION_CLIENTID"
            },
            "login": { "disableWWWAuthenticate": false },
            "validation": {
              "jwtClaimChecks": {},
              "allowedAudiences": [],
              "defaultAuthorizationPolicy": {
                "allowedPrincipals": {},
                "allowedApplications": ["<LIST OF ALLOWED APPLICATIONS ID>"]
              }
            }
          }
        }
      },
      "dependsOn": [
        "[resourceId('Microsoft.Web/sites', parameters('logicAppName'))]"
      ]
    }
  ],
  "outputs": {}
}

Key things to notice in the template:

requireAuthentication: true and unauthenticatedClientAction: Return401 keep Easy Auth strict for the public surface.
excludedPaths: ["/runtime/*"] carves out the runtime endpoints so the SAS-authenticated run-history calls aren’t blocked.
allowedApplications lets you whitelist specific AAD app IDs that are allowed to call the workflow.

Reference: Microsoft.Web/sites/config — authsettingsV2 (ARM template) · Bicep variant

This is the easiest way to add or update Easy Auth on a new or existing Logic App.

Approach 2 — REST API call as a post-deployment pipeline step

If you’d rather keep your infra template lean (or you’re updating Easy Auth on a Logic App that already exists), add a step to your CI/CD pipeline that calls the App Service authsettingsV2 REST API after the Logic App infra deployment completes. The payload mirrors the properties block from the ARM example above — including excludedPaths: ["/runtime/*"].

This approach is useful when:

The Logic App is provisioned by a different pipeline or team than the one owning auth configuration.
You need to update Easy Auth settings without redeploying the site.
You want to apply environment-specific values (tenant ID, client ID, allowed application list) at release time rather than template-compile time.

Reference: Web Apps - Update Auth Settings V2 - REST API (Azure App Service) | Microsoft Learn · GlobalValidation

Summary

The “inputs/outputs don’t load on run history” symptom after enabling Easy Auth is caused by App Service blocking SAS-authenticated runtime calls before the Logic App runtime can see them.
Either allow unauthenticated requests (and let the runtime do all the auth), or keep Easy Auth strict and exclude /runtime/*.
Because the portal doesn’t expose excludedPaths, the production-grade fix is to deploy it through CI/CD — either by adding an authsettingsV2 config resource to your ARM template or by calling the App Service auth REST API as a pipeline step after deployment.

State Explosion Security Problem in AI-Era Software Supply Chains

nirwandogra — Mon, 18 May 2026 16:08:17 GMT

Introduction

To see why this problem scales so quickly, start with the smallest possible change: a single line of code. In modern software, even a tiny edit is rarely just a local modification. It can change execution flow, introduce a new dependency, expose sensitive data, or quietly shift the purpose of the package itself. What looks trivial in a diff can create a materially different security outcome. That is why supply chain defenders cannot afford to treat small code changes as small security events.

How a Single Line Changes Package Intent

Every software package exists in a particular state at a particular moment in time. Imagine a benign version — State X — that behaves exactly as intended. Now add one line of code. That small edit can shift the package into a new state with different behavior and, potentially, a very different risk profile.

The security issue is not the added line by itself. It is the fact that the package now has to be interpreted differently. A tiny diff can change the role of the entire component, which means defenders have to reason about the resulting behavior, not just the textual change.

That is why file-level scanning breaks down so quickly. A change in one file can alter the behavior of the entire package because software semantics emerge from how components interact. Security systems therefore need to analyze packages as composed systems, not as a series of isolated file edits.

Why the whole package matters

This matters even more in modern supply chain attacks, where malicious intent is rarely concentrated in one obvious file. More often, the behavior is distributed across several files that look harmless when viewed independently.

File A defines an encoded string constant. Looks like a config value.

File B provides a decode function. Looks like a utility.

File C (setup.py / postinstall) imports both, decodes, and executes.

Viewed independently, each file may appear benign. No single file has to trigger a clear signature, rule, or heuristic. The malicious behavior only becomes visible when you reconstruct how the files interact as a system. Any scanner that evaluates files one by one without rebuilding that interaction is likely to miss the real behavior.

Why every change demands re-analysis

Every meaningful state change — a commit, pull request, version bump, or package publish — can alter the semantics of the software. That means defenders cannot stop at diff inspection or lightweight pattern matching. The real question is not only what changed, but what the software now does.

Quantifying the problem

The scale of the problem becomes clearer when you look at how many software state changes occur across the ecosystem every day:

GitHub alone recorded nearly 1 billion commits in 2025, merged an average of 43.2 million pull requests per month, and now hosts roughly 630 million repositories. In 2026, GitHub was projected to reach roughly 38 million commits per day.

npm has grown to well over 2 million packages, making JavaScript one of the largest public package ecosystems.

PyPI published more than 130,000 new projects in 2025 and more than 3.9 million new files in the same year.

NuGet serves package downloads at massive operational scale, with recent weekly totals in the 5 to 6 billion range.

Maven Central indexed more than 20 million packages and published more than 3.2 million packages in 2025.

Taken together, these ecosystems are generating an enormous stream of new software states. Some numbers describe repositories, some describe publishes, and some describe downloads, but they all point to the same reality: the scale of software movement is already massive before you even account for the acceleration from AI-assisted development.

The number of state changes is already enormous, and AI-assisted development is increasing it even further. The result is not just more code, but more package states that may require meaningful security interpretation.

Why the math breaks traditional scanning

Assume a single semantic package analysis takes 30 seconds, which is a reasonable range for LLM-based inference. Scanning 50,000 packages would require roughly 1.5 million seconds of compute time per day — about 417 hours. But the ecosystem only gives defenders 24 hours before the next wave of packages arrives. Without aggressive parallelism and purpose-built infrastructure, backlog becomes inevitable.

The scanning bottleneck

This leaves modern scanning systems with a fundamental bottleneck:

Heuristic and signature-based scanners are fast. They can match known patterns in milliseconds and work well for familiar malware families or repeated behaviors. Some systems also use emulation or detonation, but these approaches still struggle to deliver deep reasoning at ecosystem scale. That makes them easier to bypass with novel, well-structured, or AI-generated code that behaves maliciously without resembling previously known samples.

LLM-based semantic analysis can reason about intent. It can follow behavior across files, recognize obfuscated exfiltration paths, and explain why a package is suspicious even when the code appears ordinary at first glance. The tradeoff is cost, latency, and trust: inference takes seconds rather than milliseconds, and a single package may require multiple reasoning passes. At ecosystem scale, that becomes a serious infrastructure challenge.

Neither approach is sufficient on its own. Heuristics provide speed without deep understanding, while semantic models provide understanding without inherent scale. Closing the gap requires systems that combine both: package-level reasoning with the latency and throughput needed for production supply chains.

Heuristics often miss novel attacks, while LLM-based approaches remain too slow to apply inline at large scale. That gap between understanding and throughput is where supply chain malware can persist.

What needs to change

Closing that gap will require a different class of supply chain security systems. Detonation can help in some cases, but it is too slow and expensive to apply inline to every package state change. What is needed is a system that can:

Analyze entire packages as a unit — not individual files. The intent lives in the interaction between files, not within any single one.

Run semantic analysis at data-plane speed — every package, every version, on the hot path, with latency low enough for inline enforcement. Not async advisories. Not CI-time checks. Inline, before delivery.

Handle the state explosion — millions of state changes per day, each requiring full re-analysis. This is an infrastructure problem as much as a security problem: rate limiting, backpressure, connection pooling, regional failover, model versioning — the same hard distributed systems problems, with security stakes.

Maintain high accuracy under evasion — attackers deliberately use encoding, string splitting, dynamic imports, polyglot files, and similar techniques to reduce detection quality. The scanner must continue to classify packages accurately even when the code is designed to obscure intent.

The Latency-Accuracy Tradeoff: Malware Detection as an ML Problem

At cloud scale, malware detection is governed by a hard tradeoff between latency, accuracy, throughput, and cost. The fastest detectors are typically shallow: signatures, heuristics, and lightweight models can make decisions in milliseconds, but they often miss novel, compositional, or intent-level attacks. Deeper semantic analysis can improve recall and resilience against evasion, but it also increases inference time, compute cost, and operational complexity. As a result, defenders cannot optimize for accuracy in isolation; they must deliver strong detection quality within strict performance constraints.

This makes malware detection not just a cybersecurity problem, but a machine learning and distributed systems problem. In modern software supply chains, AI-assisted development increases the number of package states and enables attackers to generate variants at high speed, expanding the space defenders must reason over. The challenge is therefore to build detection architectures that preserve semantic depth while remaining fast enough for inline use at global scale.

The gap between the rate of software change and the capacity to analyze it is widening. That gap is the attack surface. If defenders cannot inspect software at the speed it is being produced and published, attackers will continue to exploit the delay.

What the industry needs now is a cloud-scale malware analysis capability that can deliver low latency, low cost, high accuracy, and the flexibility to meet different operational requirements , such as SLAs, false-positive tolerance, and enforcement policies , without compromising on package-level semantic analysis.

Agent 365 connector: Monitor, hunt, and investigate AI agent activity in Microsoft Sentinel

RGupta — Mon, 18 May 2026 16:05:15 GMT

As enterprises scale the use of AI agents, SOC teams need visibility into AI agent behavior. The Agent 365 connector, now in public preview, streams rich agent telemetry from Agent 365 into Microsoft Sentinel data lake. Agent activity, such as agent data exposure or access drift, is surfaced alongside other security data, giving SOC teams a unified view across digital environments. AI Agent actions are correlated with agent identity, endpoint, and cloud signals, enabling analysts to run end‑to‑end investigations using KQL, graph, and MCP-powered workflows.

Why this matters for organizations

By centralizing security and AI agent telemetry in Sentinel data lake, organizations establish a unified control plane for securing AI agents. This enables security teams to analyze agent activity in context with broader signals and investigate using familiar Sentinel tools. This unlocks the ability for SOCs to detect risky or anomalous agent behavior early, understand impact quickly, and respond with speed and confidence. As AI agents take on real operational responsibility, this level of visibility is critical to prevent blind spots, reduce risk, and ensure agents operate safely at enterprise scale.

End‑to‑end visibility into AI agent behavior: A centralized view of AI agent behavior allows AI agents to be treated as first-class entities alongside users, identities, endpoints, and workloads.
Advanced hunting with KQL: Hunt using KQL to proactively uncover unusual AI agent execution patterns, sensitive actions, or activity without clear human context. These hunts help surface potential risk early using the same workflows already used for other security data.
Analyzing blast radius and impact with Sentinel graph: Security teams can correlate AI agent activity with identities, endpoints, and cloud resources to understand blast radius and potential impact during an investigation. By pivoting across related entities in Sentinel, analysts can assess how agent actions connect to the broader environment and support deeper, end‑to‑end investigations.
Querying agent data through MCP: Use MCP to surface agent observability data through AI assistants, letting analysts pull agent telemetry into investigation workflows alongside other Sentinel data.

Agent 365 connector key capabilities

Install the Agent 365 connector with a single click using Sentinel Content Hub in the Defender portal. Once enabled, two capabilities come online automatically:

Unified agent telemetry across Agent 365 agent experiences: Rich Agent 365 agent telemetry streams into Sentinel data lake, ready to analyze alongside identity, endpoint, and cloud signals using familiar SOC workflows.
ASIM unified schema for AI agent observability: Agent 365 agent observability data is normalized into an ASIM-aligned schema so it is consistent, queryable, and ready for analytics and detections.

With the connector in place, Sentinel data lake becomes the system of record and the control plane for Agent 365 agent security—turning agent behavior into first-class security signals across SecOps workflows like hunting, investigation, detection engineering, and response.

Use cases

Prevent sensitive data exposure from misconfigured agents
When an AI agent is granted broader access than intended, a crafted prompt could override safeguards and expose confidential data. With agent telemetry, security teams can trace the full execution path—from prompt to tools to data access—to quickly identify the root cause and contain the exposure.

Detect and control agent access drift over time
As agents take on new tasks, their permissions can expand beyond the original scope, often without clear visibility. Agent telemetry enables continuous behavioral baselining, making it easier to spot abnormal access patterns early and prevent privilege misuse before it escalates.

Uncover hidden lateral movement across agent workflows
Agents often collaborate and delegate tasks across systems, creating complex chains of execution that are difficult to track. Agent telemetry provides visibility into these interactions, mapping delegation paths and helping teams understand and limit the potential blast radius.

Defend against prompt injection and manipulation attacks
Attackers can craft prompts to override agent instructions and manipulate behavior. By capturing prompts and reasoning flows, agent telemetry enables detection of these attacks and provides the context needed to investigate and remediate quickly.

Accelerate SOC investigations with end-to-end visibility
When an agent is involved in a security alert, understanding its actions can be challenging. Agent telemetry correlates prompts, identities, tools, and data access into a unified timeline, giving SOC teams the clarity needed to investigate faster and respond with confidence.

Strengthen governance and compliance for AI agents
Organizations need visibility into what agents exist and what data they can access. Agent telemetry provides a comprehensive audit trail of agent activity and access patterns, supporting compliance reporting and policy enforcement.

Enable proactive threat hunting on agent behavior
Security teams need to stay ahead of emerging risks as agent usage grows. Agent telemetry enables advanced hunting across agent activity, helping detect anomalies, uncover patterns, and identify threats before they impact the organization.

Get started with Agent 365 connector

Getting started is straightforward.

In the Microsoft Defender portal, navigate to Microsoft Sentinel
Open Content hub and search for Agent 365
Install the Agent 365 Connector (if not already installed)
Open the connector page and select Connect to begin ingestion

Once connected, AI agent telemetry starts flowing into Sentinel, ready for hunting, investigation, and response. Data ingestion and analytics are billed using existing Sentinel meters.

Learn more

Now in Foundry: Tongyi-MAI Z-Image-Turbo, with FLUX.1-schnell and SDXL base 1.0

Osi — Mon, 18 May 2026 16:04:58 GMT

This week's Model Mondays edition pairs three models available through the Hugging Face collection in Microsoft Foundry: Tongyi-MAI's Z-Image-Turbo, a new designed for lower latency on a single GPU and native bilingual text rendering; Black Forest Labs' FLUX.1-schnell, a 12B rectified flow transformer distilled to 1–4 step inference and one of the most adopted open-weight image models since its 2024 release; and Stability AI's stable-diffusion-xl-base-1.0 (SDXL), a latent diffusion research model that can be used to generate and modify images based on text prompts.

Models of the week

Tongyi-MAI: Z-Image-Turbo

Model Specs

Parameters / size: 6B (BF16)
Resolution: Up to 1024×1024 native
Primary task: Text-to-image generation (English and Chinese)

Why it's interesting (Spotlight)

Scalable Single-Stream Diffusion Transformer (S3-DiT) architecture: Z-Image concatenates text tokens, visual semantic tokens, and image VAE tokens into a single unified input stream rather than running text and image through separate branches. This single-stream design can improve parameter efficiency relative to dual-stream DiT architectures at the same capacity. See the Z-Image technical report for details.
8-step inference at sub-second latency, fits in 16GB VRAM: Z-Image-Turbo is distilled with Decoupled Distribution Matching Distillation (Decoupled-DMD) and further refined with DMDR, a method that fuses DMD with reinforcement learning during post-training. The result is a model that runs 8 Number-of-Function-Evaluations (NFE) per image with no Classifier-Free Guidance (CFG)—which roughly halves the per-step compute compared to CFG-based inference. See the Decoupled-DMD and DMDR papers.
Native bilingual text rendering and strong instruction adherence: Unlike most open-weight image models, which struggle with legible in-image text, Z-Image-Turbo renders complex English and Chinese text accurately which is useful for posters, signage, packaging mockups, and marketing creative.

Try it

Figure 1. Cherry cake generated by Z-Image-Turbo

Figure 2. Using the original image to create a poster for marketing material

Imagine you're a community programs coordinator at your city's parks department, planning a new summer event series — a "Cake Picnic in the Park" — designed to bring neighbors together over food in shared green space. The event is a few weeks out. You haven't booked bakery partners yet, so no actual cake exists, and you need marketing assets this week to start driving sign-ups: a hero image for the registration page, a flyer for community centers and libraries, social tiles for the city's channels. Use the prompt below and a photorealistic image, that can now be scaled to become additional assets like printed flyers or social images in minutes using image editing tools (or another model).

Prompt: A round layered cake displayed on a white ceramic cake stand, topped with glossy fresh red cherries and smooth pastel pink buttercream frosting piped in delicate rosettes around the edge. One generous slice has been cleanly cut and removed from the front, revealing a perfect cross-section: four distinct horizontal layers alternating between soft pink sponge cake and fluffy white vanilla cream frosting. Professional bakery photography, soft natural window light from the left, shallow depth of field, marble countertop, warm and inviting atmosphere, photorealistic detail on the cake texture, cherry highlights, and frosting swirls.

Black Forest Labs: FLUX.1-schnell

Model Specs

Parameters / size: 12B (rectified flow transformer)
Resolution: Flexible up to 2 megapixels
Primary task: Text-to-image generation

Why it's interesting (Spotlight)

Rectified flow transformer with adversarial distillation for 1–4 step inference: FLUX.1-schnell is the distilled, Apache 2.0 sibling of the FLUX.1 family. It uses a rectified flow formulation (a diffusion variant that learns straight-line probability paths between noise and data, reducing the number of solver steps needed) and is further compressed with latent adversarial diffusion distillation. The model generates high quality images in for latency-sensitive workloads.
Permissive licensing for commercial use: Released under Apache 2.0, FLUX.1-schnell can be used for personal, scientific, and commercial purposes. This has driven broad adoption across product features that need an open, redistributable image backbone.
Strong prompt adherence at its parameter range: At 12B parameters, FLUX.1-schnell sits between the SDXL family and frontier proprietary image models, and it remains a common reference point for evaluating open image generation prompt following—particularly for complex compositional prompts and longer captions—roughly two years after its initial release.

Try it

Hugging Face Spaces give developers the ability to experiment and try new models before deploying them. Test out a few prompts here:

https://black-forest-labs-flux-1-schnell.hf.space then when you are ready, deploy the model in Microsoft Foundry.

Stability AI: stable-diffusion-xl-base-1.0

Figure 2. Architectural diagram available here: stabilityai/stable-diffusion-xl-base-1.0 · Hugging Face

Model Specs

Parameters / size: 2.6B UNet (≈3.5B total with text encoders)
Resolution: 1024×1024 native
Primary task: Text-to-image generation

Why it's interesting (Spotlight)

Dual text encoder design and an ensemble-of-experts pipeline: SDXL uses two pretrained text encoders—OpenCLIP-ViT/G and CLIP-ViT/L—concatenated to capture both broad semantic alignment and finer-grained token-level cues. It can be run standalone or paired with the SDXL refiner in an ensemble-of-experts pipeline where the base model handles early denoising and the refiner specializes in the final steps. See the SDXL report for the original training and architecture details.
CreativeML Open RAIL++-M licensing for managed deployments: SDXL is distributed under the CreativeML Open RAIL++-M license, which permits commercial use and downstream fine-tuning with documented use restrictions.

Try it

To go deeper on SDXL, take a look at Stability AI's generative-models GitHub repository, which implements the most popular diffusion frameworks for both training and inference and continues to expand with new capabilities like distillation.

Getting started

You can deploy open-source Hugging Face models directly in Microsoft Foundry in two ways. The first by browsing the Hugging Face collection in the Foundry model catalog and deploying to managed endpoints in just a few clicks. The second way is direct through the Hugging Face Hub, select any supported model and then choose "Deploy on Microsoft Foundry", which brings you straight into Azure. Learn how to discover models and deploy them using Microsoft Foundry documentation:

Navigate changing hosting economics with the Microsoft Datacenter Optimization initiative

JillArmourMicrosoft — Mon, 18 May 2026 16:00:00 GMT

Hosting and hybrid cloud business models are under pressure as infrastructure economics change. While the full market impact will unfold through 2027, partners who begin planning now may be better positioned to protect margins, retain customers, and develop more differentiated offers across hybrid and AI‑ready scenarios.

The Microsoft Datacenter Optimization (DCO) initiative empowers you to move beyond legacy Services Provider License Agreement (SPLA)‑based operations and build a stronger, more resilient business—modernizing customer environments while unlocking new recurring revenue opportunities across Azure, hybrid, and AI‑ready services.

Learning how to navigate these changes is the first step in a multistage journey. Start with the Microsoft Hybrid Cloud Partners podcast, available on YouTube, Spotify, Apple, and Amazon. The podcast breaks down how shifting infrastructure economics are shaping the hybrid cloud landscape—and what that means for your long‑term business strategy as a partner.

This shift is about more than licensing alignment—it is about building a more resilient, differentiated, service-led business for the future. Explore additional tools and support on the Microsoft Datacenter Optimization page so you can continue to plan confidently and grow with Microsoft.

Watch the Microsoft Hybrid Cloud Partners podcast

Now available: Close deals faster and transact at scale with auto activation for SaaS subscriptions

sarahsnow — Mon, 18 May 2026 16:00:00 GMT

Auto activation for the SaaS products you sell in Microsoft Marketplace is now generally available. When turned on, subscription activation and billing for your SaaS solutions begin at purchase, removing API calls so customers get your solution, faster.

How it works

Auto activation is designed around choice. Turn it ON to streamline customer onboarding. If your solution requires validation, coordinated provisioning, or a defined go‑live moment before billing starts, manual activation may be a better fit.

You can configure this setting in Partner Center to fit how you price, bill, and fulfill your offer. Once a purchase is complete, you'll receive a real-time webhook notification confirming the completed transaction. This immediate signal allows you to trigger onboarding workflows, provision accounts, or notify internal systems without waiting for manual activation steps to resolve.

Review the documentation

Default behavior

Existing plans: Auto activation is OFF by default, you will still manually activate SaaS purchases unless you republish your offer and change the setting.
New plans: Auto activation is ON by default, with the option to turn off during offer publication if you prefer to manage manually.

Auto activation is also applicable for private offers.

By default, the private offer will use the auto activation setting of the public offer.
- Price adjustments to your SaaS plan will not affect the activation status of your private offer.

If you create a new SaaS plan with a unique plan ID for your private offer, you can explicitly turn auto activation ON or OFF.

Get started

Auto activation works best when purchase and onboarding experiences are aligned. Use it to streamline scenarios where removing billing dependencies improves time-to-value. Choose manual activation when you need more high-touch onboarding, or want to manually manage when billing starts.

Before enabling auto activation, make sure your customer messaging, documentation, and internal sales guidance reflect the updated flow. Because customer billing can start the day of activation, so clarity matters. Learn more

Help Shape the Future of Microsoft Teams for Small and Medium Businesses

MiikkaOksanen — Mon, 18 May 2026 16:00:00 GMT

Have you ever wished Microsoft Teams worked just a little better for the way your SMB customers run their business? Maybe you've thought:

“It would be great if Teams could do this…”

“This workflow would be so much simpler if…”

“Why isn’t there a feature for…?”

Now’s your chance to directly influence what comes next.

Microsoft is inviting Small and Medium Business (SMB) partners to join the Teams SMB Partner Advisory Council (PAC) — a simple, low-effort way to share real-world feedback with the product team and help shape the Teams roadmap for SMB customers.

What is Teams SMB PAC?

Our Teams SMB Partner Advisory Council (PAC) brings together a Microsoft partners who:

Work with SMB customers implementing Teams
Have insights into the challenges SMBs face when adopting collaboration tools
Want to help improve the products they rely on

Through monthly virtual sessions, participants get the opportunity to:

✅ Preview upcoming features and improvements
✅ Provide feedback during early stages of product development
✅ Share what’s working well — and what isn’t
✅ Highlight real-world business scenarios that should be better supported
✅ Influence priorities for SMB-focused innovation in Teams

This isn’t a sales call or a support channel — it’s a direct line to the Teams product team.

What’s the Commitment?

We know you are busy.

That’s why participation is designed to be:

Flexible – Virtual meetings combined with async conversation
Low effort – No prep required for most sessions
Conversational – Small-group discussions, not presentations

Most sessions are informal and focused on understanding how Microsoft can better support you and your SMB customers.

Your input helps ensure we build features that reflect how SMBs actually work — not just how software assumes they do.

Why Join?

Participants often tell us that one of the biggest benefits of joining the PAC is the opportunity to:

Get early visibility into what’s coming next
Understand where Teams development is headed
Provide feedback that directly reaches the team building the product
Help shape experiences that impact SMB customers worldwide

Your perspective matters — and it can directly shape the future of Teams for SMB.

Trusted by partners across regions including EMEA, APAC, and North America.

Interested in Participating?

If you'd like to be considered for the Microsoft Teams SMB Partner Advisory Council, simply fill out this short interest form:

👉 Express your interest to join the Teams SMB Advisory Board

Once submitted, our team will review your response and follow up with more information on next steps.

You Can Scale MCP Servers Behind a Load Balancer on App Service — Here's How

jordanselig — Mon, 18 May 2026 15:49:16 GMT

Most MCP servers in the wild are single-instance processes. That's fine when they're driving a local Claude or VS Code session — but it's the wrong shape for a production agent fleet that has to absorb traffic spikes, ride through deploys, and survive instance failures.

The good news: the MCP spec already grew up. The 2025-06-18 revision formalizes stateless HTTP transport (and the current 2025-11-25 revision keeps it), which means a single request carries everything the server needs to answer. No long-lived connection, no in-process session table, no sticky-session hacks to keep a client glued to one box.

That tiny protocol change unlocks something big: you can stick an MCP server behind App Service's built-in load balancer and scale it like any other web API. This post walks through how, with a runnable sample.

Sample: seligj95/app-service-mcp-stateless-scale-python. One azd up and you have a stateless FastAPI MCP server running on three App Service instances behind the platform load balancer, with a staging slot, Application Insights, and a k6 script that visualizes load distribution from the client side.

Why "stateless" is the whole story

Earlier MCP transports leaned on persistent connections — SSE channels and WebSocket-style sessions where the server held per-client state in memory (open tools, subscriptions, partial streams). That model is great for a local IDE talking to a local process. It's hostile to load balancing, because routing a follow-up request to a different instance breaks the session.

The stateless HTTP transport flips that. Each request is a complete JSON-RPC envelope (initialize, tools/list, tools/call), every response is self-contained, and the server is allowed to forget the client between requests. Any instance can serve any call. That is the property a load balancer needs.

In the sample, every tool is a pure function of its arguments — whoami reports the serving instance, lookup_fact reads a static dictionary, compute_primes runs a sieve. None of them touches per-client memory. That's not a constraint of the protocol; it's a discipline you adopt to keep statelessness intact.

Why App Service, and not Functions or AKS

A few defaults made App Service the right home for a scaled MCP server:

Always On. Reasoning tools call into LLMs and external APIs; latencies routinely sit in the multi-second range. Functions caps a single execution at ten minutes by default (and aggressively scales workers to zero between bursts, which kills warm caches). App Service keeps the process resident.
Horizontal scale is one parameter. Pick a Premium SKU, set the plan's capacity to N, and you have N instances behind a managed load balancer. No VMSS to declare, no ingress controller to wire up, no Service to reconcile.
Deployment slots. Swap a warmed-up staging slot into production for zero-downtime deploys. Critical when your "API" is an LLM tool surface that an agent is actively driving.
Easy Auth. OAuth 2.1 in front of the MCP endpoint without writing the flow yourself — turn on the App Service authentication blade and point it at Entra ID. The sample leaves this off so the deploy is one command, but the wiring is a checkbox away.

The TL;DR: it's PaaS that already knows how to run a stateful long-lived process at horizontal scale, which is exactly the shape of a scaled MCP server.

The FastAPI MCP server, end-to-end stateless

The whole transport is one POST handler. The full source is in main.py, but here are the load-bearing pieces:

@app.post("/mcp")
async def mcp_endpoint(request: Request):
    body = await request.json()
    method = body.get("method", "")
    msg_id = body.get("id")

    if method == "initialize":
        return {"jsonrpc": "2.0", "id": msg_id, "result": _server_info()}

    if method == "tools/list":
        return {"jsonrpc": "2.0", "id": msg_id, "result": {"tools": [...]}}

    if method == "tools/call":
        params = body.get("params", {})
        result = await MCP_TOOLS[params["name"]]["function"](**params.get("arguments", {}))
        return {
            "jsonrpc": "2.0",
            "id": msg_id,
            "result": {"content": [{"type": "text", "text": json.dumps(result)}]},
        }

There is no session table. There is no client_id cookie. There is no AsyncIterator held open between requests. initialize, tools/list, and tools/call all return in a single round trip, which is the shape App Service's load balancer expects.

The most useful debugging tool in the sample is whoami:

async def tool_whoami() -> Dict[str, Any]:
    return {
        "instance_id": os.environ.get("WEBSITE_INSTANCE_ID", "local"),
        "hostname": socket.gethostname(),
        ...
    }

WEBSITE_INSTANCE_ID is unique per App Service worker. Call whoami a few times from your MCP client and the value rotates — that's the load balancer working. If it doesn't rotate, something is pinning your traffic (almost always the ARR Affinity cookie; we'll get there).

The Bicep that actually makes it scale

The infra is a P0v3 plan with capacity: 3, a web app with affinity disabled, and a staging slot on the same plan:

resource appServicePlan 'Microsoft.Web/serverfarms@2024-04-01' = {
  name: name
  sku: {
    name: 'P0v3'
    capacity: instanceCount   // 3 by default
  }
  properties: { reserved: true }
}

resource web 'Microsoft.Web/sites@2024-04-01' = {
  name: name
  properties: {
    serverFarmId: appServicePlanId
    httpsOnly: true
    clientAffinityEnabled: false   // ← the one line that matters
    siteConfig: {
      linuxFxVersion: 'PYTHON|3.11'
      alwaysOn: true
      healthCheckPath: '/health'
      appCommandLine: 'python -m uvicorn main:app --host 0.0.0.0 --port 8000'
    }
  }
}

resource staging 'Microsoft.Web/sites/slots@2024-04-01' = {
  parent: web
  name: 'staging'
  properties: { /* same shape — separate hostname, same plan */ }
}

The single most important line in that template is clientAffinityEnabled: false. App Service defaults to on, which sets the ARRAffinity cookie and pins every subsequent request from a given client to the instance that handled the first one. That default exists because legacy ASP.NET apps used in-process session state. Stateless MCP does not. Leaving affinity on silently undoes everything we just built.

Premium v3 (P0v3) is the floor for two reasons: it gives Always On and unlocks deployment slots. Below that tier you don't get either.

Application Insights without writing telemetry code

The sample drops one line of bootstrap into main.py:

from azure.monitor.opentelemetry import configure_azure_monitor

if os.environ.get("APPLICATIONINSIGHTS_CONNECTION_STRING"):
    configure_azure_monitor(logger_name="mcp")

The Azure Monitor OpenTelemetry distro auto-instruments FastAPI and outbound HTTP. Every request span App Service emits is tagged with cloud_RoleInstance, which Application Insights populates from WEBSITE_INSTANCE_ID. That makes the question "is traffic actually spreading across my instances?" a one-liner in Logs:

requests
| where timestamp > ago(15m)
| where name contains "/mcp"
| summarize count() by cloud_RoleInstance
| order by count_ desc

If you see three roughly-equal rows, you're done. If you see one row, your client is sending ARRAffinity cookies — turn affinity off and redeploy.

Deploy

azd auth login
azd up

That provisions the resource group, plan, web app, staging slot, Log Analytics workspace, and Application Insights resource, then deploys the Python app via Oryx. The output prints both WEB_URI and WEB_STAGING_URI. Open the production URI — the home page renders the instance ID that served it. Refresh. The ID changes.

To swap the staging slot into production with no downtime:

az webapp deployment slot swap \
  --resource-group <rg> --name <app> \
  --slot staging --target-slot production

App Service warms the staging instances, redirects traffic, and the old production becomes the new staging — the classic blue-green pattern, but free.

Prove it scales

The sample ships a k6 script that hammers /mcp with tools/call requests and tags every response with the instance_id the server returned:

BASE_URL=https://<your-app>.azurewebsites.net \
  k6 run --summary-export=summary.json loadtest/k6-mcp.js
jq '.metrics.mcp_instance_hits.values' summary.json

The output groups hits per instance tag. On a three-instance plan with a 60-second steady load you should see something close to:

{
  "count": 1842,
  "instance0d3e2f...": 614,
  "instance7a91bc...": 612,
  "instance19f0c4...": 616
}

Roughly 33% on each box — the App Service load balancer round-robining new connections, with no help from the application.

What I'd do next

The sample is intentionally a starting point. Two extensions are the obvious next moves:

Add Easy Auth. Turn on App Service authentication, pick Entra ID, require auth on /mcp. The token surfaces as headers; your tool handlers can use it to identify the calling agent without you owning any of the OAuth machinery.
Autoscale on CPU. instanceCount: 3 is a starting point. Wire up Microsoft.Insights/autoscalesettings against the plan and let it scale 3 → 10 on the prime-counting tool. The architecture already supports it — that's the whole point of stateless.

Try it

Sample repo: github.com/seligj95/app-service-mcp-stateless-scale-python
MCP spec: modelcontextprotocol.io/specification/2025-11-25
App Service docs: learn.microsoft.com/azure/app-service/overview

If you ship something with it, I'd love to hear how it held up.

"Not Available in Your Region" Isn't a Dead End: A Security Assessment of Global Deployments

shikhasinha — Mon, 18 May 2026 15:45:46 GMT

You want to build with the latest Microsoft Foundry model. You checked the regional availability, and it isn't there yet — only Global Standard. Now you're weighing the capability you actually need against your instinct to keep everything in a regional SKU. This post is for that moment.

This is a more common situation than people realise. Microsoft typically releases new and preview models on Global first, then expands into specific regions over time as capacity is built out. It isn't an oversight. It's how Microsoft makes new capabilities available to the broadest set of customers as quickly as possible. If you want those capabilities, Global is the path.

The good news is that the path is well-paved. Microsoft Foundry Global Standard is a secure, enterprise-grade deployment type backed by the same Azure controls you already rely on, with explicit contractual commitments on how your data is used. The data protection guarantees don't change because the model is newer or because regional capacity hasn't caught up — they're the same on day one of a new model on Global as they are on a model that's been deployed regionally for a year.

The rest of this post walks through what Microsoft commits to, what you get out of the box, what you add on top, and the small number of cases where Global is genuinely the wrong choice. It's written for three audiences:

Developers who want to know if they're allowed to ship on Global.
Solution architects weighing the model choice against latency, quota, and resilience.
Security architects who need to map Foundry's behaviour to enterprise controls before they sign off.

Where does my data actually go?

This is the question that drives most of the concern, and the answer has two parts. Mixing them up is what causes the confusion.

Data at rest stays in the Azure geography of your Foundry resource. That includes your configuration, uploaded files, stored artifacts, and logs. This is true for Global deployments, exactly the same as it is for regional ones. Microsoft commits to this in the Azure data residency page.

Data in processing is different. When you send a prompt, the model processes it in memory for a few hundred milliseconds and returns a response. For Global deployments, that processing can happen in any Azure region where the model is hosted. This is how Microsoft gives you the highest available capacity and the broadest model access. The prompt and response are not persisted as part of inference processing in the region that processed them.

Once you separate "where my data lives" from "where the request runs," the residency picture becomes much clearer. Your customer data lives where you put it. The model that processes that data runs on Microsoft's global fleet. You can read the official description on the Microsoft Foundry deployment types page.

In a Global deployment, data at rest stays in your selected Azure geography. Inference requests are routed by Microsoft to whichever region has the best available capacity for the model.

What Microsoft commits

These commitments are contractual, not marketing language — they sit inside Microsoft's Product Terms and Data Protection Addendum. According to the data privacy page for Azure Direct Models, your prompts and completions are not used to train Microsoft or OpenAI models, and your fine-tuned models are exclusively yours. Microsoft is also explicit that your data does not touch consumer OpenAI services:

"Microsoft hosts the Azure Direct Models in Microsoft's Azure environment and Azure Direct Models do NOT interact with any services operated by Azure Direct Model providers, for example, OpenAI (e.g. ChatGPT, or the OpenAI API)."

For partner and community models served through serverless APIs, the model catalog data privacy page confirms that those models are stateless and that Microsoft does not use prompts or outputs to train any model.

**What Global does NOT do**

A Global deployment does not replicate your stored data into other regions, does not expose your prompts to consumer OpenAI services, and does not use your inputs or outputs for training. The only cross‑region behavior is the transient execution of model inference, which is stateless and not customer‑addressable.

What Global gives you on day one

Before you configure anything yourself, a Global Standard deployment already includes the following:

Encryption at rest using FIPS 140-2 compliant 256-bit AES with Microsoft-managed keys, applied transparently. See the Microsoft Foundry architecture page.
Encryption in transit using TLS 1.2 or higher, enforced by the platform.
Microsoft Entra ID authentication with Azure RBAC. Foundry separates control-plane actions (like creating deployments) from data-plane actions (like invoking models), so you can grant least privilege without writing custom roles.
Tenant isolation. Your Foundry resource lives in your subscription, your data lives in your tenant, and any fine-tuned models you create are exclusively yours.
Compliance inheritance. Foundry runs on Azure and inherits Azure's compliance controls, including ISO 27001, SOC 1/2/3, HIPAA, PCI DSS, FedRAMP, and many others. The current authoritative list is in the Azure compliance offerings catalogue and the Microsoft Trust Center.

This baseline, with no extra configuration, already meets the security posture most enterprise teams target for new workloads.

The controls you already know

Securing Microsoft Foundry uses the same building blocks as securing any other Azure PaaS service. If your team already knows how to lock down Azure Storage or Azure SQL, you already know how to lock down Foundry. Developers see familiar patterns. Architects get a clean fit into the landing zone. Security architects review the same control surfaces they review elsewhere.

A typical secure deployment pattern. The application calls Foundry over a Private Link path, RAG sources sit behind their own private endpoints, and cross-cutting controls wrap the whole solution.

The controls you'd apply are exactly what you'd expect:

Private networking: Map the Foundry resource to a private IP using Private Link, back it with Private DNS, disable public network access, and route egress through Azure Firewall or an NVA. For agent workloads, Microsoft publishes a private networking template for Foundry Agent Service you can deploy with Bicep or Terraform. Note that Private Link secures the path to the endpoint, not the routing of requests inside the model fleet — you get a private network path without giving up Global's capacity benefits.
Azure APIM GenAI gateway: Put Azure API Management's GenAI gateway in front of your Foundry Global deployments to control who can call models, how much they can use, and under what policies, independent of where inference runs. It enforces central auth, per‑consumer token limits, logging, and policy controls, turning Global deployments from “globally available” into centrally governed and auditable services.
Identity and secrets: Use Managed Identity for application-to-model calls and avoid embedding API keys in code. Apply Conditional Access to admin sign-in and use Privileged Identity Management for just-in-time elevation on admin roles.
Customer-managed keys: If your compliance regime requires key ownership, enable CMK on the Foundry resource via Azure Key Vault for rotation, revocation, and separation of duties.
Logging and monitoring: Send diagnostics to a customer-owned Log Analytics workspace, enable the Azure Activity Log, and alert on token-usage spikes, unusual source IPs, and repeated authentication failures.
Governance at scale: Use Azure Policy to enforce baselines (allowed locations, mandatory diagnostics, required private access) across your tenant, and pair it with Microsoft Defender for Cloud for continuous posture management.

The risk that deserves attention: Data Exfiltration

The most common security risk in any LLM deployment, on any SKU, is not Microsoft's infrastructure. It's the application layer. Examples include over-broad RAG retrieval pulling data the user shouldn't see, a tool-calling agent reaching an unintended destination, or a prompt that quietly echoes PII into a downstream log. These risks exist on Global, Data Zone, and Regional deployments equally. Choosing a more restrictive SKU does not mitigate them.

The good news is that the mitigations are well understood and entirely under your control:

Use Private Endpoints for Storage, AI Search, Cosmos DB, and any other backing services your application uses for RAG, so retrieval traffic stays off the public internet.
For tool-calling and agent scenarios, route outbound traffic through Azure Firewall with FQDN filtering, and keep an explicit allowlist of destinations the agent is permitted to reach.
Apply DLP and redaction at the application layer for high-risk data classes, before that data ever becomes part of a prompt.
Treat prompts and completions as transient. Don't persist them unless you have a specific, auditable reason to do so.

Doing this work on a Global deployment gives you exactly the same protection as doing it on a regional one.

Is Global Deployment right for you?

For most teams building on Microsoft Foundry, the answer is yes. Global Standard gives you:

The highest default quotas and the broadest model availability in the catalogue.
First access to new models and features, often weeks or months ahead of regional rollouts.
Elastic absorption of demand spikes through Microsoft's global capacity pool.
A simpler architecture, with no regional duplication or custom failover logic.
The full Azure security stack: Entra ID, RBAC, Private Link, CMK, Azure Policy, Defender for Cloud, and Monitor.
Contractual guarantees that your data isn't used for training and isn't shared with consumer OpenAI services.

Global is not the right choice when a specific regulation explicitly requires inference processing to occur within a named country or zone. Note the word "processing" there: not data at rest, but the transient processing of the prompt itself. These cases do exist, particularly in some government, healthcare, and financial sector contexts, and Microsoft Foundry offers Data Zone (US or EU) and Regional SKUs for exactly those situations. But unless someone has pointed you at a specific clause in a specific regulation that names processing locality, you most likely don't need to step down from Global.

Summary

Microsoft Foundry Global deployments are secure, compliant, and enterprise‑ready. Data at rest remains in your chosen Azure geography. Prompts and completions are not used for training and do not interact with consumer AI services. Encryption, identity, networking, logging, governance, and monitoring are all first‑class Azure controls. Modified Abuse Monitoring is available for qualifying enterprise customers where required.

A short summary for each audience:

Developers: you can build on Global with confidence, using the Azure patterns you already know.
Solution architects: Global is a sensible default unless a regulatory requirement specifically rules it out. Data Zone and Regional remain available for the cases that need them.
Security architects: the control surfaces are familiar, the contractual commitments are explicit, and Global can be approved on the same basis as any other Azure PaaS service handling equivalent data classifications.

If you've been defaulting to a regional SKU "just to be safe," it's worth taking a fresh look at whether Global actually fits your workload. In most cases, it will.

Critical Shell/Explorer.exe Boot Loop and Flickering on Recent Windows 11 Insider Build

suryanandikolla — Mon, 18 May 2026 15:22:40 GMT

Hello Windows Insider Team,

I am writing to report a critical UI/system stability issue encountered immediately after updating to and restarting the recent Windows 11 Insider build on my machine.

Issue Description: Upon finalizing the update and rebooting, the desktop shell entered an infinite crash loop. The Windows background and active windows were flickering/blinking rapidly, and the Start Menu and Taskbar were completely missing/unresponsive.

Key Diagnostics:

Task Manager Stability: Interestingly, the Task Manager remained completely stable and unaffected by the flickering, confirming the core OS and graphic drivers were functional.

Attempted Fixes: Restarting explorer.exe via Task Manager did not resolve the issue. Attempting to delete the IrisService registry key HKCU > SOFTWARE > Microsoft > Windows > CurrentVersion > IrisService only stabilized the Start Menu for a brief moment before the flickering loop resumed.

Resolution: The system was only stabilized after bypassing the UI via Task Manager, booting into the Advanced Startup menu, and performing an "Uninstall latest feature update" rollback to the previous working Insider build.

I wanted to bring this to your attention as the crash loop completely breaks usability for users hitting this specific flight. Please let me know if you need any specific diagnostic logs from my previous build state to help isolate the bug.

Best regards,

Suryanarana N

YellowKey BitLocker Exploit

StuartK73 — Mon, 18 May 2026 15:05:12 GMT

Hi All

I hope you are well.

Anyway, the YellowKey BitLocker Exploit has came to my attention.

We already have automatic / silent BitLocker encryption enabled.

So, is there anything we should be doing (preferably via Intune) to mitigate this new exploit?

Platform SSO during automated device enrollment is now generally available for macOS

Justin-Ploegert — Mon, 18 May 2026 15:00:00 GMT

Getting new devices into users’ hands quickly while maintaining strong identity and compliance has always required a careful balance. IT admins need streamlined deployment workflows, while end users expect a frictionless experience from the very first sign-in.

Today, we’re excited to announce that Platform SSO (PSSO) during Automated Device Enrollment (ADE) on macOS is now generally available. This capability simplifies onboarding by enabling device registration and Platform SSO setup to occur automatically during enrollment, eliminating extra steps for both IT administrators and end users.

Streamline setup for IT admins

Automated Device Enrollment already provides a powerful way to provision macOS devices with the right configuration, policies, and applications from the start. With Platform SSO now integrated directly into this flow, IT admins can:

Ensure Platform SSO is enabled as part of enrollment — no post-setup steps required.
Standardize device identity and access configuration from day one.
Reduce deployment complexity by avoiding separate workflows for completing SSO setup.
Improve compliance posture immediately with identity-backed device trust.

By incorporating PSSO into ADE, organizations can treat identity configuration as a core part of provisioning—not as an afterthought.

Reduce friction for end users

Previously, users enrolling macOS devices might encounter an additional step after setup to complete Platform SSO registration, typically requiring them to respond to a prompt or click a “Finish” action.

With this new capability, that extra step is removed:

No additional prompts to complete Platform SSO
No need for users to manually finish enrollment steps
Immediate access to single sign-on experiences after setup

The result is a smoother, more intuitive onboarding experience where users can begin working right away without interruption.

Understand how it works

With the EnableRegistrationDuringSetup capability, Platform SSO registration is performed as part of the Automated Device Enrollment process. This ensures that:

The device is properly registered with Microsoft Entra ID during setup.
Platform SSO is activated automatically.
The user’s identity is fully integrated into the device experience from first sign-in.

Because this happens within the managed enrollment flow, it aligns naturally with existing MDM configurations and provisioning policies.

See why it matters

For organizations adopting modern identity and device management, reducing friction during onboarding is critical—not just for productivity, but for security consistency at scale.

With Platform SSO during ADE:

IT admins gain a predictable, simplified setup experience.
Users avoid confusing or redundant steps during onboarding.
Organizations achieve faster time-to-productivity with stronger identity integration.

This is especially impactful in environments where devices are deployed at scale, such as enterprise rollouts, education, or frontline scenarios.

Get started

Ready to simplify macOS onboarding? Configure Platform SSO during Automated Device Enrollment in Microsoft Intune to reduce setup friction and strengthen identity from day one.

To enable Platform SSO during Automated Device Enrollment, follow the MDM configuration steps below:

Configure Automated Device Enrollment for macOS in your MDM solution.
Ensure Platform SSO is configured for your organization.
Enable the EnableRegistrationDuringSetup setting as part of your deployment profile.

Once enabled, new devices will automatically complete Platform SSO setup during enrollment—with no additional user action required.

- Justin Ploegert

Additional resources

Learn more about Microsoft Entra

Prevent identity attacks, ensure least privilege access, unify access controls, and improve the experience for users with comprehensive identity and network access solutions across on-premises and clouds.

Legal Teams: Drafting Documents Securely with Copilot

JohnNaguib — Mon, 18 May 2026 14:36:56 GMT

In today’s legal environment, speed matters just as much as accuracy. Legal teams are under constant pressure to draft contracts faster, review documents more efficiently, and maintain airtight compliance standards. At the same time, firms and corporate legal departments are handling larger volumes of sensitive information than ever before. This is where AI-powered tools like Microsoft Copilot are transforming the way legal professionals work.

https://dellenny.com/legal-teams-drafting-documents-securely-with-copilot/

[MMR Call Redirection] ISV submission form broken — requesting allowlisting channel

Hicham_KADIRI — Mon, 18 May 2026 13:56:00 GMT

The ISV submission form referenced on this page is currently unavailable. Here is the URL

We represent an ISV (Ringover — app.ringover.com) with a completed PoC validating MMR Call Redirection on AVD and Windows 365.

Full submission pack is ready. Please advise on the correct submission channel or restore The form. Contact: hicham.kadiri [at] ringover.com

Thanks in advance for your feedback.

Regards,

Hicham.

rss.livelink.threads-in-node

Partner Blog | Time to market wins: Building the Frontier partner practice

Launched: Microsoft 365 Adoption Hub Redesign

EVENT | Drive Frontier Transformation: Attend the engineer summit and work toward your badge

Say goodbye to planning bottlenecks with Microsoft Azure Migrate

Launched: Microsoft 365 Copilot Adoption Hub Redesign

Don’t Start Your Application Upgrade by Changing Code

Look at the app before you touch it

The order matters

Watch it in action

Easy Auth Configuration for Logic App Standard through CI/CD

Problem Statement

Background — How Easy Auth Interacts with Logic Apps

Solution

Option 1 — Allow unauthenticated requests

Option 2 — Keep Easy Auth strict, but exclude the runtime paths

Approach 1 — ARM Template (Microsoft.Web/sites/config)

Approach 2 — REST API call as a post-deployment pipeline step

Summary

State Explosion Security Problem in AI-Era Software Supply Chains

Introduction

How a Single Line Changes Package Intent

Why the whole package matters

Why every change demands re-analysis

Quantifying the problem

Why the math breaks traditional scanning

The scanning bottleneck

What needs to change

The Latency-Accuracy Tradeoff: Malware Detection as an ML Problem

Agent 365 connector: Monitor, hunt, and investigate AI agent activity in Microsoft Sentinel

Why this matters for organizations

Agent 365 connector key capabilities

Use cases

Get started with Agent 365 connector

Learn more

Now in Foundry: Tongyi-MAI Z-Image-Turbo, with FLUX.1-schnell and SDXL base 1.0

Models of the week

Tongyi-MAI: Z-Image-Turbo

Black Forest Labs: FLUX.1-schnell

Stability AI: stable-diffusion-xl-base-1.0

Getting started

Navigate changing hosting economics with the Microsoft Datacenter Optimization initiative

Now available: Close deals faster and transact at scale with auto activation for SaaS subscriptions

How it works

Default behavior

Get started

Help Shape the Future of Microsoft Teams for Small and Medium Businesses

What is Teams SMB PAC?

What’s the Commitment?

Why Join?

Interested in Participating?

You Can Scale MCP Servers Behind a Load Balancer on App Service — Here's How

Why "stateless" is the whole story

Why App Service, and not Functions or AKS

The FastAPI MCP server, end-to-end stateless

The Bicep that actually makes it scale

Application Insights without writing telemetry code

Deploy

Prove it scales

What I'd do next

Try it

"Not Available in Your Region" Isn't a Dead End: A Security Assessment of Global Deployments

Where does my data actually go?

What Microsoft commits

What Global does NOT do

What Global gives you on day one

The controls you already know

The risk that deserves attention: Data Exfiltration

Is Global Deployment right for you?

Summary

Critical Shell/Explorer.exe Boot Loop and Flickering on Recent Windows 11 Insider Build

YellowKey BitLocker Exploit

Platform SSO during automated device enrollment is now generally available for macOS

Streamline setup for IT admins

Reduce friction for end users

Understand how it works

See why it matters

Get started

Legal Teams: Drafting Documents Securely with Copilot

[MMR Call Redirection] ISV submission form broken — requesting allowlisting channel

Approach 1 — ARM Template (`Microsoft.Web/sites/config`)

**What Global does NOT do**