Apps on Azure Blog articles

Regional Endpoints for Azure Container Registry Geo-Replication — Now in Public Preview

johnsonshi_msft — Fri, 05 Jun 2026 06:12:53 GMT

By Johnson Shi, Zoey (Zhuyu) Li, Huangli Wu

What's new

Regional endpoints for geo-replicated Azure Container Registries are now in public preview. See the feature's official MS Learn documentation. If you've been following since the private preview announcement, here's what changed:

No feature flag registration. No subscription enrollment so all Azure subscriptions and customers can now use this feature.
No CLI extension. Regional endpoints commands are built into Azure CLI 2.86.0+ natively. If you installed the private preview acrregionalendpoint extension, uninstall it to avoid conflicts.
Native CLI and portal support.
- With Azure CLI 2.86.0+, enable regional endpoints for all geo-replicas of a registry with az acr create --regional-endpoints enabled or az acr update --regional-endpoints enabled.
- The Azure portal also supports configuring regional endpoints natively.
CLI flag rename for configuring a geo-replica's global endpoint routing (an existing separate feature). The existing flag --region-endpoint-enabled (on az acr replication create/update) has been renamed to --global-endpoint-routing.
- Key clarifications:
  - "--global-endpoint-routing" (formerly "--region-endpoint-enabled" on "az acr replication create / az acr replication update") — controls whether a specific geo-replica participates in global endpoint routing. This is an existing feature that is different from the new registry-level "--regional-endpoints" feature being discussed in this post.
  - "--regional-endpoints" (on az "acr create / az acr update") — enables or disables the regional endpoints feature at the registry level for all geo-replicas. This is the feature discussed in this post.
- See the endpoint reference for the full breakdown of the various registry endpoints (global endpoints, regional endpoints, and data endpoints).

Regional endpoints are available on Premium SKU registries in all Azure public cloud regions.

What are regional endpoints?

Regional endpoints give you dedicated, per-region login server URLs for each geo-replica with the following URL pattern:

myregistry.eastus.geo.azurecr.io
myregistry.westeurope.geo.azurecr.io

Regional endpoints coexist with the registry's global endpoint (myregistry.azurecr.io) — enabling regional endpoints doesn't disable a registry's global endpoint that is backed by Azure-managed routing. You can choose per workload:

You can use the global endpoint with automatic Azure-managed routing with health-aware failover, where Azure will route your requests to the geo-replica with the best network performance profile to the client.
You can use a regional endpoint when you need explicit control or routing to a specific geo-replica.

Other resources:

For the full background on why regional endpoints exist and the problems they solve, see the private preview blog post.
For the complete operational deep dive — health-aware failover, throttling considerations, storage quota and pricing, eventual consistency, home region outage behavior, DNS propagation, private endpoint interaction, capacity planning, and monitoring guidance — see How ACR geo-replication handles failover, failback, and traffic redirection.
For the behind-the-scenes engineering implementation — architectural overview and the engineering system design of the feature — see Determinism over magic: the engineering design behind Azure Container Registry Regional Endpoints.

Getting started

Enable regional endpoints on an existing registry:

az acr update -n myregistry -g myrg --regional-endpoints enabled

View all registry endpoint URLs, including the registry global endpoint, geo-replica regional endpoints, and data endpoints:

az acr show-endpoints --name myregistry --resource-group myrg

Using regional endpoints

Authenticate to a specific regional endpoint:

az acr login --name myregistry --endpoint eastus

Push to a specific geo-replica.

Images and tags pushed to a geo-replica via regional endpoints still propagate to all other geo-replicas under eventual consistency.

docker tag myapp:v1 myregistry.eastus.geo.azurecr.io/myapp:v1 docker push myregistry.eastus.geo.azurecr.io/myapp:v1

Pull an image:

docker pull myregistry.eastus.geo.azurecr.io/myapp:v1

You can specify regional endpoints directly in Kubernetes deployment manifests if you need to pin workloads to specific regions. This ensures clusters in specific regions always pull from their colocated replica, providing predictable routing and reduced latency.

By using different regional endpoints in each cluster's manifests, you can choose to guarantee that each cluster pulls from its local replica instead of relying on Azure-managed routing.

East US cluster deployment:

apiVersion: apps/v1 kind: Deployment metadata: name: myapp-eastus spec: template: spec: containers: - name: myapp image: myregistry.eastus.geo.azurecr.io/myapp:v1

West Europe cluster deployment:

apiVersion: apps/v1 kind: Deployment metadata: name: myapp-westeurope spec: template: spec: containers: - name: myapp image: myregistry.westeurope.geo.azurecr.io/myapp:v1

When to use regional endpoints

Scenario	What to do
Most workloads	Keep using the global endpoint (`myregistry.azurecr.io`). Health-aware failover handles routing automatically.
Pin AKS clusters to co-located replicas	Use regional endpoint URLs in deployment manifests.
CI/CD push-then-pull consistency	Pin pushes to a regional endpoint to avoid eventual-consistency races.
Client-side failover	Switch between regional endpoints based on your own health checks.
Capacity planning	Spread workloads across multiple regional endpoints to avoid per-replica throttling.
Troubleshooting	Target a specific geo-replica to reproduce or isolate an issue.

What changed from private preview

Private preview	Public preview
Feature flag registration required (`az feature register`)	No registration needed
Subscription private preview enrollment and propagation wait	Immediately available to all Azure subscriptions for all Premium SKU registries in all Azure public cloud regions.
Separate CLI extension (`acrregionalendpoint`)	Built into Azure CLI 2.86.0+ natively
No registry-level CLI flag	`az acr update --regional-endpoints enabled` enables regional endpoints for all geo-replicas
`--region-endpoint-enabled` flag for controlling a geo-replica's global endpoint routing via `az acr replication update`	Flag for controlling a geo-replica's global endpoint routing renamed to `--global-endpoint-routing`
No portal support	Native Azure portal support for enabling regional endpoints for new registries (during creation) and for existing registries
Private preview docs in Azure/acr	Full documentation on MS Learn

Enabling regional endpoints in the Azure portal

You can enable regional endpoints directly from the Azure portal for both new registries (during creation), as well as existing registries:

If you were in the private preview

1. Uninstall the CLI extension.

The private preview CLI extension conflicts with the built-in commands in Azure CLI 2.86.0+. Remove it:

az extension remove --name acrregionalendpoint

Verify it's gone:

az extension list --query "[?name=='acrregionalendpoint']" -o table

2. Ensure you're running Azure CLI 2.86.0 or later.

Regional endpoints commands are available natively starting in Azure CLI 2.86.0. Check your version:

az version

3. Update scripts that use --region-endpoint-enabled for controlling global endpoint routing for a geo-replica.

The old flag name for controlling a geo-replica's global endpoint routing configuration is deprecated and will be removed in Azure CLI 2.87.0 (June 2026). Update to --global-endpoint-routing:

# Old (deprecated) az acr replication update --registry myregistry --name westus \ --region-endpoint-enabled false # New az acr replication update --registry myregistry --name westus \ --global-endpoint-routing false

Why the rename? The old flag name --region-endpoint-enabled was confusing — it sounded like it controlled the regional endpoints feature, but it actually controlled whether a geo-replica participates in global endpoint routing. The new name --global-endpoint-routing says exactly what it does. For a full breakdown of all three CLI flags and how they relate, see the endpoint reference.

Learn more

Full documentation: Geo-replication in Azure Container Registry — Regional endpoints — prerequisites, CLI commands, network considerations, private endpoint integration, and troubleshooting.
Operational deep dive: How ACR geo-replication handles failover, failback, and traffic redirection — health-aware failover, throttling, eventual consistency, DNS considerations, monitoring, pricing, and a full walkthrough.
Behind-the-scenes engineering implementation: Determinism over magic: the engineering design behind Azure Container Registry Regional Endpoints — architectural details and the engineering system design behind the feature.
Endpoint reference: Azure Container Registry endpoint reference — all endpoint types, URL formats, and CLI flags in one place.
Private endpoints: Connect privately to a registry using private endpoints — IP allocation math, subnet sizing, and NIC queries for registries with regional endpoints.
Firewall rules: Configure firewall access rules — which FQDNs to allow for regional endpoints.

Feedback

We'd love to hear how you're using regional endpoints and what we can improve. Reach out via:

Azure Container Registry GitHub repository — issues, feature requests, and discussion
Azure portal feedback — use the feedback button in the Azure portal on your registry's page

Regional endpoints are on the path to GA. Your feedback directly shapes the feature's direction.

Inside ACR Artifact Cache: Pull-Through Caching at Scale

akashsinghal — Tue, 02 Jun 2026 22:43:58 GMT

By: Akash Singhal, Luis Dieguez, Kiran Challa, Nathan Anderson, Tony Vargas, Caroline Barker, Ren Shao, Mabel Egba, Toddy Mladenov, Johnson Shi

Introduction

For many customers, Azure Container Registry (ACR) is the only registry their workloads can trust, even when images and artifacts originate from a different registry such as Docker Hub, Microsoft Artifact Registry, GitHub Container Registry, Quay, another ACR, or a private registry. ACR Artifact Cache makes this many-to-one model practical by letting a platform team map a downstream ACR repository path to an upstream source repository. Here, upstream means the source registry and repository ACR contacts on behalf of the customer, and downstream means the ACR-facing path customers pull from.

From the outside, the experience looks like a normal pull from ACR. Inside the service, that pull moves through the same multi-tenant registry platform that serves ACR traffic across regions, clouds, and data plane stamps. This series is about the gap between that simple external experience and the internal system. The goal is to show what happens inside ACR, why the system is designed this way, and how those design choices shape the behavior customers ultimately observe.

Some implementation details are simplified, and the system continues to evolve. The request paths and design constraints are representative, but this article intentionally avoids service-by-service internals that are not necessary to understand the feature.
For this overview, the useful mental model is: serve now, hydrate for later. Later sections will show where that model helps, and where it creates engineering pressure.

Why serve upstream content from ACR?

Pulling directly from an upstream is often sufficient for development, but production systems need stronger guarantees from the pull path.
The failure modes are familiar to anyone who has operated containerized workloads at scale:

an upstream registry is slow or temporarily unavailable
an upstream applies rate limits or burst protection
credentials for various upstream sources need to be handled safely
ACR-to-ACR scenarios should avoid customer-managed credentials entirely by using managed identity
network policy expects pulls to stay inside an approved network boundary
a platform team wants one shared, sanitized catalog of public content for first-party consumption while individual teams pull only what they need

Let’s take Docker Hub as a concrete example. Docker Hub pull rate limits mean that unauthenticated users and Docker Personal users can exhaust their allowed pulls in a time window, causing shared build agents or Kubernetes nodes to receive rate-limit errors instead of images. That is a useful example because it makes the upstream dependency visible, but it is not the whole story. The broader engineering problem is that upstream-sourced artifacts should behave like local registry dependencies once a customer chooses to route them through ACR.

Artifact Cache addresses that problem by letting customers map a downstream ACR namespace to an upstream namespace, pull through ACR, and allow ACR to materialize content locally as it is requested.

A pull-through cache inside ACR

Azure Container Registry operates across 60+ Azure regions and 6 public and sovereign clouds, serves hundreds of thousands of registries, and handles billions of requests per day. Artifact Cache is only one part of that larger service, but it is large enough to be a distributed systems problem in its own right: more than 100 million image pulls per day, petabyte-scale egress, upstreams with different behavior, and customers who expect registry pulls to remain predictable.

This scale matters because Artifact Cache is not deployed beside ACR as a separate service. It is part of the same registry system that serves normal pushes, pulls, tag listing, catalog operations, authentication flows, private networking scenarios, and other registry API traffic.
That means Artifact Cache has to fit into ACR's existing resource model and request-serving model. Customers configure cache rules and authentication boundaries through the control plane, then their pulls are served through the data plane. The next sections follow those two parts in order: first the resources customers create, then the runtime path those resources affect.

The customer workflow

The setup begins in the control plane, where customers define the relationship between an ACR namespace and an upstream source.
A customer starts with an ACR and chooses an upstream repository. In the examples below, myregistry.azurecr.io is the customer's ACR login server. The dockerhub/library/node path is the downstream ACR namespace the customer wants to use for cached content.

The authentication model depends on the upstream:

For a public upstream, the cache rule may not need credentials.
For a private upstream, the customer stores upstream credential material in their Azure Key Vault, creates a credential set that references those secrets, and then associates that credential set with a cache rule. At access time, ACR uses the system-assigned managed identity associated with the cache rule to read the referenced Key Vault secrets, so the customer controls access by granting that identity the required secret permissions. ACR materializes those credentials only when it needs to contact the upstream, so the customer-owned Key Vault remains the secret store.
For an ACR-to-ACR upstream, the customer can use a user-assigned managed identity. In that scenario, credential sets are not part of the flow; managed identity replaces the credential-set and Key Vault path.

At a high level, the customer defines a namespace mapping:

docker pull myregistry.azurecr.io/dockerhub/library/node:latest

maps to:

docker pull docker.io/library/node:latest

In ACR, that mapping is stored as a cache rule: a control-plane resource that maps a downstream ACR path to an upstream source path. If the upstream requires authentication, the cache rule links to the appropriate credential boundary: a credential set backed by customer-owned Key Vault secrets, or a user-assigned managed identity for ACR-to-ACR.

This is where the control-plane/data-plane split shows up. The control plane manages registry configuration through surfaces such as CLI, portal, Bicep, ARM templates, and other Azure Resource Manager clients. ARM sends those resource operations to the ACR control plane, which creates or updates the cache rule and, when needed, the credential set as child resources under the registry. Those resources do not own customer secrets or identities directly; they link to existing Azure resources such as the customer's Key Vault or an optional user-assigned managed identity. Later, the data plane uses that persisted configuration to decide whether a runtime registry request, such as a pull or tag listing, should be handled by Artifact Cache.

Diagram A: Control plane resource provisioning

After setup, the runtime path begins with the simplest possible pull:

docker pull myregistry.azurecr.io/dockerhub/library/node:latest

To understand what happens after that command, we need a map of the ACR components that participate in the request path.

The ACR components involved

The architecture needed for this overview is much smaller than ACR's full internal service graph.

ACR is a regionalized service. The control plane operates at the regional level, while data plane stamps serve hot-path registry traffic for the registries assigned to them. A registry is pinned to a stamp, and high-traffic regions may have more than one stamp. Stamp architecture is an ACR concept covered in more detail in the stamp rebalancing post; this article only needs the simplified model below.

For this article, ACR has three important boundaries:

The regional control plane manages registry resources and provisioning operations.
The data plane stamp serves hot-path registry traffic for registries pinned to that stamp.
The storage layer holds downstream registry metadata, blobs, and storage-backed event queues.

At this level of detail, a data plane stamp is composed of a few major runtime substrates. The registry data plane virtual machine scale set (VMSS) is the core ACR data plane. It runs containerized services including the frontend, the registry API entry point that receives and routes OCI and ACR-specific requests. The data proxy VMSS also runs containerized services and serves selected blob-content paths. It serves eligible blob-content traffic behind ACR's dedicated data endpoint; see the ACR data endpoint documentation. The stamp also includes a runtime cluster for additional data plane services, including services that are not on the hot path.

This article will not explain why ACR uses both VMSS-based services and a runtime cluster inside the data plane stamp. That tradeoff is useful context, but it belongs in a separate deep dive. For Artifact Cache, the important point is narrower: the stamp contains the runtime substrates that participate in data plane serving, including runtime-cluster services that process async import and hydration work.

The component list is:

Component	Role
Region control plane	Manages registry resources and provisioning operations
Data plane stamp	Serves pinned registries in a region
Registry data plane VMSS	Core ACR data plane for OCI and ACR-specific APIs
Frontend	Handles OCI registry API traffic inside the registry data plane
Data proxy VMSS	Serves selected blob-content paths, including Artifact Cache
Runtime Kubernetes Cluster	Hosts additional data plane services, including async import and hydration workers
Cache rule	Maps downstream ACR path to upstream path
Credential set or managed identity	Provides the upstream authentication boundary when needed
Cache Backend service	Handles cache-rule-backed pulls
Storage queue	Regional storage resource used for hydration events
Metadata/blob storage	Stores downstream manifests, tags, digests, and layer blobs
Import workers	Run in the data plane runtime cluster and hydrate downstream content asynchronously
Upstream registry	Public, private, or another ACR registry used as the source

The diagram below is a component map rather than a step-by-step pull trace. It shows one visible data plane stamp in West US for myregistry.azurecr.io, with a muted marker to indicate that larger regions can contain multiple stamps. The stamp contains a registry data plane VMSS, a data proxy VMSS, and a runtime Kubernetes cluster. Regional metadata/blob storage and the storage queue sit outside the stamp boundary. The storage queue is also outside the regional control plane cluster; it is a storage resource consumed by data plane runtime-cluster workers.

Diagram B: Region, stamp, data plane, and control plane

First artifact pull

Now return to the pull request:

docker pull myregistry.azurecr.io/dockerhub/library/node:latest

The request reaches the data plane stamp where myregistry is pinned. The frontend in the registry data plane VMSS handles the registry API request and forwards it to the Cache Backend Service, which checks whether the requested repository path matches a cache rule.

If there is no matching cache rule, the request follows the normal ACR path. If a cache rule matches, Artifact Cache logic applies.

The next check is local state. ACR looks at downstream metadata and blob storage to determine whether the requested manifest and blobs are already available locally. If the content is present, ACR can serve it from the downstream registry path.

If the content is not available locally, ACR resolves the upstream repository path from the cache rule. If the upstream requires authentication, ACR uses the configured auth boundary for that upstream: a credential set for private upstreams, or a user-assigned managed identity for ACR-to-ACR upstreams. The request can then be served through the upstream-backed data path, with the data proxy handling the blob content path.

The first pull does not need to wait for durable hydration to complete before the client receives content. Serving the pull and hydrating the downstream registry are related operations, but they are deliberately separated.

Diagram C: First docker pull before hydration

The trace above follows the same node:latest image used in the setup example. On a cache miss, the data plane queues an async import event for the requested image while still serving the client request. Manifest content returns through the frontend path. For layer blobs, the frontend returns a redirect to the data proxy, and the client follows that redirect while the data proxy streams blob content from the upstream CDN.

The data plane serves the customer request, but it also detects that durable downstream state needs to be populated. That durable work is where hydration comes in.

Hydration

Hydration is the process that materializes upstream content into the downstream ACR registry.

ACR performs hydration asynchronously because the data plane workload can be bursty and variable. A deployment or scale-out event can cause many clients to request the same not-yet-hydrated image at nearly the same time. Image size, layer count, multi-platform manifest trees, upstream behavior, queue depth, and retry behavior all matter in a multi-tenant service.

The north star is to coordinate those requests: collapse duplicate work, hydrate the content from upstream, and serve all waiting clients without turning one customer action into unnecessary upstream load. That coordination problem is challenging at ACR scale, and we are continuing to improve it.

The existing async import path gives Artifact Cache a durable and scalable foundation while that serving path continues to evolve. At a high level, the data plane queues an import event. A notification service consumes the event and dispatches work to import workers in the data plane runtime cluster. Those workers fetch the required content from the upstream registry and write manifests, tags, digests, and layer blobs into ACR metadata and blob storage.

Diagram D: Async hydration

When import workers complete, they notify the notification service, which can publish completion signals through ACR eventing surfaces such as Event Grid and webhooks. This allows customers to use webhooks to detect when cached content is fully available locally. You can read more about how it works here.

The mental model is that the first pull can serve immediately, while hydration makes future local serving durable. A follow-up post will go deeper on the work ACR does to reduce upstream load during this hydration window.

Later pulls

After hydration completes, later pulls for the same content can be served from ACR.

For digest references, the model is relatively direct because a digest is content-addressed. If ACR has the requested digest and its blobs downstream, the data plane can serve that content locally.

Tags are more subtle because tags can change. A tag such as latest is a name that can point to different content over time. Artifact Cache therefore must care about freshness semantics for tag-based pulls. This is one of the reasons a pull-through cache becomes more complex than "fetch once and forget."
The benefit is not only lower latency. ACR also reduces repeated dependency on the upstream for content that has already been materialized downstream.

Guarding the pull path

Once content is hydrated, ACR must serve that content from the customer's registry boundary even when the upstream is slow, unavailable, or returning errors. That distinction matters for tag-based pulls: ACR may need upstream checks to reason about freshness, but an upstream failure should not automatically prevent ACR from serving content that is already available downstream.

Artifact Cache also must be careful about how it behaves when upstreams are unhealthy. If an upstream starts returning 5xx errors or throttling requests, ACR should avoid amplifying the problem by repeatedly sending customer-triggered requests upstream. Circuit breaking and upstream work minimization are part of being a good steward of both customer traffic and upstream registry limits. More details to follow in subsequent posts.

There is a separate availability question inside ACR: what happens if Artifact Cache-specific components, such as the cache backend path, are operationally unavailable? ACR handles that case gracefully by falling back to normal registry pull behavior: it checks the customer's registry state and serves the image if the requested content already exists in ACR. In other words, cache-backend unavailability should not block pulls for content that is already present in the registry.

What we will explore next

This overview is the map for the rest of the series. The following posts will go deeper into the parts of the system where the design pressure is highest.

Minimizing upstream work

We will start with how Artifact Cache avoids making more upstream requests than necessary.

This becomes difficult when many clients request the same not-yet-hydrated image at the same time. A Kubernetes scale-out event is the classic example: many nodes may ask for the same image concurrently, and the system must avoid turning one customer's action into unnecessary duplicate upstream work.

Making Artifact Cache observable to customers

We will also look at how customers understand whether their cache rule is healthy, whether credentials are usable, and why a pull failed.
This is hard because a failed pull can involve customer configuration, Key Vault access, managed identity configuration, upstream credentials, upstream availability, data plane request handling, or asynchronous hydration. The engineering challenge is to expose the right customer-facing health and debug signals without turning internal topology into the user interface.

Repository semantics in Artifact Cache

Finally, we will look at repository semantics. Once upstream content becomes local, the repository is no longer just a mirror.

Tags can move upstream, digest references are content-addressed, and customers may push their own content into downstream repositories. The visible repository state can involve both upstream-derived content and customer-owned downstream writes.

Closing

Artifact Cache is designed to make upstream-sourced artifacts behave like ACR-served content once customers choose to route those artifacts through their registry. The design goal is that customers can pull from ACR and reason about the result using ACR boundaries: registry configuration, local serving, customer-visible health, and predictable repository semantics.

Anyscale on Azure: Powering Enterprise AI at Massive Scale on Azure Kubernetes Service

bobmital — Tue, 02 Jun 2026 20:56:02 GMT

Somewhere on your AI platform team, an engineer is on call this weekend — not for the model, not for the training run, but for the integration code holding five separate AI processing systems together. Data preparation on one. Training on a second. Evaluation on a third. Serving on a fourth. Observability bolted on across all of it. The glue between them has quietly evolved into a production system of its own, complete with its own failure modes and its own pager.

This is what running AI at scale looks like for most enterprises in 2026. To process the full breadth of AI workloads, teams don’t have one platform, but a stack of multiple compute engines — stitched together and monitored around the clock. Training failures become increasingly costly as multi-node GPU clusters remain underutilized and difficult to operate. Inference costs climb in a straight line when they should be bending the other way. And the accelerators underneath, at six figures a year per node, sit at 30–40% utilization.

None of this is a model problem. It is a systems problem, and it exposes a divide that is widening across the industry.

The AI shift: Moving from API inference calls only to end-to-end AI

Most enterprises start an AI journey by calling hosted model APIs. It’s the fastest way to experiment and ship. But as adoption grows, inference costs scale in a straight line while differentiation remains limited. The organizations pulling ahead are doing more than consuming models. They are customizing them with proprietary data, operating them at scale, and owning the infrastructure between their data and their models. Their unit economics improve as they scale. The dividing line isn’t budget. It isn’t ambition. It is a single architectural decision: whether the layer between your data and your models is something you rent in pieces or run as a single system.

That unified system for end-to-end AI, almost without exception, is built on one runtime: Ray, an open-source framework widely adopted by AI-natives such as Cursor, Mistral and xAI to act as the engine that powers many of their workloads from multimodal data processing to reinforcement learning.

Anyscale on Azure: Build and run end-to-end AI on your Azure subscription

Anyscale on Azure brings the distributed compute runtime the AI industry has converged on — Ray— into your Azure tenant as an Azure Native service, that includes purpose-built developer tooling and unified pane for cluster management, built through deep engineering collaboration between Anyscale and Microsoft.

Unlike other processing engines which either only support one hardware type (e.g. CPUs) or focus on a single workload (e.g. inference), Ray turns a heterogeneous cluster of CPUs and GPUs into a single Python runtime composing data preparation, distributed training, fine-tuning, reinforcement learning, high-throughput inference, and agentic execution as one program, not five interlocking systems. Anyscale created Ray and stewards the open-source Ray project, now governed by the PyTorch Foundation; the Anyscale Runtime is the production-grade layer that enterprises can utilize on critical paths from day one, bringing managed cluster operations, enterprise-grade support, and the operational reliability needed to run AI and data workloads at scale.

On Azure, that runtime executes on your Azure Kubernetes Service (AKS) clusters, inside your subscription, and under Microsoft Entra ID workload identity. Your data, models, and weights never leave your cloud, and consumption is billed through Azure with drawdown against your existing Azure commitment (MACC).

Sovereignty isn't a label bolted on after the fact. It is the architectural starting point: customer-owned data and models in the customer-owned tenant and governance boundary. The variable per-token economics of hosted APIs are replaced with compute you govern directly. Your proprietary data becomes a compounding advantage rather than a payload shipped to a third-party endpoint.

A single runtime for the full AI lifecycle

The cost profile of enterprise AI is largely architectural. Fragmented stacks — separate systems for prep, training, evaluation, and serving — produce a predictable set of failure modes such as Idle GPU time, Integration code and cross-system data movement.

The result: production GPU utilization only in the 30–40% range, against accelerators that cost six figures per node per year.

On the same fleet, Anyscale customers run those accelerators at 80%+ sustained utilization and report 40–60% lower GPU spend versus static, single-tenant clusters — driven by fractional GPU allocation (down to 0.2 of a device), bin-packing across complementary memory and compute profiles, gang scheduling for distributed training, priority-aware preemption that lets production inference take precedence over ad-hoc training, and spot integration with checkpoint-aware preemption so long-running jobs survive reclamation without lost work.

Anyscale on Azure replaces this with a single Ray-powered runtime that spans the lifecycle as one distributed computation graph:

Ray Data (distributed preparation) → Ray Train (fault-tolerant training) → Ray Tune (hyperparameter search) → Ray Serve (inference) — under one managed control plane.

On top of open-source Ray, the Anyscale Runtime adds fault-tolerant training with checkpoint/restart, optimized scheduling, faster cluster bring-up, inference-aware autoscaling, and per-stage observability.

Ray is the unifying layer that, rather than replacing, streamlines distributed processing of the framework stack the AI industry already uses: PyTorch, Hugging Face Transformers, FSDP, DeepSpeed, and Megatron for training, vLLM and SGLang for high-throughput inference with continuous batching, paged attention, and speculative decoding. Ray Train orchestrates the three parallelism patterns modern training requires — data parallel, model parallel, and hybrid 3D parallel (data + tensor + pipeline) — for trillion-parameter models, without requiring teams to write custom distributed code.

The architectural payoff is direct: a single Python program defines a graph spanning CPU-heavy preparation and GPU-heavy training. The model produced by Ray Train is served by Ray Serve in the same cluster, against the same storage. The operational, identity, and observability surface is unified instead of fragmented.

What enterprises deploy with Anyscale on Azure

There are five workloads that power the development of modern AI systems, spanning data processing, training, inference, and simulation. But in most environments, each depends on separate engines, frameworks, and orchestration layers. The resulting fragmentation drives up infrastructure spend, latency, and engineering complexity. This makes a single Ray-based runtime under Anyscale’s managed control plane the operationally rational choice.

Anyscale on Azure provides a complete platform to build and deploy AI applications using the same APIs as open-source Ray. While the data plane runs inside the customer’s AKS cluster, the managed control plane provides a unified interface for development, debugging, and cluster operations.

AI in your trust boundary by design: the architecture

Anyscale on Azure is an Azure Native product — discoverable via the Azure portal and provisioned through Azure Resource Manager with every resource tagged, scoped, and policy‑bound like any other in your subscription.

Anyscale on Azure is a split-plane deployment:

Control plane (managed by Anyscale) — scheduling, jobs, services, workspaces, and observability.
Data plane (your Azure subscription) — Ray clusters run on your AKS, in your VNet, on your storage (Azure Blob / ADLS Gen2 via BlobFuse2).

The trust boundary is what matters — more than any individual data plane feature — for regulated workloads (financial services, healthcare, public sector) and any enterprise where proprietary data is the differentiation.

The execution model:

Workloads run inside your AKS cluster — your subscription, your VNet. Model weights, training data, KV caches, checkpoints, and inference traffic never leave the boundary.
Provisioning is ARM-native — resources tag, scope, and inherit Azure Policy like anything else in the subscription.
Identity is Microsoft Entra ID end to end — workload identity issues pod credentials; RBAC governs access. No long-lived keys, no parallel secret store.
Network controls are yours — Private Link, NSGs, Cilium-based Azure CNI policies, and customer-managed encryption keys via Key Vault.
Audit is the Azure Activity Log — the same surface your compliance team already monitors.
The Anyscale Operator is the only Anyscale-controlled component in your environment — it runs inside your AKS, communicates with the control plane via egress only, and accepts no inbound access from Anyscale.

The result: code and data stay in your Azure subscription. Your existing compliance posture, audit surface, and data residency certifications carry forward — nothing new to attest. Billing rolls through the same Azure invoice with MACC drawdown — no second invoice, no parallel procurement.

Production evidence

Xoople planetary‑scale satellite imagery on Anyscale on Azure; multimodal AI turns spectral data into operational intelligence. "Anyscale lets our teams focus on models and outcomes rather than infrastructure, dramatically accelerating the path from experimentation to deployment," — Milos Colic, VP of Engineering, Xoople.

Wayve trains the next generation of autonomous‑driving foundation models on Anyscale on Azure, running distributed ML and data pipelines across large CPU and GPU fleets. The operational driver is GPU‑capacity aggregation at a scale that no single region or cluster can deliver.

Beyond Anyscale on Azure, the same Ray runtime is used in production at Cursor, Physical Intelligence, xAI, Coinbase, Bedrock Robotics, and Runway. Bedrock Robotics scaled compute 85x on Anyscale without linearly increasing costs. Currently with 12M+ weekly downloads (+400% YoY) and 42K+ GitHub stars and now openly governed under the PyTorch Foundation (Linux Foundation), Ray is becoming the de-factor open-source standard and is not a single-vendor runtime.

Pricing

Pricing is usage‑based and consolidates onto the same Azure invoice as the rest of the customer's subscription, including drawdown against existing Azure commitment (MACC):

Azure infrastructure — standard Azure compute and GPU charges for the AKS substrate the workload runs on, scaling directly with actual usage.
Anyscale service layer — pay‑as‑you‑go through Azure service meters with no upfront commitment, priced by CPU, memory, and GPU type.

Where Anyscale on Azure fits

Base-model intelligence is converging. Enterprises can buy access to the same frontier models, so the model itself is no longer the moat. What separates the enterprises pulling ahead is the layer underneath: how efficiently they run the full AI lifecycle at scale, how much compounding leverage they extract from their proprietary data, and whether they own the runtime that ties it all together. Anyscale on Azure is the Azure Native runtime layer for that posture — bringing the open-source distributed compute standard the AI industry has converged on into the same Azure governance, identity, and procurement model as the rest of the tenant.

The shape of enterprise AI is settling. The teams pulling ahead are not the ones renting the most intelligence through APIs — they are the ones building and operating AI systems inside their own cloud, on their own data, under their own governance, and scaling those systems on the open distributed runtime the industry has already converged on.

Anyscale on Azure is that runtime, delivered as an Azure Native product:

Ray, productionized — the open‑source distributed compute standard for AI, hardened with the Anyscale Runtime, a managed control plane, and observability designed for foundation‑model‑scale workloads.
One runtime, the full AI lifecycle — data preparation, training, fine‑tuning, reinforcement learning, inference, and agentic workloads in a single Python program, on a single substrate, with no cross‑system glue.
Inside your Azure tenant, on the AKS you already run — customer‑owned data, customer‑owned models, customer‑owned governance. Entra identity, Azure RBAC, Private Link, Activity Log audit, and customer‑managed keys end to end.
One Azure invoice — usage‑based pricing through the Marketplace with MACC drawdown; no parallel procurement, no second vendor contract.

If your team is wrestling with GPU utilization, fragmented data‑to‑serving stacks, training jobs that exceed any single region's capacity, or hosted‑API costs that scale faster than your usage — this is the runtime built for that problem.

Try it now

Provision your first Anyscale Cloud by navigating to the Azure portal. Click on "Create" to begin creating the Anyscale cloud resource and link the necessary Azure resources.

Create your Anyscale Cloud directly from Azure Portal.Attach an existing AKS cluster. Configure Storage and ACR Azure resources.Click on "Launch Anyscale" to navigate to the Anyscale console.

Explore the quickstart guides and documentation on Microsoft Learn to get started. For architectural deep‑dives, capacity planning, or a hands‑on workshop with the Anyscale on Azure solution architects, reach out through your Microsoft account team.

Deepen your expertise and deep dive on best practices in the upcoming virtual webinar. Register here.

The infrastructure for the next decade of enterprise AI is here. Build on it.

Links and Resources

Announcing Go support in Azure Functions (Preview)

AnthonyChu — Tue, 02 Jun 2026 20:46:42 GMT

We're excited to announce that Azure Functions now supports Go as a first-class language, available today in public preview on the Flex Consumption plan. Go developers can now build event-driven, serverless applications using idiomatic Go, the standard toolchain they already love, and the full breadth of Azure Functions triggers, bindings, and operational capabilities.

TL;DR: Write Functions in Go using a new code-first programming model and SDK (azure-functions-golang-worker). Use triggers across HTTP, Timer, Service Bus, Event Hubs, Event Grid, Cosmos DB, and Blob Storage.

Why Go on Azure Functions

Go has become a default choice for cloud-native APIs, platform services, networking tools, and high-throughput integration workloads. Until now, teams that standardized on Go on Azure had to either:

Use Azure Functions through the custom handlers protocol, missing out on a first-class developer experience, or
Build and operate their own serving, scaling, and eventing infrastructure on containers or VMs.

With first-class Go support, those teams get the productivity of Go plus the operational leverage of serverless: automatic scaling, pay-per-use billing, integrated triggers across the Azure ecosystem, and built-in observability, without leaving the Go ecosystem.

What's in the preview

A new Go programming model and SDK: a code-first, idiomatic way to register Functions and declare triggers using functional options.
Support for popular triggers: HTTP, Timer, Service Bus (queues and topics), Event Hubs, Event Grid, Cosmos DB, and Blob Storage. More to come.
Native Go build pipeline: go build produces a single static binary that the Functions host invokes directly. No function.json, no interop shims at request time.
Integrated observability: Application Insights logging, metrics, and distributed tracing.
End-to-end tooling: local development with a preview build of Azure Functions Core Tools. Deployment via Core Tools, zip deploy, or GitHub Actions.
Flex Consumption: fast elastic scale, scale-to-zero, per-second billing, VNet integration, and always-ready instances.

A quick look at the programming model

The Go model is code-first: you register functions and declare triggers in Go, with compile-time checks and full IDE support. No separate JSON metadata to keep in sync.

Here's a minimal HTTP-triggered Function:

package main import ( "fmt" "net/http" "github.com/azure/azure-functions-golang-worker/sdk" "github.com/azure/azure-functions-golang-worker/worker" ) func main() { app := sdk.FunctionApp() app.HTTP("hello", hello, sdk.WithMethods("GET", "POST"), sdk.WithAuth("anonymous"), ) worker.Start(app) } func hello(w http.ResponseWriter, r *http.Request) { name := r.URL.Query().Get("name") if name == "" { name = "world" } fmt.Fprintf(w, "Hello, %s!", name) }

Notice the HTTP handler is a plain http.HandlerFunc, the same signature you'd use with net/http or any Go web framework. There's nothing Functions-specific to learn at the handler level.

Registering other triggers

The same pattern works across triggers. Non-HTTP handlers take a context.Context plus a typed payload:

import ( "context" "log" "github.com/azure/azure-functions-golang-worker/sdk" "github.com/azure/azure-functions-golang-worker/sdk/bindings" ) // Timer: runs every 10 seconds func onTimer(ctx context.Context, t bindings.TimerInfo) error { log.Printf("timer fired; past due=%v", t.IsPastDue) return nil } app.Timer("cleanup", onTimer, sdk.WithSchedule("*/10 * * * * *"), ) // Service Bus queue func onOrder(ctx context.Context, msg bindings.ServiceBusMessage) error { log.Printf("order %s: %s", msg.MessageId, string(msg.Body)) return nil } app.ServiceBusQueue("processOrder", onOrder, sdk.WithQueueName("orders"), sdk.WithConnection("ServiceBusConnection"), ) // Event Hubs func onEvent(ctx context.Context, e bindings.EventHubMessage) error { log.Printf("event seq=%d body=%s", e.SequenceNumber, string(e.Body)) return nil } app.EventHub("ingest", onEvent, sdk.WithEventHubName("telemetry"), sdk.WithConnection("EventHubConnection"), ) // Cosmos DB change feed func onChange(ctx context.Context, docs []bindings.CosmosDocument) error { for _, d := range docs { log.Printf("doc %s: %s", d.ID, string(d.Data)) } return nil } app.CosmosDB("onChange", onChange, sdk.WithDatabase("ToDoList"), sdk.WithContainer("Items"), sdk.WithConnection("CosmosDBConnection"), ) // Event Grid func onGridEvent(ctx context.Context, e bindings.EventGridEvent) error { log.Printf("%s: %s", e.EventType, e.Subject) return nil } app.EventGrid("onEvent", onGridEvent)

Extension triggers: real Azure SDK clients

For triggers like Blob Storage, the Go SDK injects a fully-typed Azure SDK client directly into your handler. You opt in with a blank import, so your binary only includes the extensions you actually use:

import ( "context" "io" "log" "github.com/Azure/azure-sdk-for-go/sdk/storage/azblob/blob" "github.com/azure/azure-functions-golang-worker/sdk" _ "github.com/azure/azure-functions-golang-worker/triggers/blob" // registers blob trigger client factory "github.com/azure/azure-functions-golang-worker/worker" ) func onUpload(ctx context.Context, client *blob.Client) error { log.Printf("blob: %s", client.URL()) resp, err := client.DownloadStream(ctx, nil) if err != nil { return err } defer resp.Body.Close() data, err := io.ReadAll(resp.Body) if err != nil { return err } log.Printf("size=%d", len(data)) return nil } app.Blob("onUpload", onUpload, sdk.WithPath("uploads/{name}"), sdk.WithConnection("AzureWebJobsStorage"), sdk.WithSource("EventGrid"), )

The handler receives a *blob.Client from github.com/Azure/azure-sdk-for-go/sdk/storage/azblob/blob, the same client you'd use in any other Go app. Because it's a real SDK client, you can DownloadStream blobs of any size without buffering the whole payload through the worker. Dependencies stay isolated per extension, so apps that don't use Blob never pull in azblob or azidentity.

Project layout

A Go function app is just a regular Go module plus the standard Functions config files:

my-function-app/ ├── host.json ├── local.settings.json ├── go.mod ├── go.sum └── main.go

No function.json and no generated metadata. Triggers are declared in main.go. go build, go test, and go mod tidy all just work.

Get started

Quickstart Install the preview tooling, scaffold your first Go function app, run it locally, and deploy to Flex Consumption.

We can't wait to see what you build. Welcome to Functions, Gophers.

Introducing the Azure Functions serverless agents runtime (preview)

AnthonyChu — Tue, 02 Jun 2026 22:23:58 GMT

We're thrilled to announce the Azure Functions serverless agents runtime, now in public preview. It brings a new, markdown-first programming model for building AI agents as a first-class workload on Azure Functions, with the event-driven triggers, scale-to-zero economics, and operational integrations you know and love from the platform.

A few things you could build in a matter of minutes:

A daily briefing agent that wakes up on a timer, scours the web, and drops a summary in your Outlook inbox every morning.
A Teams chat agent that triggers on every message and answers your team's questions, looking up data across your connected systems.
An on-call troubleshooting agent that investigates incidents by querying logs in Azure Data Explorer and reports back what it found.

Each one is a single markdown file with instructions plus a trigger, and deployed like any other function app and running on the Flex Consumption plan.

Why a serverless agents runtime

Building production agents today usually means stitching together a framework, a hosting layer, message queues, identity, secrets, observability, and a long list of per-service integrations. Most of that work is plumbing, not the agent.

Azure Functions has spent years making event-driven compute simple: declare a trigger, write the handler, get autoscale and managed identity for free. The serverless agents runtime applies that same model to agents:

Agents are the unit of work. You define behavior in natural language, not boilerplate.
Trigger agents from almost any event. HTTP requests, timers, queues, database changes, Teams messages, Outlook mail, and more.
Tools, MCP servers, connectors, and sandboxed execution are declared, not coded.
Deploy and operate like any function app. Flex Consumption for scale-to-zero and per-second billing, managed identity, VNet integration, Application Insights, and the same deployment tools you already use.

Markdown-first: what an agent looks like

An agent is a .agent.md file. Your app can have multiple agents, each with its own metadata that declares the trigger. The markdown body becomes the agent's instructions.

Here's a timer-triggered agent that summarizes the day's tech news and emails it:

--- name: Daily Tech News Email description: Fetches top tech news and emails a summary daily. trigger: type: timer_trigger args: schedule: "0 0 15 * * *" --- You are a news assistant. When triggered, do the following: 1. Scour the web for today's top tech news headlines. Use reputable sources; Include links to the original articles. 2. Summarize the top stories in a concise, well-formatted HTML email body. 3. Email the summary to $TO_EMAIL with the subject "Daily Tech News Summary" followed by today's date.

That's the whole function. Drop the file into your app, deploy, and it runs on the schedule. No framework wiring, no service-specific integration code.

Your agents can share configuration and capabilities through a few files alongside the agent definitions. agents.config.yaml declares system tools and the default model. mcp.json lists the MCP servers your agents can call, including MCP-enabled Azure connections. A /tools folder holds custom Python tools and a /skills folder holds reusable prompt fragments. Everything here is optional and available to every agent automatically when present.

In this example, the agent uses a Container Apps dynamic session to browse the web with Playwright, and a Microsoft Office 365 connection (exposed as an MCP server) to send the email:

# agents.config.yaml system_tools: dynamic_sessions_code_interpreter: endpoint: $ACA_SESSION_POOL_ENDPOINT model: $AZURE_OPENAI_DEPLOYMENT

// mcp.json { "servers": { "office365": { "type": "http", "url": "$MICROSOFT_365_CONNECTION_MCP_ENDPOINT", "auth": { "scope": "https://apihub.azure.com/.default" } } } }

The function app's managed identity authenticates to the connection's MCP endpoint, so there are no secrets to manage. Any Azure connector that supports MCP, or any remote MCP server, can be added the same way.

Any of these global settings can be overridden per agent in the agent's metadata.

What you get in the preview

Triggers across the Azure Functions catalog. HTTP, Timer, Queue, Service Bus, Event Hubs, Cosmos DB, Blob, Event Grid, plus new connection-backed triggers like Teams messages, Outlook mail, and calendar events.
1,400+ Azure connectors as tools. Create a connection, enable its MCP endpoint, and an agent can send mail, post to Teams, create records, query data, all without integration code or auth plumbing.
Any remote MCP server as tools. Use any remote MCP server.
Sandboxed code and browser automation. Run code or a Playwright-powered browser in Azure Container Apps dynamic sessions, isolated per agent session.
Built-in chat UI, HTTP API, and MCP server endpoint with no extra code.
Custom Python tools in a tools/ folder and reusable skills in a skills/ folder, shared across agents.
Pluggable model providers. Microsoft Foundry, Azure OpenAI, and OpenAI out of the box.

Where this fits

The serverless agents runtime is designed for the agents most enterprises actually need to build:

Scheduled background agents that summarize, monitor, or reconcile on a timer.
Event-driven assistants that react to messages, emails, alerts, and database changes.
Cross-system agents that tie multiple SaaS and enterprise apps together through connections. Trigger with a Teams message, look up the customer in Salesforce, send an email, and update a database record, all from one agent.
Conversational front-ends that pair an HTTP or chat-UI entry point with the same agents your event triggers invoke.
Agents as MCP servers that other agents and MCP clients can integrate with directly.

We want your feedback

The serverless agents runtime is in public preview, and we're actively building it out with input from real customer workloads. Tell us what you build, what's missing, and where the model should go next.

Get started

Docs: aka.ms/azure-functions-agents-docs

Building agents on Azure Functions has never been easier. We can't wait to see what you create with the serverless agents runtime!

Azure Functions MCP Extension: What's New at Build 2026

lily-ma — Tue, 02 Jun 2026 21:02:12 GMT

The Azure Functions MCP extension has had a breakout year! Since its initial preview, the extension has grown from a single trigger type into a full-featured platform for building remote MCP servers: with tool, resource, and prompt triggers across multiple languages, MCP Apps for interactive UIs, built-in MCP authentication, and feature enhancements. Here's what's new and what it means for developers building MCP servers on Azure Functions.

The full MCP primitive set: Tools, resources, and prompts

When the MCP extension first shipped, it supported tool triggers. Declare a function as an MCP tool, and any MCP client can discover and call it. That was the starting point.

Since then, we've shipped the remaining MCP primitives:

Resource triggers: expose a function as an MCP resource.
Prompt triggers: expose a function as an MCP prompt, letting clients request structured prompt templates from your server.

Like tool triggers, resource and prompt triggers are supported in multiple languages including .NET, Java, Python, TypeScript, and JavaScript.

MCP Apps: interactive UI from your MCP server

MCP Apps let your tools return interactive user interfaces instead of plain text. Combine tool triggers with resource triggers, and your MCP server can serve rich, rendered experiences to MCP-aware clients.

The Azure Functions MCP extension supports MCP Apps natively, meaning the same function app that exposes tools and resources can also serve UI components. The launch blog post on the Azure Apps Blog walked through the pattern in detail.

For .NET developers, the new fluent builder API (available in the latest NuGet release) makes it easier to compose MCP Apps by chaining tool and resource definitions in a declarative style.

MCP Apps allow servers to return results in customize, interactive UIs that users can directly interact with in compatible clients.

MCP authentication

The extension supports built-in MCP authentication, implementing the requirements of the MCP auth spec. All samples in the aka.ms/remote-mcp repo enable built-in MCP auth by default with Microsoft Entra ID as the identity provider.

Samples have also been updated to demonstrate how to exchange tokens in the On-Behalf-Of (OBO) flow, so your MCP tools can access downstream APIs using the invoking user's identity.

Auth configuration in the Azure portal: Preview at Build is a one-click experience in the Azure portal for configuring built-in MCP auth. No more manual app registration creating, configuration and wiring to the server. Just open your server app on the portal and click to enable MCP auth. Try it out!

Feature enhancements

Beyond the headline primitives and auth, the extension has shipped a steady stream of capabilities the past few months. The following are the notable additions.

Structured content

Structured content lets you return machine-readable JSON metadata alongside your tool's response via the `structuredContent` field. Clients that support it can programmatically consume the data (e.g. parse fields, render tables, drive downstream logic) rather than just displaying text. Clients that don't support it still get the regular content blocks as a fallback.

Rich content types

Tools aren't limited to returning plain text. The extension supports the full set of MCP content block types, e.g. `TextContent`, `ImageContent`, `AudioContent`, `ResourceLink`, and `EmbeddedResource`, so your tools can return images, audio clips, references to resources, and inline file content alongside text.

Input and output schemas

`WithInputSchema` and `WithOutputSchema` give you explicit control over the JSON schemas advertised for your tools. This is especially useful when the auto-generated schema from function parameters doesn't capture the full contract. For example, when your tool accepts a complex nested object or returns a specific shape that clients depend on. Input and output schemas are currently supported in .NET, with support for other languages coming soon.

builder.ConfigureMcpTool("SearchDocs") .WithOutputSchema(""" { "type": "object", "properties": { "results": { "type": "array", "items": { "type": "string" } }, "query": { "type": "string" } }, "required": ["results", "query"] } """);

Fluent configuration APIs in .NET

A set of fluent builder APIs that let you configure MCP primitives declaratively in `Program.cs`:

ConfigureMcpTool: add properties, metadata, input/output schemas, or promote a tool to an MCP App
ConfigureMcpResource: attach metadata to resources
ConfigureMcpPrompt: define prompt arguments and metadata

builder.ConfigureMcpTool("sayhello") .WithProperty("name", McpToolPropertyType.String, "Name of the user", required: true) .WithMetadata("ui", new { resourceUri = "ui://index.html" });

What's next

Usage of the MCP extension has grown steadily since its preview launch. Tool execution volume has increased 15x over the past several months as more customers move from experimentation to production. As adoption grows, so do the expectations. Developers building production MCP servers are hitting real friction around auth complexity, client configuration, and observability. We're continuing to invest in the extension to address these gaps and help customers be more successful building and hosting MCP servers on Azure Functions. Here's where we're focusing next.

Continued auth simplification

Auth remains the biggest barrier to getting an MCP server into production. We'll work on:

Smoother client setup: making it easier to connect any MCP client to an authenticated Azure Functions MCP server, not just VS Code.
Simplified OBO flow: streamlining the experience of On-Behalf-Of authentication so developers can delegate user identity to downstream services with less configuration.

Our goal: the secure path should be the easy path.

Deeper integration with Microsoft Foundry

We'll build tighter integration between Azure Functions MCP servers and Microsoft Foundry. This includes surfacing MCP servers in Foundry Toolbox, a new feature introduced to help Foundry agents discover and consume tools from a single endpoint. Developers will be able to publish an MCP server from Functions and have it available to Foundry agents through Toolbox without manual endpoint configuration.

Continued feature enhancement

We prioritize based on feedback from the community raised in our GitHub repo. For example, support for streaming output and pagination are top items in our backlog today based on user demand.

We also track the MCP spec's evolution closely and will continue shipping support for strategic features as they land. Examples of proposals we're following:

MCP Tasks: the Tasks extension (SEP-2663) defines a standard pattern for async, long-running tool calls with durable task handles. This replaces hand-rolled polling patterns and aligns well with Functions' execute-and-return model.
Stateless MCP: SEP-2575 proposes removing the mandatory initialization handshake, which is a natural fit for serverless platforms like Azure Functions where fresh instances can handle any request.

Have something you'd like us to prioritize? Let us know by filing a request on GitHub.

Get started

Samples: Samples showcasing most up-to-date features: aka.ms/remote-mcp
Documentation: Model Context Protocol for Azure Functions
MCP Extension GitHub repo: Azure Functions MCP Extension

Introducing On-demand Sandboxes for Azure Durable Task Scheduler (Private Preview)

greenie-msft — Tue, 02 Jun 2026 19:30:00 GMT

Maybe it needs a native toolchain. Maybe it runs untrusted customer or LLM-generated code. Maybe it needs Python from a .NET orchestrator, or bursty compute that should scale to zero when the work is done.

Today, we're thrilled to announce On-demand Sandboxes for Azure Durable Task Scheduler, now available in private preview. On-demand Sandboxes lets you move those individual workflow steps to managed, isolated compute while your orchestrator stays exactly where it is. Tell DTS which steps should run in isolation, provide a container image with the step code, and DTS handles provisioning, scaling, and teardown. No infrastructure to manage, no idle costs, no orchestrator changes.

Sign up for On-demand Sandboxes Private Preview Today →

Availability: On-demand Sandboxes targets the standalone Durable Task SDKs used outside the Azure Functions host — for apps running on Azure Container Apps, Azure Kubernetes Service, App Service, or anywhere else you self-host. The private preview supports the .NET and Python Durable Task SDKs, with additional language SDKs and Azure Functions support coming soon.

What is Azure Durable Task Scheduler?

The Durable Task Scheduler is a fully managed backend for durable execution on Azure. It can serve as the backend for a Durable Function App using the Durable Functions extension, or as the backend for an app leveraging the Durable Task SDKs in other compute environments, such as Azure Container Apps, Azure Kubernetes Service, or Azure App Service. For a deeper introduction, see the Durable Task Scheduler overview or the full Durable Task documentation.

Why On-demand Sandboxes?

Most activities belong in-process. They're fast, simple, and co-located with your orchestrator. But sometimes you hit a step that doesn't fit: it needs a native binary, a different language runtime, per-invocation isolation, or bursty compute you don't want to keep warm. On-demand Sandboxes gives you a way to handle those exceptions without spinning up dedicated infrastructure or managing scaling policies in Azure Kubernetes Service or Azure Container Apps.

Activity-level granularity. Move individual steps to managed compute, not your whole app.
Per-activity or per-invocation isolation. Each execution runs in a clean, microVM-backed sandbox. Ideal for untrusted code, customer plugins, or LLM-generated logic.
Cross-runtime flexibility. Run a Python inference step from a .NET orchestrator. No compromise on either side.
Scale-to-zero. Pay for CPU and memory per second of execution, not infrastructure that waits.
No orchestrator changes. Your orchestration code and hosting model don't change at all.

Here are a few scenarios where On-demand Sandboxes shines:

Native toolchains. Package ffmpeg, LibreOffice, or Pandoc in a container without dragging them into your main app.
CPU-heavy preprocessing. OCR, layout extraction, or image processing can scale independently of the rest of your workflow.
Cross-runtime workflows. A .NET orchestrator dispatches a Python inference step. No compromises.
Sandboxed code execution. Run customer plugins or LLM-generated code with a clean boundary on every invocation.
Multi-tenant isolation. Tenant-specific steps get dedicated boundaries while everything else stays in-process.
Bursty event-driven workloads. Steps that spike hard but rarely may not justify always-on infrastructure. Sub-second cold starts mean you get capacity when you need it without paying to keep it warm.

How it works

On-demand Sandboxes uses a two-part model: a worker profile in your orchestrator app that tells DTS which activities to offload, and a worker image that contains those activity implementations. Your orchestrator still calls activities the same way it always has; the decision to run one activity in a sandbox lives in the profile configuration.

1. Declare a sandbox worker profile

In the app that hosts your orchestrator, define a sandbox worker profile. The profile gives DTS the container image, resource shape, concurrency setting, and activity names that should run in a sandbox:

using Microsoft.DurableTask.Worker.AzureManaged.Sandbox; [SandboxWorkerProfile("code-executor")] internal sealed class CodeSandboxWorkerProfile : ISandboxWorkerProfile { public void Configure(SandboxOptions options) { options.ContainerImage = Environment.GetEnvironmentVariable("DTS_SANDBOX_IMAGE") ?? throw new InvalidOperationException("DTS_SANDBOX_IMAGE is required."); options.Cpu = "1000m"; options.Memory = "2048Mi"; options.MaxConcurrentActivities = 1; options.AddActivity(TaskNames.ExecuteCode); } }

Then enable on-demand sandbox discovery when you configure the Durable Task worker in the main app:

workerBuilder.AddTasks(tasks => tasks.AddAllGeneratedTasks()); workerBuilder.UseDurableTaskScheduler(options => { options.EndpointAddress = Environment.GetEnvironmentVariable("DTS_ENDPOINT"); options.TaskHubName = Environment.GetEnvironmentVariable("DTS_TASK_HUB"); options.Credential = credential; }); workerBuilder.EnableSandboxes();

Here's what the profile configuration does:

SandboxWorkerProfile: a friendly profile id for this sandbox setup. It groups the activity, image, and resource settings for monitoring and reuse across deployments.
ContainerImage: the container image (from your registry) that contains the activity implementations.
Cpu / Memory: the resource shape for each worker instance. Sized per your activity's needs.
MaxConcurrentActivities: how many activities a single worker instance can process concurrently.
AddActivity: the specific activity to offload. Only activities added to a sandbox worker profile execute in DTS-managed isolated compute; everything else stays in-process.

The orchestrator call site doesn't change:

ExecuteCodeOutput execution = await context.CallActivityAsync<ExecuteCodeOutput>( TaskNames.ExecuteCode, new ExecuteCodeInput(pythonCode, input.CsvData));

ExecuteCode is not registered in the main app's in-process activity list. When the orchestrator calls it, DTS uses the codegen profile to route the work to the sandbox image.

2. Build the worker image

The worker image is a container you own. In most apps, this worker lives in a separate project from the orchestrator host so it can have its own entry point, dependencies, and container image. It registers the activity implementations it can run and opts in to managed execution with UseSandboxWorker():

builder.Services.AddDurableTaskWorker(workerBuilder => { workerBuilder.AddTasks(tasks => { tasks.AddActivity<ExecuteCodeActivity>(); }); workerBuilder.UseSandboxWorker(); });

UseSandboxWorker() is the key line. It signals that this worker runs in DTS-managed compute. The sandbox worker does not need to configure the DTS endpoint, task hub, profile id, or credentials; DTS injects the runtime settings when it starts the container.

The activity implementations themselves are standard Durable Task activities. There's nothing special about the activity code: it can call a runtime with different dependencies, such as Python and pandas, while running in an isolated container instead of in your main app's process.

Package the image like any containerized service, including whatever runtimes and native tools the activity needs. Push it to your container registry (e.g., Azure Container Registry) and reference the image in the worker profile's ContainerImage option.

View logs in the DTS dashboard

Once your sandbox activities are running, you can view their execution logs directly in the Durable Task Scheduler dashboard. The dashboard shows real-time output from your managed workers, including stdout, stderr, and activity lifecycle events. This gives you full visibility into what's happening inside the sandbox without needing to configure external log sinks or set up your own observability pipeline.

Demo

Get started

On-demand Sandboxes is in private preview. To get access, sign up here. We'll enable the feature on your scheduler and help you get your first sandbox activity running.

Once you're in, the workflow is straightforward: declare a sandbox worker profile in your orchestrator app, build and push a worker image, and DTS takes care of the rest.

Sign up for On-demand Sandboxes Private Preview Today →

Documentation: Durable Task Scheduler overview

Samples: Azure-Samples/Durable-Task-Scheduler

Pricing: Azure Durable Task Scheduler pricing

Questions, feedback, or ideas? Open an issue in the Durable-Task-Scheduler GitHub repo. We'd love to hear from you.

Announcing Anyscale on Azure public preview: Powered by Ray on AKS

Brendan Burns — Tue, 02 Jun 2026 19:30:00 GMT

What's new

The defining workload of the cloud era is no longer a web service or a database. It is a distributed AI training or inference job that needs thousands of GPUs, a coherent data plane, and a way for a handful of engineers to operate all of it without losing their weekends. Getting there is still harder than it should be. GPU capacity is fragmented across regions and SKUs, data is scattered across the lifecycle, and identity and credentials sprawl with every cluster a team adds.

Today, I’m excited to announce the public preview of Anyscale on Azure, bringing Anyscale’s managed Ray platform and the Anyscale Runtime natively to Azure, all running on Azure Kubernetes Service (AKS). It is the fastest path I have seen from a single notebook to a multi-region distributed AI job, running on the AKS clusters your platform team already operates.

Bringing the power of Ray to Azure

When I talk with customers who are scaling AI on Kubernetes, the same three problems come up:

Capacity is fragmented. GPU supply lives across regions, SKUs, and quotas, and a single cluster is rarely enough to satisfy a serious training run.
Data is stranded. Training, fine-tuning, and inference each pull from different stores, in different formats, with different access patterns, and that gap quietly slows every team down.
Operations don’t scale. Credentials, identity, observability, and upgrade paths pile up cluster by cluster until the platform team becomes the bottleneck.

Anyscale and Microsoft have been working together to solve all three of these challenges, and today that work is ready for customers to try in public preview.

“At Anyscale, we’re building a company around Ray. Ray is the open-source distributed compute engine for scaling python and AI workloads. What we’re bringing with Anyscale is the production layer on top: a performance-enhanced runtime, developer tooling, and managed operations so teams can stay focused on building. And now this is all delivered in an Azure-native manner with enterprise readiness on AKS.”

Robert Nishihara, Co-founder, Anyscale

What’s available in public preview today

Starting today, you can provision and manage Anyscale on Azure directly from the Azure Portal or the Azure CLI, the same tools your platform team already uses for everything else. From Azure, you get native billing, identity, and cluster lifecycle management. From the Anyscale platform, your ML engineers get workspaces, job scheduling, and the Anyscale Runtime to build, train, and serve models without stitching infrastructure together. The solutions can help your organization across these three key areas:

Scaling GPU capacity: Anyscale on Azure delivers elastic scalability through multi-cluster, multi-region capacity aggregation. A single Ray job can pull GPUs from wherever they happen to be available across your Azure footprint, so you stop building your training plan around the limits of any one cluster.
Reliability across the AI lifecycle: The Anyscale Runtime, paired with Azure storage, gives you a unified data plane that spans experimentation, training, fine-tuning, and inference. Training data, checkpoints, and inference artifacts live in one place from dev to production. Engineers stop stitching pipelines together and start shipping models.
Governance and security: Anyscale on Azure uses Microsoft Entra workload identity with automated credential management on the AKS-native control plane. Your platform team keeps the operational model they already know, with the same RBAC, the same audit trail, and the same policies, without rolling new identity systems for every new AI workload.

What customers are already building

Wayve is a self-driving startup training the next generation of self-driving models that power autonomous vehicles. Their work depends on aggregating GPU capacity at a scale no single region or cluster can deliver, which makes Anyscale on Azure’s elastic, multi-region capacity model exactly the unlock their training teams need.

“Wayve and Microsoft have a deep partnership focused on scaling embodied AI and the infrastructure behind it. As Wayve’s AI platform and data operations have grown, Azure has become a core part of its large-scale compute and ML stack.

Wayve uses Ray, and increasingly Anyscale on Azure to run distributed ML and data pipelines across large CPU and GPU fleets, supporting large-scale inference, analytics, and dataset processing with improved efficiency and resiliency. This enables Wayve to train and deploy its autonomous driving AI at the speed and scale needed for safe, real-world deployment globally."

Girish Venkataramani, VP of Engineering, Wayve AI

Xoople gathers global, high-quality Earth observation data through satellites, sensors, and other remote-sensing tools, then turns it into AI models that help customers understand the planet. Pipelines like theirs need to scale on demand without forcing a small team to stand up and operate Ray themselves, which is exactly what the managed model in Anyscale on Azure delivers.

"What Xoople is doing is incredibly important as they are creating Earth's System of Record, the data layer AI has been missing, whilst also defining a new category that will transform decision making for the Enterprise.

With Anyscale on Azure, Xoople can reliably run massively distributed AI workloads over planetary-scale satellite imagery, transforming complex spectral data into decision-ready intelligence.

Anyscale lets our teams focus on models and outcomes rather than infrastructure, dramatically accelerating experimentation to deployment. For our product teams and theirs, this means a faster stream of information, more agility and improved risk management.”

Milos Colic, VP of Engineering, Xoople

Built on the AKS you already run

Anyscale on Azure runs on standard Azure Kubernetes Service. There is no fork or special cluster type. It composes with the AI work AKS has shipped over the last year: Dynamic Resource Allocation for GPUs, Multi-Instance GPU, NVIDIA Dynamo for multi-node inference, KAITO for fine-tuning and RAG, and Azure Container Storage v2 for stateful AI workloads. If you prefer open-source Ray, KubeRay on AKS continues to be a great path. Anyscale on Azure is for teams that want a managed Ray platform with the Anyscale Runtime, fully integrated with the AKS clusters and Azure services they already use.

Frequently asked questions

What’s the release status?

Public preview, available today.

Do I need to migrate off open-source KubeRay?

No. Open-source Ray on AKS continues to be fully supported. Anyscale on Azure is for teams that want a managed Ray platform with the Anyscale Runtime. Learn how to easily onboard your open-source Ray into Anyscale on Azure.

How does pricing work?

Pricing is usage-based with two components: the Azure infrastructure you consume, and the Anyscale service layer.

Azure infrastructure. You pay Azure for the underlying AKS infrastructure you use, including compute and GPUs, and those charges scale directly with actual usage.
Anyscale service. Pay-as-you-go through Azure service meters with no upfront commitment, based on CPU, memory, and GPU type. Anyscale charges for the orchestration and management layer, not for GPU capacity itself. Rates align with Anyscale’s global pricing list, with no regional multipliers at the Anyscale service layer. Anyscale Enterprise Support is included with the service.

Get started

Start a workspace on Anyscale on Azure → aka.ms/AnyscaleonAzureOverview
Watch our session from Microsoft Build on AKS and the Anyscale announcement: BRK222: The honest practitioner's take on agentic AI on Kubernetes

A huge thank-you to the Anyscale team and to the Ray community. This work would not exist without either of them. This is the start of the work, not the end. We have more coming on the roadmap, including expanded region coverage, deeper integration with the AKS AI stack, and continued investments in elastic, multi-region distributed training and inference. I cannot wait to see what you build.

Announcing managed connectors for Azure Functions (Preview)

nzthiago — Tue, 02 Jun 2026 19:30:00 GMT

Azure Functions now includes managed connectors in public preview - the same 1,400+ connector ecosystem behind Logic Apps and Power Platform - as first-class triggers in your Functions code, plus typed SDKs for invoking connector actions from your function body. Build event-driven integrations with Microsoft 365, Salesforce, ServiceNow, SAP, Dynamics 365, and 1,400+ other systems using familiar Functions syntax.

This release is the result of close collaboration between the Azure Functions team and the Connectors team, the same team that builds and maintains the connector ecosystem behind Logic Apps and Power Platform. Triggers, SDKs, and the connection runtime were designed together so that connectors feel native to Functions, and so that the connector library that already powers thousands of Logic Apps workflows in production is available to Functions developers.

The integration is built on the new Connector Namespace service, which brings the Logic Apps/Power Platform connector runtime to developers as a programmable integration layer.

A quick look: new Outlook email → post to Teams

Here's a function example (adapted from the sample app): the Office 365 trigger fires on every new email in the watched inbox, and the function posts a notification to a Teams channel using the Teams connector SDK.

using Microsoft.Azure.Functions.Worker; using Microsoft.Azure.Functions.Worker.Extensions.Connector; using Azure.Connectors.Sdk.Office365.Models; using Azure.Connectors.Sdk.Teams; using Azure.Connectors.Sdk.Teams.Models; public class ProcessEmail(TeamsClient teams) { private readonly string _teamId = Environment.GetEnvironmentVariable("TEAMS_TEAM_ID")!; private readonly string _channelId = Environment.GetEnvironmentVariable("TEAMS_CHANNEL_ID")!; [Function("OnNewEmail")] public async Task Run([ConnectorTrigger] Office365OnNewEmailTriggerPayload payload) { foreach (var email in payload.Body?.Value ?? []) { var message = new PostMessageRequest { Recipient = new() { GroupId = _teamId, ChannelId = _channelId }, MessageBody = $"📧 New email From: {email.From} Subject: {email.Subject}" }; await teams.PostMessageToConversationAsync("Flow bot", "Channel", message); } } private sealed class PostMessageRequest : DynamicPostMessageRequest { public RecipientInfo Recipient { get; set; } = new(); public string MessageBody { get; set; } = ""; } private sealed class RecipientInfo { public string GroupId { get; set; } = ""; public string ChannelId { get; set; } = ""; } }

The TeamsClient is registered with DI at startup against the Teams connection's runtime URL — the same managed identity the trigger uses authenticates the outbound call. No OAuth code in the function. No HTTP client. No token handling.

For the complete end-to-end samples see the Functions Connectors Samples repo.

What's shipping in preview

Connector triggers. First-class Functions triggers backed by Connector Namespace connections - Office 365 new-email, Teams message-posted, SharePoint item-created/updated, Dataverse row-changed, Salesforce record-updated, calendar events, and more. Configured via the [ConnectorTrigger] attribute (C#) and equivalent decorators as language SDKs roll out.
Typed connector SDKs. Strongly-typed client libraries for invoking connector actions from inside your function — OutlookClient, TeamsClient, Office365UsersClient, DataverseClient, SalesforceClient, and growing. Built jointly by the Connectors and Functions teams.
Auth via managed identity and built-in authentication. Configure the function app with built-in authentication to allow only the Connector Namespace to trigger the function. See .NET sample: built-in authentication with managed identity.
Observability. Every connector trigger run is recorded with information about the run. End to end tracing into the Function App is on the roadmap.

Typed SDKs are rolling out incrementally. Not all 1,400+ connectors have strongly-typed SDKs today, and language coverage will expand over time. You can see the ones supported in the different SDK repos for .NET, Python, and Node.js.

The connector catalog

The full catalog is the Logic Apps connector library is in scope. Below are the categories most relevant to enterprise integrations:

Microsoft 365

Outlook (Office 365) — send email, create drafts, search mailbox, read calendar, manage events
Microsoft Teams — post messages, create channels, list team members, manage meetings and tabs
SharePoint — read and write lists and document libraries, subscribe to item-created/updated events
OneDrive for Business — upload and download files, manage folders, track changes
Excel Online (Business) — read and write worksheets, add rows, call named functions in workbooks

CRM and operations

Dataverse / Dynamics 365 — full entity CRUD across all standard and custom tables; use ODATA filters
Salesforce — query and write contacts, leads, opportunities, and cases via SOQL
ServiceNow — create and update incidents, change requests, and CMDB records
Workday — read worker, position, and organization data

ERP and data

SAP — call BAPIs and read tables (uses on-premises data gateway for SAP behind a firewall)
SQL Server — execute queries, stored procedures, and table operations
Oracle Database — same surface as SQL Server
PostgreSQL — query and write via the generic SQL connector

Developer and platform

Azure DevOps — read and write work items, pipelines, repositories, and pull requests
GitHub — manage issues, PRs, and repository content.

More trigger examples

// Office 365 — new email [Function("OnNewEmail")] public Task OnNewEmail([ConnectorTrigger] Office365OnNewEmailTriggerPayload payload) { /* ... */ } // Teams — new channel message [Function("OnTeamsMessage")] public Task OnTeamsMessage([ConnectorTrigger] TeamsOnNewChannelMessageTriggerPayload payload) { /* ... */ } // SharePoint — list item created [Function("OnTicketCreated")] public Task OnTicketCreated([ConnectorTrigger] SharePointOnNewListItemTriggerPayload payload) { /* ... */ } // Salesforce — record updated [Function("OnOpportunityUpdated")] public Task OnOpportunityUpdated([ConnectorTrigger] SalesforceOnRecordUpdatedTriggerPayload payload) { /* ... */ }

The connection that backs each trigger is configured on the Connector Namespace as part of deployment, so trigger declarations stay focused on the event payload, not on auth or connection wiring.

Pricing

There is no extra cost for the integration itself. You pay:

Existing Azure Functions pricing for execution (Flex Consumption per-second billing).
Existing Logic Apps connector pricing for connector calls, billed at the same per-action rates Logic Apps customers pay today.

See the Logic Apps pricing page for current connector rates and standard/enterprise connector tiers.

Preview restrictions

Language and runtime support: typed SDKs and the [ConnectorTrigger] attribute ship first for C# (.NET 10 isolated worker), followed closely by Python and Node.js. Java, and PowerShell are on the roadmap.
Typed SDK coverage: not every connector in the 1,400+ catalog has a typed SDK yet but coverage is expanding.
Regional availability: connector triggers are enabled per region as Connector Namespace rolls out. Check the documentation for the current region list.

Calls to action

Developers building integrations with SaaS or enterprise systems should explore managed connectors in Azure Functions to reduce integration complexity and accelerate delivery.
Partners can position this for customers migrating from on-premises integration platforms or looking to modernize custom integration code into a serverless, event-driven architecture.
Customers running both Logic Apps and Functions today can consolidate integration logic: keep workflow-style orchestrations in Logic Apps, and move code-first event-driven integrations into Functions with the same connector library.

Get started

Documentation: Azure Functions integration with managed connectors
Samples: Azure Functions integration with managed connectors in Azure Functions samples

Looking for connectors as tools for AI agents? That's covered in the serverless agents Azure Functions runtime, which builds on this same Connector Namespace integration to expose connections as MCP tool servers for the agents runtime.

Introducing Azure Container Apps Sandboxes: Secure Infrastructure for Agentic Workloads

vyomnagrani — Tue, 02 Jun 2026 19:30:00 GMT

Today we are announcing the public preview of Azure Container Apps Sandboxes - a new first-class resource type that gives you fast, secure, ephemeral compute environments with built-in suspend and resume. This is the underlying infrastructure on which products like Cloud sandboxes in GitHub Copilot, Foundry Hosted Agents, and Azure Container Apps Express are built, you now have the opportunity to build your solutions leveraging this infrastructure.

Azure Container Apps Sandboxes unlocks two massive opportunities. For platform developers and ISVs, sandboxes give you the same isolated compute fabric that powers many Microsoft products. You get the building blocks to create your own multi-tenant platform on proven, enterprise-scale infrastructure. For AI agents, sandboxes become a self-configurable tool that lets agents extend their own capabilities on the fly. An agent can spin up a fresh sandbox in milliseconds and use it to execute untrusted code, compile source, test HTTP requests against a live app, launch a browser session, or tackle whatever needs a quick and scalable infrastructure.

On one side it empowers humans to build platforms, on the other it empowers agents to build their own capabilities. Both get enterprise-grade isolation, instant startup, and snapshot-based persistence out of the box.

We'll walk through the resource model, sandbox lifecycle, the features that set Sandboxes apart - like snapshots, lifecycle policies, network egress controls, volumes, and managed identities - and show you how to get started with the portal and CLI.

What Are Container Apps Sandboxes?

Container Apps Sandboxes are secure, isolated compute environments that start in sub-second time, scale to thousands, and cost nothing when idle. Each sandbox runs in its own hardware-isolated microVM boundary - fully separated from the host, the platform, and every other sandbox. You bring your own Open Container Initiative (OCI) image, and Sandboxes handle the rest: provisioning from prewarmed pools, strong multi-tenant isolation, and snapshot-based suspend/resume that preserves full memory and disk state across sessions.

There are many ways Sandboxes can help you build your next project - here are a few:

Your own build & test systems - wire a Sandbox into your CI/CD flow to run builds while your laptop stays cool.
Agents that can run anything safely - an agent spawns a sandbox, executes work inside it, and returns the output with no agent host privileges required.
Agent swarms - decompose a research question, spawn N sandbox workers in parallel (each pinned to its own image and egress policy), and synthesize the result.

Early access customers are already unlocking significant benefits by leveraging Azure Container Apps Sandboxes.

"With Azure Container Apps sandboxes, SitecoreAI can safely enable agents to take real action. The combination of multi-tenant isolation, rapid scale-out, and full automation allows Sitecore to run long-lived, autonomous agents that securely execute code, manage workflows, and interact with enterprise systems within secure, governed environments.

With this foundation, we can build agents that do real work: assembling content, personalizing experiences, and optimizing campaigns in production. Agents that operate continuously, learn from results, and improve over time, so our customers get better outcomes without giving up control."

- Mo Cherif, VP of AI and Innovation, Sitecore

"We got early access to Azure Container Apps Sandboxes, and got the first prototype integrated with Atlas AI in hours, and it's already shaping a new Atlas AI capability that we plan to launch in preview in Q3.

It gives every Atlas AI agent a safe, sandboxed workspace (file system, terminal, code execution) on a customer's live data in Cognite Data Fusion. The value: Industrial process, reliability, and production engineers spend days and weeks on questions like "which wells are underperforming and why?" These questions are tractable but expensive, so they are asked rarely and decisions are made on gut feel. With this, an agent pulls the data, runs the analysis, cross-references maintenance and inspection records, and returns a cited draft in minutes. Sandboxes make it practical: Aligned feature set, per-customer isolation, pause/resume across multi-day investigations, scale-to-zero economics."

- Kelvin Sundli, Product manager, Atlas AI, Cognite

Resource Model: Sandbox Groups and Sandboxes

The top-level ARM resource is Microsoft.App/SandboxGroups. A Sandbox Group is the management boundary for a collection of sandboxes that share configuration - think of it like a Container Apps Environment, but purpose-built for sandboxes.

When you create a Sandbox Group, you specify:

Subscription, Resource Group, and Region
Sandbox defaults (optional): default CPU, memory, disk, max sandbox count, and default idle timeout
Networking: optionally deploy into a custom VNet with a dedicated subnet for private networking
Identity: System or user assigned Entra identity.

Individual sandboxes are created within a Sandbox Group. Each sandbox has its own source (disk image or snapshot), resource tier, lifecycle policy, network egress policy, environment variables, ports, volumes, and connections.

Sandbox Lifecycle

Sandboxes have a well-defined lifecycle with the following states:

State	Description
Creating	Provisioning the sandbox from a disk image or snapshot
Running	Actively executing - backed by a live microVM
Idle	System-suspended after inactivity; can auto-resume on the next request
Suspended	Full state (memory + disk) preserved as a snapshot; no compute costs
Resuming	Restoring from a suspended or idle state - sub-second for most workloads
Stopped	User-initiated stop; can be resumed
Stopping	Graceful shutdown in progress
Deleting	Teardown in progress

The key insight here is the distinction between Idle and Suspended. When a sandbox goes idle (e.g., no traffic for a configured timeout), the system can automatically suspend it and capture a snapshot. When a new request arrives, the sandbox resumes transparently. This gives you scale-to-zero economics with stateful compute - something that wasn't possible before without significant custom engineering.

Disk Images: Bring Your Own Container

Sandboxes boot from Disk Images - Open Container Initiative (OCI) images converted into an optimized root filesystem format. You point to any OCI image (public or private registry), and the platform builds a bootable disk image from it.

You can start with public, pre-built images maintained by the platform (for example, Ubuntu base images), or bring your own private images. For private registries, you can authenticate with username/token or use a user-assigned managed identity for Azure Container Registry (ACR) – integrated with Azure as you expect.

Snapshots: Full-State Persistence

Snapshots capture the complete state of a running sandbox - memory, disk, and all running processes. When you resume a sandbox from a snapshot, every process, open file handle, and in-memory data structure is restored exactly as it was.

A snapshot captures the full state of a running sandbox: memory pages, disk, processes. Two ways to make one - automatically on suspend, or manually on demand. Three things they're great for:

Checkpointing mid-task so a long-running agent can resume exactly where it left off
Cloning an environment that's already warm - dependencies installed, caches populated, services running
Shipping a "ready-to-go" state that resumes in sub-second instead of cold-booting

Snapshots are free during the preview, after which they will be stored as Azure Blob Storage at standard rates. Each snapshot records the source sandbox, resource allocation (CPU, memory, disk), and container metadata - so what you get back is exactly what you snapshotted.

Resource Tiers

Every sandbox is assigned to a resource tier that determines its CPU, memory, and disk allocation:

Tier	CPU	Memory	Disk
XS	0.25 vCPU	0.5 GB	5 GB
S	0.5 vCPU	1 GB	10 GB
M (default)	1vCPU	2 GB	20 GB
L	2 vCPU	4 GB	40 GB
XL	4 vCPU	8 GB	80 GB

When creating a sandbox from a snapshot, the resource tier is inherited from the snapshot and cannot be changed - this ensures the restored environment has the exact resources it was running with when the snapshot was taken.

Lifecycle Policies: Auto-Suspend and Auto-Delete

Every sandbox can be configured with lifecycle policies that automate state transitions and cleanup:

Auto-Suspend

Idle timeout: How long a sandbox can sit idle before being suspended (configurable: 1m, 2m, 5m, 10m, 30m, 60m)
Suspend mode:
- Disk + Memory (default): Full snapshot including memory state - resume picks up exactly where you left off, with all processes and in-memory data intact.
- Disk: Only the disk is preserved; the VM restarts fresh on resume. Useful when you only need file persistence, not process continuity.

Auto-Delete

Automatically delete sandboxes after a configurable number of days of inactivity
Prevents accumulation of abandoned sandboxes that consume snapshot storage

These lifecycle policies are what make Sandboxes economically viable at scale. A platform serving thousands of tenants can configure aggressive idle timeouts (say, 60 seconds) with Memory suspend mode, and each tenant's sandbox disappears from the billing meter almost immediately - but resumes in sub-second time the moment they return.

Network Egress Policy

For scenarios involving untrusted code - AI agents executing LLM-generated scripts, multi-tenant SaaS with user-submitted workloads - controlling outbound network access is critical. Sandboxes provide a per-sandbox Network Egress Policy:

Default action: Allow or Deny all outbound traffic
Host rules: Domain-pattern rules (e.g., *.github.com → Allow) to permit specific destinations
Custom CIDR rules: Network-level rules for IP ranges (e.g., 10.0.0.0/8 → Deny)
Skip egress proxy: Option to bypass the egress proxy entirely when custom VNet routing handles policy enforcement

This means you can run a sandbox in a deny-by-default posture and allowlist only the specific endpoints it needs (your API server, a package registry, etc.) - without setting up NSGs or firewall appliances.

Managed Volumes: Persistent and Shared Storage

Sandboxes support two types of mountable volumes, both managed by Microsoft:

Volume Type	Backed By	Best For
Managed Azure Blob	Azure Blob Storage	Shared data across sandboxes, file uploads/downloads, persistent artifacts
Managed Data Disk	Azure Disk Storage	High-performance storage for databases, build caches, large working sets - only available to one sandbox at a time

Blob volumes come with a built-in file explorer in the portal - you can browse, upload, download, create folders, and drag-and-drop files directly. Data Disk volumes provide dedicated block storage with configurable sizes.

Secrets and Identity

Secrets

Sandbox Groups support key-value secrets scoped to the group. Secrets can be created, edited, and referenced by sandboxes within the group. These secrets can be used in egress policies to modify requests with transform or header-injection rules, without exposing the secrets to code running inside the sandbox.

Managed Identity

Sandbox Groups support both system-assigned and user-assigned managed identities, with full RBAC role assignment management. This means your sandboxes can authenticate to Azure services (Key Vault, Storage, Cosmos DB, etc.) without managing credentials - the same identity model you use everywhere else in Azure.

MCP Connectors and Triggers

ACA Sandboxes now supports managed connectors through the Model Context Protocol (MCP), giving sandboxes access to external APIs - including Microsoft 365, Salesforce, ServiceNow, GitHub, and 1,400+ other systems - without managing credentials directly. Attach a Connector Gateway to your sandbox group, and every sandbox in the group can call external APIs through a standardized MCP interface at runtime. Pair connectors with triggers to build event-driven automation: route an Outlook email to a sandbox that triages it with an AI agent, or react to a SharePoint file upload by extracting and processing the document all without writing glue code. Triggers can fire a shell command inside a sandbox or invoke an HTTP endpoint the sandbox exposes, so your automation shapes fit naturally around your workload.

The integration is built on the new Connector Namespace service (az connector-namespace), the same runtime behind Logic Apps and Power Platform connectors, now available as a programmable layer for sandboxes. See the end-to-end samples for runnable azd up-deployable examples covering email triage and document automation scenarios.

The Portal Experience

Azure Container Apps Sandboxes are only available in the new Azure Container Apps portal that provides a rich, IDE-like experience for working with sandboxes.

Creating a Sandbox

The portal offers multiple creation paths:

Standard Sandbox - full configuration control over source, resources, lifecycle, networking, and volumes
GitHub Copilot Sandbox - preset, Copilot CLI ready to go, GitHub credentials can be wired through the Access Token before the sandbox is created
Claude Sandbox - Claude CLI pre-installed, ready for agentic coding inside the sandbox

Using Coding Agents (Copilot CLI / Claude Code)

If you live inside Copilot CLI or Claude Code, you don't need to learn a new CLI. Install the azure-sandbox skill once and your agent picks up the right skills:

# GitHub Copilot CLI # Add as a plugin marketplace /plugin marketplace add microsoft/azure-container-apps # Install all skills /plugin install sandboxes@Azure-Container-Apps # Claude Code claude plugin add microsoft/azure-container-apps

The skill runs prerequisite checks silently (az --version, az account show, node --version, aca --version), prompts only if something's missing, and maps natural-language asks to the right aca commands. Bundled runbooks cover Copilot CLI BYOK (bring your own Azure OpenAI key), the deploy-a-web-app walkthrough, and shell setup.

Sandbox Detail Page

Once your sandbox is running, the detail page gives you immediate access to the sandbox terminal and additional details, such as -

Network Audit - real-time egress traffic log showing allowed and denied requests
Monitor - live CPU, memory, disk, and network utilization charts
Connectors - attached connections with an "Add" action
Volumes - mounted volumes with an "Add" action
Log Stream - streaming container logs
Processes - running process list inside the sandbox
Files - file explorer to browse the sandbox filesystem

The toolbar actions let you manage the state of the sandbox - Resume or Stop. In the Ellipsis menu (⁝) you can find additional settings to manage network Egress Policy and ingress (Add port), take a Snapshot of the sandbox, Commit (save disk state as a new disk image), set Lifecycle Policy or permanently Delete the sandbox. Finally, you can see additional Details in a side panel.

Getting Started with the CLI and Python SDK

All sandbox and sandbox-group operations go through the  aca  CLI. There are no az containerapp sandbox commands, - az is only used for az login, az account show, and resource-group management.

Install (CLI)

# Mac, Linux curl -fsSL https://aka.ms/aca-cli-install | sh # Windows irm https://aka.ms/aca-cli-install-ps | iex

Run aca --help to get started.

Install (Python SDK)

pip install azure-containerapps-sandbox

For more details, quick start and examples on ACA CLI and Python SDK, please go to https://sandboxes.azure.com

Evolution from Dynamic Sessions

If you've used Azure Container Apps Dynamic Sessions, Sandboxes are the next evolution of that capability. Everything Sessions can do, Sandboxes can do - and significantly more:

Capability	Dynamic Sessions	Sandboxes
Sub-second startup	✓	✓
Strong isolation	✓	✓
Custom container images	✓	✓
Custom VNet integration	✓ (Partial)	✓
Suspend/resume with Memory and Disk snapshots	-	✓
Lifecycle policies (auto-suspend, auto-delete)	-	✓
Network egress policy (per-sandbox)	-	✓
Persistent managed volumes (Blob, Data Disk)	-	✓
Managed identity (system + user-assigned)	-	✓
Secrets management	-	✓
Configurable resource tiers	-	✓
Direct access to sandbox in Portal experience	-	✓

We will continue to support Dynamic Sessions, but all new investment goes into Sandboxes. If you're building new workloads on isolated ephemeral compute, start with Sandboxes.

How It All Fits Together

ACA Sandboxes is a platform primitive. It's the foundation on which multiple Microsoft products are already built - including ACA Express, Cloud sandboxes in GitHub Copilot, and Foundry Hosted Agents. When you build on Sandboxes, you're building on the same infrastructure that powers Microsoft's own portfolio.

This is the evolution of what we shared with Project Legion in 2024. Legion described the internal infrastructure; Sandboxes exposes it as a customer-facing primitive that you can use directly.

What's Next

• Deeper Azure integrations - first-class connectivity with Azure networking, identity, storage, and AI services

• Enhanced SDK and CLI - richer programmatic experiences for managing sandboxes at scale

• More Microsoft services built on Sandboxes - this is just the beginning

Get Started Today

• Portal: https://sandboxes.azure.com/

• Documentation: Azure Container Apps Sandboxes

• Pricing: Azure Container Apps Pricing (per-second vCPU/memory billing, scale-to-zero, snapshots at Blob Storage rates)

We'd love to hear your feedback. You can ask questions, or file issues on the Azure Container Apps GitHub (prefix with [Sandbox] for Sandboxes-specific issues).

What's new in Azure Kubernetes Service at Microsoft Build 2026

coryskimming — Tue, 02 Jun 2026 19:30:00 GMT

A year ago, teams were still asking whether Kubernetes belonged anywhere near their AI workloads. That question has mostly been answered as the community comes together to . The real challenge now is operational: how to run training and inference at scale when cost, latency, and reliability are constantly in tension.

The AKS announcements at Microsoft Build focus on that tension directly. They expand what you can control across the stack: how individual clusters are operated, how close workloads run to the hardware, how you scale across a fleet, and how AI workloads are trained and served on top.

Start with the cluster: reduce undifferentiated work

A lot of Kubernetes effort still goes into maintaining the cluster itself rather than running applications. Two updates reduce that overhead and make cluster behavior more predictable.

Managed system node pools in AKS Automatic are now generally available. These nodes run the core components that keep the cluster healthy. Previously, you had to plan capacity, handle patching, and scale them manually. Now Azure handles that lifecycle. In practice, this means system components no longer compete with your workloads for resources, which is especially important for GPU-backed nodes. That separation gives you more consistent performance and fewer surprises when workloads scale.

Azure Container Linux, also generally available, standardizes the host OS layer. It is a minimal, container-optimized Linux distribution maintained by Microsoft. The smaller package footprint reduces patching overhead and limits drift across clusters. For teams operating multiple environments, this creates a consistent baseline that is easier to maintain and secure over time, which becomes more important as fleets grow.

Tune for performance: remove infrastructure bottlenecks

Some workloads benefit from abstraction, while others pay for it (especially when you are pushing hardware limits).

AKS on bare metal, now in public preview, is designed for those cases. It lets you run AKS on dedicated machines without a hypervisor, giving you direct access to NVLink, RDMA, and high-performance networking. You still use the same AKS control plane and APIs, but without the additional layer between your workloads and the hardware.

This matters for large training jobs, latency-sensitive inference, and high-throughput data pipelines, where small inefficiencies translate directly into higher cost or longer runtimes. Removing that overhead improves both performance and utilization as you scale.

Scale across the fleet: operate environments as one system

Most teams are not managing a single cluster – they are managing many, often across regions, clouds, and on-prem environments, and those differences tend to show up as operational inconsistency.

Azure Kubernetes Fleet Manager for Arc-enabled clusters is now generally available and extends fleet-level control beyond Azure. You can apply updates, enforce policies, and place workloads across clusters from a single control plane, which reduces the need to manage each environment independently.

For AI workloads, this shows up in a few practical ways. You can roll out changes progressively with health checks between stages, place workloads based on GPU availability and SKU, and apply RBAC consistently across environments. That consistency makes it easier to reason about reliability and capacity as systems scale.

The AI layer: training and inference as first-class primitives

With the cluster and fleet in place, the next challenge is coordinating distributed AI workloads efficiently.

Anyscale on Azure, now in public preview, brings managed Ray to AKS. Kubernetes continues to handle scheduling and cluster lifecycle, while Ray coordinates distributed execution within a workload. That includes managing CPUs and GPUs together, handling heterogeneous and fractional GPU allocation, and orchestrating jobs that scale dynamically based on demand.

The service runs inside your Azure subscription, integrates with Entra ID, and is billed through your existing agreement. It gives you more control over how compute is allocated within a job, which directly impacts both cost efficiency and time to completion.

Model serving: from YAML to production endpoints

Model serving has been one of the more complex parts of running AI on Kubernetes. Open source tooling is starting to simplify that path without replacing the underlying platform.

AI Runway, introduced earlier this year at KubeCon Europe, provides a Kubernetes-native way to deploy and operate models. Instead of starting with configuration, you start by selecting a model, validating that it fits your available GPU memory, reviewing cost estimates, and deploying it. That action creates a ModelDeployment custom resource, which drives the rest of the workflow.

KAITO, the Kubernetes AI Toolchain Operator, handles much of the underlying orchestration. It estimates resource requirements, provisions nodes through tools like Karpenter, and launches optimized runtimes such as vLLM. From there, standard Kubernetes components take over. KEDA manages autoscaling based on workload metrics, Gateway API handles routing, and rollout strategies follow familiar Kubernetes patterns.

AI Runway sits as a platform layer, with KAITO as one of several providers alongside options like NVIDIA Dynamo and KubeRay. It supports multiple serving engines, including vLLM, SGLang, TensorRT-LLM, and llama.cpp. These tools build on Kubernetes primitives rather than hiding them, so you can move faster without giving up visibility or control.

What this looks like in production

These capabilities show up as consistent patterns across teams, even when the use cases differ.

Wayve is building an end-to-end deep learning AI Driver that can be fine-tuned to drive almost any car, in any city, primarily from cameras. It trains and validates that model on Azure, using AKS, Ray and now Anyscale on Azure to connect thousands of GPUs into a flexible supercomputer. The approach generalizes: Wayve took a new Nissan vehicle in Tokyo, a city it had never driven, and had it driving autonomously in four months. Wayve-equipped vehicles now operate in the UK, the United States, Germany, and Japan.

Royal Bank of Canada built a self-service AI platform on AKS where development teams provision GPU resources and deploy models through a CI/CD workflow they run themselves. KAITO handles production model serving, with model images hosted in the bank's private container registry. The compliance perimeter wraps the entire path: private endpoints, Entra ID, Key Vault, and a private ACR keep models and data inside the bank's Azure boundary. Developers get self-service speed; the business gets the security and audit trail it requires.

SimCorp unified its SimCorp One investment management platform on Azure and standardized on AKS to run workloads consistently across regions, without configuration drift and without turning Kubernetes into a product it has to operate. With that in place, it embedded governed, auditable AI directly into investment workflows.

The practitioner's takeaway

The common thread across these updates is not that they remove the cost-latency-reliability tradeoffs, but that they make them easier to manage explicitly.

At the cluster layer, you trade control for simplicity where it makes sense, such as offloading system node management. At the infrastructure layer, you can choose between flexibility and raw performance, including when to run directly on hardware. At the workload layer, you decide how tightly to control scheduling, scaling, and serving behavior based on the needs of your models.

The practical approach is to start with the constraint that matters most for your workload. If cost is the issue, focus on utilization and right-sizing. If latency is the constraint, look at placement and hardware access. If reliability is the concern, prioritize rollout controls and fleet consistency. Azure Kubernetes Service expands your options in each of these areas so you can make those tradeoffs deliberately rather than working around them.

For the deeper version of this, join The honest practitioner's take on agentic AI on Kubernetes (BRK222) at Microsoft Build 2026, live or online.

What's new in Azure Container Apps at Build'26

vyomnagrani — Tue, 02 Jun 2026 19:30:00 GMT

Azure Container Apps (ACA) is a fully managed serverless container platform that enables developers to build and deploy microservices and modern applications without requiring container expertise or needing infrastructure management. ACA provides built-in autoscaling (including scale to zero), per-second billing, advanced networking, built-in observability, and simplified developer experiences across multiple programming languages and frameworks.

The world of application development is shifting rapidly. Agentic AI is fundamentally changing the requirements of cloud platforms - more code is being written by AI, more apps are being deployed by agents, and more deployment stacks are being assembled autonomously. Platforms are aligning to two concurrent demands: hosting intelligent agents as first-class workloads, and giving those same agents access to empty, secure compute pools as tools they can invoke on demand. At the same time, the proliferation of AI-generated code means that platforms must offer strong isolation for untrusted workloads, instant provisioning for rapid iteration, and production-grade defaults that make the right thing the easy thing - for both humans and agents.

Azure Container Apps is purpose-built for this new reality. Whether you're a developer shipping a web app in minutes or an agent spinning up ephemeral sandboxes for code execution, ACA provides the serverless foundation that meets both audiences where they are. Customers across industries are betting on ACA as the compute foundation for their AI and cloud-native workloads:

Replit runs its agent-driven software creation platform on Azure, enabling enterprises like Hexaware to securely build and deploy AI-generated applications at scale with seamless procurement through Azure Marketplace.
LayerX built its Ai Workforce document processing platform on Azure Container Apps, Azure OpenAI, Azure AI Search, and Cosmos DB - helping clients like Mitsui & Co. save 570 hours annually by automating manual document tasks.
SJR built GX Manager with Microsoft Foundry to automate website personalization at scale - delivering production-grade, data-grounded content in seconds instead of hours of manual curation.
August AI powers an AI health companion serving over 3.5 million customers on Azure infrastructure, scoring 100% on the U.S. Medical Licensing Examination and delivering potentially life-saving medical support.
Photon Education created Classwise on Azure OpenAI and Foundry with Defender for Cloud security, enabling teachers to prepare lessons faster and engage students more effectively in inclusive learning environments.
Microsoft Foundry Agent Service is built directly on Azure Container Apps, serving over 20,000 customers with a dedicated agent runtime that handles fast startup, tool execution, long-running operations, and enterprise-grade isolation at scale.

Following the features announced at Ignite'25 and our continued momentum through early 2026, we're excited to share what's new at Build'26. This release deepens our commitment to the agentic era with new primitives for secure ephemeral compute, the fastest path from container to production, a reimagined portal experience, and continued investment in security, observability, and developer productivity.

Azure Container Apps Sandboxes (Public Preview)

Teams building agentic applications, multi-tenant platforms, development environments, and CI/CD systems have often had to stitch together custom infrastructure to run untrusted code safely, preserve state across sessions, and handle bursty demand without paying for idle capacity. Azure Container Apps Sandboxes addresses that challenge with a new first-class resource type that provides fast, secure, ephemeral compute environments with built-in suspend and resume capabilities.

Each sandbox runs in its own hardware-isolated microVM boundary, supports standard OCI container images, and starts in sub-second time. Sandboxes can preserve memory, disk state, and preloaded libraries in a snapshot, so workloads resume quickly from the same point without incurring a cold-start reload penalty.

Why Sandboxes are perfect for agents

Agents can safely run AI-generated code in isolated environments with instant startup. Agents also accumulate context, intermediate results, and working state during long-running tasks. With sandbox snapshots, agents get persistent, isolated workspaces that survive across task boundaries - they can suspend and resume as needed, preserving full execution context including memory and disk.

Key capabilities

Sub-second startup - provision and execute immediately
Hardware-isolated microVMs - strong security boundary for untrusted code
Snapshot and resume - full state preservation (memory + disk) across sessions
OCI container image support - bring any container
Scale to zero, scale to thousands - consumption pricing with per-second billing

This is the underlying infrastructure on which products like Cloud Sandbox in GitHub Copilot, Foundry Hosted Agents, and Azure Container Apps Express are built. ACA Sandboxes joins the Container Apps family alongside Apps, Jobs, Functions, and Dynamic Sessions as a foundational building block for the next generation of cloud and AI application workloads. Learn more about Azure Container Apps Sandboxes at https://aka.ms/aca/sandboxes

Azure Container Apps Express (Public Preview)

We recently launched Azure Container Apps Express in public preview - the simplest and fastest way to launch and scale powerful applications on Azure, from zero to hyperscale, without infrastructure decisions. It represents the first Azure compute platform purpose-built for agent and developer use alike.

Express is based on years of experience running Azure Container Apps at scale. We've learned that most developers working on web apps, APIs, and agents want to deploy quickly, have automatic scaling, and avoid dealing with complex infrastructure. Express provides these capabilities - it sets up your environment in seconds, handles any amount of traffic, and removes complicated settings. This helps teams move from writing code to having a production-ready app in minutes, not hours.

What makes Express different

Instant provisioning - your app is running in seconds, not minutes
Sub-second cold starts - fast enough for interactive UIs and on-demand agent endpoints
Scale to and from zero - automatic, no configuration required
Per-second billing - pay only for what you use, no environment provisioning fee
Production-ready defaults - autoscaling, managed identity, secrets management, custom domains, container registry integration, revision management, and built-in observability

Purpose-built for custom agents

Agents need to spin up application endpoints on demand - fast, reliably, and without pre-provisioning infrastructure. Express is purpose-built for this pattern: it provisions in seconds, scales from zero instantly when an agent triggers a workload, and scales back down when the task is complete. Whether an agent is deploying a tool-use endpoint, standing up a temporary API for a multi-step workflow, or launching a web UI for human-in-the-loop review, Express gives it a production-grade, internet-reachable application with zero operational overhead.

It's the fastest path from "an agent decided to deploy something" to "it's live and serving traffic."

Learn more about Azure Container Apps Express at https://aka.ms/aca/express/launch-blog

New Azure Container Apps Portal

You open the Azure portal and want to deploy a Container App. Ten minutes later you're three blades deep, toggling settings you don't understand, wondering which workload profile is best before you even have an app.

We built a different portal. One where deploying a container app takes less time than reading this paragraph. One where creating an Azure Container App is a single click. And one where experimental features ship weekly, not quarterly.

Smart defaults, advanced when you need

Developers care about outcomes - where their app is running and how to reach it - not starting with a configuration form. The new portal offers three creation modes to keep setup simple:

Simple "one-click create" - auto-generates a unique name and provisions your app. Provide the container image and egress settings. That's it - no environment type selection, networking decisions, or container registry configuration.
Advanced create - unlocks everything: custom VNets with subnet selection, managed identity for registry auth, lifecycle policies, egress controls, environment variables, custom scale rules, and more. It's a toggle at the top of the same form, not a separate workflow.
Express App (Preview) - the new kind of ACA application that provisions and starts almost instantly.

Observe quickly, act faster

The app overview page surfaces critical information at a glance - including a unified Log Stream that brings app and system logs together in one place. Getting to the root cause now takes fewer clicks, and next steps are always one click away.

Faster releases, direct feedback loop

Azure Container Apps Express (Preview) and Azure Container Apps Sandboxes (Preview) are currently available only in this new portal. We ship weekly - often more. Upcoming Portal Features in settings give you an easy way to opt in to early access features and share feedback directly.

Security: Defender for Cloud Serverless Containers Posture and Confidential Compute

Security remains a top priority as enterprises run more sensitive and regulated workloads on Azure Container Apps. At Build'26, we're announcing two key security milestones.

Public Preview: Defender for Cloud Serverless Containers Posture on Azure Container Apps

Customers can now bring Azure Container Apps environments into Microsoft Defender for Cloud's Serverless Containers Posture experience, helping security teams extend posture management across more of their container estate from a single workflow. This makes it easier to gain visibility into Container Apps resources and assess risks across areas such as identity, networking, and container or image configuration.

With this capability, teams can more consistently evaluate risk across container environments and use attack path analysis to identify potential exposure faster. The result is a more unified security posture, less manual effort, and stronger confidence when securing Container Apps deployments. Serverless Containers Posture is available as part of the Defender CSPM plan. Learn more at the Defender for Cloud documentation.

General Availability: Confidential Compute for Azure Container Apps

Confidential Compute in Azure Container Apps is now generally available, providing hardware-backed Trusted Execution Environments (TEEs) through workload profiles. This extends protection to data in use - in addition to data at rest and in transit - enabling teams to run higher-trust workloads with stronger isolation for sensitive data.

With confidential computing now GA, Azure Container Apps becomes more viable for regulated, financial, healthcare, and other high-trust scenarios where organizations need hardware-enforced isolation that protects in-memory data, including from the underlying infrastructure.

There is no extra charge for confidential compute workload profiles. Learn more at the Azure Confidential Computing documentation.

Observability: HTTP Traffic Logs and OpenTelemetry Destinations

Knowing what's happening inside your application is essential to running production workloads with confidence. At Build'26, we're announcing two enhancements that give teams deeper visibility and more flexibility in where they send telemetry.

Monitor HTTP traffic in Azure Container Apps

Azure Container Apps now adds a dedicated Azure Monitor diagnostic setting category - ContainerAppHTTPLogs - that exposes detailed HTTP access logs for incoming traffic. This capability is designed for high-volume request data, enabling teams to troubleshoot ingress and request-flow issues with much greater precision.

With HTTP traffic logs, you can now investigate:

Failed requests and error codes
Latency patterns and outliers
Retries and WebSocket disconnects
Routing behavior and backend connectivity

The result is faster issue resolution, less operational friction, and stronger confidence in running high-traffic, business-critical applications. Standard Azure Monitor log volume charges apply. Learn more at Azure Monitor pricing.

Additional OpenTelemetry Destinations: New Relic, Dynatrace, Elastic

Azure Container Apps enhances its managed OpenTelemetry (OTel) capabilities by expanding support for third-party observability platforms. This update introduces additional endpoint options for commonly used monitoring tools - New Relic, Dynatrace, and Elastic - extending the existing managed OpenTelemetry experience.

Teams can now use a more consistent OpenTelemetry-based pipeline across Azure Monitor, Datadog, New Relic, Dynatrace, Elastic, and any OTLP-compatible endpoint, with less configuration overhead and more flexibility to route logs, metrics, and traces where they need them - without deploying or managing their own collectors.

No extra charge applies. Learn more at the OpenTelemetry agents documentation.

Additional Enhancements and Ecosystem Updates

Beyond the headline announcements, Azure Container Apps continues to evolve with a steady cadence of improvements across the platform.

Override Scale Rules in Azure Functions on Azure Container Apps

Azure Functions on Container Apps has traditionally used platform-managed scaling, where triggers are automatically translated into KEDA scale rules. With the new allowScalingRuleOverride property, customers can now choose to override platform-managed scaling and define their own custom KEDA scaling rules.

This enhancement is especially useful for scenarios where automatically generated KEDA rules lead to unintended scaling behavior, where workloads require custom thresholds or concurrency tuning, or where teams need standardized scaling policies across services. It works with any of the 60+ KEDA scalers - Service Bus, Kafka, PostgreSQL, HTTP concurrency, Cron, and more.

Heroku Migration to Azure Container Apps

With Heroku entering maintenance mode, Azure Container Apps is a natural landing zone for Heroku workloads. New guidance and tooling makes the migration path straightforward - from understanding why ACA is the right next step to a practical migration guide for hands-on implementation.

Dapr v1.16 Platform Upgrade

Azure Container Apps completed a staged platform upgrade to Dapr v1.16.4, bringing modernized actor scheduling, improved scalability for reminders, and updated TLS/security internals. The upgrade is fully platform-managed, with minimal customer action required for most workloads.

Running AI Models on ACA Serverless GPUs

The community continues to push the boundaries of what's possible with serverless GPUs on ACA. Recent highlights include running Gemma 4 with Ollama for fully private, self-hosted inference, and deploying ComfyUI for text-to-image and text-to-video workloads - all with scale-to-zero and per-second billing.

Hosting Remote MCP Servers on ACA

Azure Container Apps is emerging as the preferred platform for hosting Model Context Protocol (MCP) servers. With serverless scaling, idle billing, HTTP/1.1 and HTTP/2 support, and managed identity integration, ACA provides a production-ready environment for exposing tools and APIs to AI agents. Multiple tutorials and guides are now available for deploying MCP servers on ACA, including integration with Azure API Management.

App Modernization with GitHub Copilot

GitHub Copilot App Modernization can dramatically reduce the time required to modernize legacy applications and deploy them to ACA. A recent walkthrough demonstrated upgrading a classic ASP.NET MVC app on .NET Framework to .NET 10 and deploying it to Azure Container Apps in hours - with managed identity and Key Vault integration enabled by default.

Azure Skills Repository for Container Apps

The new Azure Skills repository includes comprehensive skills specifically for Azure Container Apps - covering troubleshooting, best practices, architecture patterns, security, deployment, and integration. These skills are designed to be used by AI agents and developer tools like GitHub Copilot CLI, providing rich context for building, deploying, and operating ACA workloads. It's another example of how the ACA ecosystem is evolving to be agent-native.

Docker Compose for Agents

Docker Compose for Agents on Container Apps (public preview) brings the familiar Compose workflow to agentic applications. Declare models, agents, and MCP tools in a single compose.yaml file and deploy unchanged from laptop to cloud - supporting LangGraph, Vercel AI SDK, Spring AI, CrewAI, and other frameworks. Learn more at the Compose for Agents documentation.

What's Next

Azure Container Apps is redefining how developers and agents build, deploy, and operate intelligent applications. With Sandboxes for secure ephemeral compute, Express for instant provisioning, a reimagined portal for streamlined management, and continued investment in security and observability - ACA provides the ideal foundation for the agentic era.

The features announced at Build'26 deepen our commitment to making Azure Container Apps the platform where both humans and AI agents can ship production workloads with confidence, speed, and minimal operational overhead.

Also, if you're at Build, come see us at the following sessions:

Breakout 221: Idea to production-ready agent in seconds on AI-native runtime
Demo 312: Multi-agents in action with 3 AI agents, 3 frameworks, tools & models
Lab 580: Build and deploy reasoning agents with NVIDIA Nemotron and Foundry
Lightning Talk 453: Building an End‑to‑End Enterprise AI Platform on Azure

Or come visit us at the Azure Application Services booth #44. Visit our GitHub page for feedback, feature requests, or questions. Check out our roadmap to see what we're working on next. We look forward to hearing from you!

Azure Functions at Build 2026 Update

nzthiago — Tue, 02 Jun 2026 19:47:19 GMT

Azure Functions took another big leap at Build 2026. It is now the best programming model for event-driven apps and agents, on the best infrastructure to write secure code that scales. The headline features: serverless agents, connectors to M365, Teams, and more, Go, MCP, and Durable Tasks.

Microsoft Copilot scales AI workflows to hundreds of millions with Durable Task Scheduler

Before we start with all the announcements, we want to highlight a new case study. As Microsoft Copilot scaled to support complex, long-running AI workflows, engineering teams needed a more reliable and consistent orchestration model. By standardizing on Durable Task Scheduler in Azure Functions, Copilot unified state management, retries, and recovery across services, helping run hundreds of millions of executions weekly while improving resilience and delivery speed.

Read the customer story: https://aka.ms/microsoft-copilot-dts

Serverless agents runtime (Preview)

→ Full post

Azure Functions now has a first-class programming model for AI agents. Define an agent in a .agent.md file with markdown instructions plus metadata that declares the trigger and tools, and deploy it exactly like any other Function. No framework to wire up, no hosting infrastructure to manage.

Any Azure Functions trigger can run an agent: HTTP, Timer, Service Bus, Event Hubs, Cosmos DB, or the new connection-backed triggers (Teams message, Outlook mail, calendar events, SharePoint item). Agents get access to MCP tool servers, sandboxed code and browser execution via Azure Container Apps dynamic sessions, and the full 1,400+ connector catalog. Built-in surfaces like chat UI, HTTP chat API, and MCP server endpoint are opt-in with no extra code.

The operational model is exactly what you already know: Flex Consumption for scale-to-zero and per-second billing, managed identity for auth, Application Insights for traces, azd for deployment.

Here's a timer-triggered agent that summarizes the day's tech news and emails it:

That's the whole function!

Managed connectors (Preview)

→ Full post

Azure Functions now includes the same 1,400+ managed connectors behind Logic Apps and Power Platform as first-class triggers in your Functions code, plus typed SDKs for invoking connector actions from your function body. Built jointly with the Connectors team on the new Connector Namespace service, so connectors feel native to Functions and the library that already powers thousands of Logic Apps workflows is now available to Functions developers.

React to SaaS events with first-class triggers like Office 365 new-email, Teams message-posted, SharePoint item-created, Dataverse row-changed, Salesforce record-updated, calendar events, and more using the [ConnectorTrigger] attribute. Call connector actions from your code via strongly-typed clients like OutlookClient, TeamsClient, Office365UsersClient, DataverseClient, and SalesforceClient.

public class ProcessEmail(TeamsClient teams) { [Function("OnNewEmail")] public async Task Run([ConnectorTrigger] Office365OnNewEmailTriggerPayload payload) { foreach (var email in payload.Body?.Value ?? []) { await teams.PostMessageToConversationAsync("Flow bot", "Channel", new PostMessageRequest { Recipient = new() { GroupId = _teamId, ChannelId = _channelId }, MessageBody = $"New email from {email.From}: {email.Subject}" }); } } }

MCP updates

→ Full MCP extension post

The Azure Functions MCP extension now covers all the MCP primitives like tool, resource, and prompt triggers are supported in .NET, Java, Python, TypeScript, and JavaScript. The extension also supports MCP Apps for interactive UI, where your tools can return rendered widgets instead of plain text.

And for .NET developers, a new fluent builder API makes it easier to compose MCP servers by chaining tool and resource definitions in a declarative style:

builder.ConfigureMcpTool("sayhello") .WithProperty("name", McpToolPropertyType.String, "Name of the user", required: true) .WithMetadata("ui", new { resourceUri = "ui://index.html" });

Finally, Built-in MCP authentication now offers a one-click configuration experience in the Azure portal, and a new AI tab in your function app lets you enable MCP auth without manual app registration or wiring.

New Azure Functions CLI (Preview)

V5 is here! A ground-up, next-gen build of the Azure Functions CLI. Now in public preview this release gives local Functions development a refresh.

Configuration profiles let you define your deployment targets up front, so func init can scaffold a project with full‑fidelity host settings in a single command. That means no more surprises when you deploy, earlier access to new platform capabilities, and improved reliability across environments.

New func setup preps your machine for .NET, Node, Python, or Go in one command. The func quickstart command scaffolds complete, ready-to-run apps from a curated catalog. And a new interactive func run dashboard gives you a live TTY UI with a function browser, log navigation, and keyboard shortcuts.

Existing func workflows for create, run, publish, and deploy carry forward unchanged, so you can try v5 alongside your current projects. Give it a spin and let us know what you think. Full command reference: Azure Functions local runtime and tools reference (v5)

Azure Functions VS Code Template Gallery (Preview)

The latest version of the Azure Functions extension for VS Code introduces a new Template Gallery, giving you single-click access to complete, ready-to-deploy templates. The gallery is hand-curated and maintained by the Functions team to keep every template aligned with the latest releases and best practices, including Azure Developer CLI (AZD) enablement and recommended settings. It already covers the majority of supported languages and triggers, and will continue to expand with the newest Azure Functions features. The same templates are available across both VS Code and the new Functions CLI (func quickstart).

Go language support (Preview)

→ Full post

Azure Functions now supports Go as a first-class language, available on Flex Consumption. The programming model is code-first and idiomatic: HTTP handlers are plain http.HandlerFunc, non-HTTP triggers take a context.Context and a typed payload, and the project layout is a standard Go module. Go build, go test, and go mod tidy just work.

Triggers in preview: HTTP, Timer, Service Bus, Event Hubs, Event Grid, Cosmos DB, and Blob Storage. No function.json, no interop shims, no generated metadata to keep in sync.

On-demand Sandboxes for Durable Task Scheduler (Private Preview)

→ Full post

Move individual orchestration steps to managed, isolated compute while your orchestrator stays exactly where it is. Declare which activities should run as serverless, point at a container image, and DTS handles provisioning, scaling, and teardown. No infrastructure to manage, no idle costs, no orchestrator changes.

Each execution runs in a clean, microVM-backed sandbox with per-activity or per-invocation isolation, ideal for native toolchains (ffmpeg, LibreOffice, Pandoc), CPU-heavy preprocessing (OCR, image work), cross-runtime steps (a Python inference activity called from a .NET orchestrator), sandboxed execution of customer plugins or LLM-generated code, and bursty workloads that can't justify always-on infrastructure.

Azure Functions Skills for coding agents (Preview)

→ Full post

Bring Azure Functions expertise to your coding agent. Azure Functions Skills equips GitHub Copilot CLI, Claude Code, and Codex with Functions-specific knowledge like trigger and binding patterns, language anti-patterns, runtime versions, and deployment best practices, so your agent gives accurate guidance instead of generic advice. One command installs guided workflows to create, deploy, diagnose, and review Functions apps. The standout is the doctor command: it uses LLM-powered semantic analysis to catch configuration mistakes and code issues like missing error handling, blocking I/O, hardcoded secrets, durable-orchestrator non-determinism, and supply-chain risks before you deploy, available as both a local CLI command and a GitHub Actions pre-deploy gate.

Try it now! npx @azure/functions-skills install

Built-in Grafana dashboards (Generally available)

Every function app now has a single pane of glass for operations with zero setup. A new Grafana dashboards entry in the function app's portal TOC opens a prebuilt dashboard purpose-built for Functions: execution count, success/failure rates, p50/p95/p99 duration, resource utilization, scale activity, and recent errors linked to Application Insights logs all in one view, scoped to your app. It's powered by Azure Monitor managed Grafana, so there's nothing to provision, wire up, or pay extra for. Duplicate and customize it to make it your own, save it to your subscription, and share it with your team.

Start using built-in Grafana Dashboards today!

TLS/SSL certificate support Flex Consumption (Preview)

Azure Functions Flex Consumption now supports TLS/SSL certificates through a new site-scoped certificate model in public preview. Each function app can hold up to 3 private (.pfx) and 3 public (.cer) certificates uploaded directly, imported from Azure Key Vault, or issued as free App Service Managed Certificates to enable custom domains, client-certificate authentication, and mutual TLS scenarios on Flex Consumption.

See Configure site-scoped certificates, infrastructure as code instructions, and the cross-plan certificate comparison for details.

Rolling Updates for Flex Consumption (Generally Available)

Rolling updates are now generally available in the Flex Consumption plan, delivering zero-downtime deployments with a simple configuration change.

Instead of forcefully restarting all instances during code or configuration updates, the platform gracefully replaces live instances by draining batches every few seconds while dynamically scaling out the latest version to meet demand. This approach ensures uninterrupted execution and resilient throughput across HTTP, non-HTTP, and Durable workloads - even during intensive scale-out scenarios.

Learn more at Site update strategies in Flex Consumption.

OS-level dependencies with containers on Flex Consumption (coming soon)

Bring your own OS-level dependencies to Flex Consumption without giving up serverless. Package your Functions worker and app code as a container image with a standard Dockerfile (Chromium for Playwright, native toolchains, custom system libraries, whatever your app needs) and run it on the Flex Consumption plan. You get the things that make Flex valuable: dynamic, event-driven scaling across all triggers and the pay-per-execution billing model. This is expected in the next couple of months.

How to engage

Everything announced this week is being actively shaped by real workloads. We want to hear from you.

X (Twitter): http://x.com/azurefunctions
Microsoft Q&A: file issues and track progress at https://learn.microsoft.com/en-us/answers/questions/ask/

Closing the AI-readiness gap with agentic modernization

Mike_Hulme — Tue, 02 Jun 2026 19:49:29 GMT

Legacy debt is widening the AI-readiness gap

Legacy systems and mounting tech debt aren't just slowing your AI agenda — they're quietly stealing its potential. Aging architectures, and complex, decades-old applications, databases, and infrastructure weren't designed for high performance, complex, dynamically scaling agentic workloads. The longer legacy lasts, the wider the gap between AI ambition and AI-readiness.

This year at Microsoft Build 2026, we're taking our biggest step yet toward closing it.

In a recent Forrester study, 94% of IT leaders ranked modernization as a top priority for their AI strategy, yet only 43% of their portfolios have been modernized on average, and only 32% are AI-ready.¹ Ambition for AI adoption is at a high, yet most are held back by the underlying legacy code, technical debt, and modernization backlog. Forrester’s data underscores it: on average, 35% of modernization projects stall due to legacy constraints, 65% cite security and compliance as the top challenge, 58% are held back by the complexity of monolithic applications, and 59% struggle with finding skilled talent to execute.¹

The result: AI initiatives that stall before they ever reach production. Modernization is a key step to move towards AI production; and it’s typically easier said than done. The growing problem is how to execute at the pace and scale that AI now demands.

That’s why IT operators, architects, application owners, and developers are turning to agents to eliminate legacy toil, connect workstreams across teams, and scale their modernization efforts while customizing how they modernize.

The first agentic end-to-end modernization solution that unifies IT and developer workflows

Azure Copilot migration agent and GitHub Copilot modernization agent create the first agentic, end-to-end modernization solution that unifies IT and developer workflows— helping organizations close the AI-readiness gap by connecting discovery, assessment, planning, code transformation, governance, deployment, and observability into one continuous system. Built into the tools IT teams and developers already use, the solution combines estate-scale planning with GitHub-native execution, application-aware migration, broad workload coverage across apps, infrastructure, and data, and enterprise-grade privacy, security, and flexibility— so modernization becomes a governed, scalable, portfolio-level capability across teams, rather than a series of one-off projects.

Building the estate-wide modernization plan

Azure Copilot migration agent (public preview) brings AI to every step of estate modernization planning - from discovery and assessment to dependency mapping, ROI analysis, and wave planning - reducing months of manual analysis to minutes.

For organizations with a clear picture of their estate, the migration agent accelerates the path from inventory to wave plan. For organizations that don’t, the migration agent helps them build that picture from scratch: what is running, what depends on what, what to move, what to modernize, what to retire, and in what order.

By creating business-goal oriented estate plans, generating ROI analysis in minutes, and aligning IT and development teams through connected workflows, it helps enterprises move mission critical applications, databases, and infrastructure onto Azure faster and more confidently, with a continuous, data-driven view of what to modernizing next.

Freeing teams from the legacy tax

GitHub Copilot modernization agent, now generally available, empowers application owners, architects, and developers to scale modernization across their entire application portfolio.

Operated from the CLI, the modernization agent acts as an orchestrator that simultaneously:

Assesses readiness across multiple applications at once
Plans application-specific modernization journeys and executes the identified migration tasks
Surfaces deep code and dependency-level insights and recommendations
Automates upgrades for Java and .NET applications
Recommends Azure services aligned to organizational standards

With its native design into GitHub Copilot, the modernization agent creates issues, pull requests, and shareable assessment reports for each application as it works. Architects and application owners retain visibility and governance from a single view, while developers receive clear, prioritized work they can execute from the agent or finish directly in their preferred editor. Behind the scenes, the modernization agent coordinates with GitHub Copilot's coding agent to complete tasks asynchronously across repositories, with a full monitoring and audit trail in GitHub's Agent HQ.

The result is a connected planning-to-execution flow that finally makes modernization at scale possible, without sacrificing oversight or control. In just a few months, the modernization agent has already accelerated modernization up to 4x faster across hundreds of thousands of legacy .NET and Java applications at hundreds of customers.

Enterprise level customization

Every application is built and operated as uniquely as the business it serves. The path to modernization must be equally unique: tailored to each application's architecture, dependencies, and intent. At Build, we're excited to announce the general availability of custom skills for the modernization agent.

Custom skills (GA) let developers teach the modernization agent how their organization works by encoding proprietary patterns, libraries, Azure best practices, and migration approaches once, then reusing them across every run. Each skill is authored as a skill.md file with build instructions, sample usage, reference APIs, and more, and is built on open-standard agent skills so teams aren't locked into a proprietary format.

With custom skills, developers can equip the modernization agent with:

Business-specific context, knowledge, intent, and migration approaches for application-aware guidance
Centralized skills library to reuse and repeat tasks across the portfolio
Full traceability for every skill used in generating the modernization plan

The result is portfolio-scale execution with application-level specificity, in the same agentic workflow. And because skills live in a shared library, teams can reuse and repeat for faster, more consistent modernization outcomes aligned with the application's goals.

Innovating while closing the AI-readiness gap

GitHub Copilot is already dramatically reducing technical debt in real world environments, helping to close the AI readiness gap and, more importantly, innovate faster with AI. Organizations that adopt agentic modernization can not only close their AI-readiness gap, they can also make modernization a continuous process, allowing them to more readily integrate AI into existing business applications and services

Ready to reimagine your applications? Join us at Microsoft Build this year, online or in person, to see our product teams reimagine applications live with GitHub Copilot modernization, share customer success, and empower you to modernize with confidence in days, not months.

Join online or in person for Build session BRK220 on Wednesday 9AM PST
Learn more about GitHub Copilot modernization: aka.ms/ghcp-modernization
Dive deeper at the virtual .NET Agentic Modernization Day on June 16^th: aka.ms/dotnetday/rsvp

¹ Forrester’s Q1 2026 Cloud and AI Application Modernization Survey [E-66670]

Azure SRE Agent at Microsoft Build 2026: Bringing agentic operations to the enterprise

dchelupati — Wed, 03 Jun 2026 15:46:10 GMT

Build 2026 Update

When we launched Azure SRE Agent, the promise was simple: reduce operational toil, improve up time, and evolve teams from manual incident response towards AI-powered operations. Since GA in March 2026, that promise has held up in production. Teams are using the agent to diagnose live issues, reason across telemetry and code, and automate response workflows - and the footprint has grown fast.

But there's a gap between an agent that works in a dev/test environment and one that works in your production environment. Real production environments sits behind a private network with strict egress rules for enterprise security. Their code lives in a GitHub Enterprise tenant that a consumer OAuth sign-in can't reach. Platform teams need to govern what the agent can learn and use, and connectors must scale across many tools and many teams.

At Microsoft Build 2026, we're announcing five releases that take a major step toward enterprise adoption at scale:

VNet integration Preview - Run SRE Agent inside your private Azure workloads, with full support for enterprise network boundaries and private connectivity.

Managed Connectors - A redesigned connector experience for governing, securing and scaling connections across observability, incident management, code, and collaboration tools plus an expanded SaaS connector catalog including Jira, GitLab, Slack, Power BI, and more.

Granular permissions model - Set allow, ask, and deny rules on individual tools. Admins can set guardrails that apply everywhere; Agent users can approve tools for the rest of their conversation without waiting on policy changes.

Native GitHub Enterprise support - Ground investigations in your enterprise repositories and workflows, so an incident can become an issue, an investigation, a pull request, and a repair plan — all under a governed service identity.

Private Plugins Marketplace - Give platform teams a governed way to publish approved skills, MCP tools, and operational workflows to every SRE Agent in the tenant.

Together with our Infrastructure-as-Code templates, these releases make Azure SRE Agent easy to integrate into secure environments with locked-down networks, regulated teams and complex codebases.

Read the series

VNet integration - https://aka.ms/sreagent/blog/VNET

Managed Connectors - https://aka.ms/sreagent/blog/connectorsv2

SRE Agent permissions model - https://aka.ms/sreagent/blog/HooksAndToolPermissions

Native GitHub Enterprise support - https://aka.ms/sreagent/blog/githubenterprise

Private Plugins Marketplace - https://aka.ms/sreagent/blog/privatepluginmarketplace

📺 Watch the on-demand session from #MSBuild 2026 - https://aka.ms/sreagent/build26

Get started

Create an SRE Agent — https://aka.ms/sreagent

Documentation — https://aka.ms/sreagent/newdocs

Recipes — https://aka.ms/sreagent/recipes

What's next

We're exploring Microsoft Entra Agent ID for first-class agent identity and Microsoft Agent 365 integration for centralized agent governance. What enterprise controls would unlock adoption in your production environments? Tell us in the comments below

Bring Your Own GitHub App: Connecting Azure SRE Agent to Enterprise Repositories

dchelupati — Tue, 02 Jun 2026 21:09:03 GMT

What if your SRE agent could access your enterprise GitHub repositories the same way your CI/CD pipelines do with a governed service identity, not a personal token?

Azure SRE Agent connects to your GitHub repositories to build rich context about your systems source code, infrastructure definitions, deployment configs, skills, runbooks, and operational history. This context is what turns generic troubleshooting into root cause analysis that points to the exact file, the exact commit, the exact config change. This is part of the Azure SRE Agent announcements at Build 2026.

For teams on github.com, connecting is a quick OAuth sign-in. Today, we are extending that same deep context to GitHub Enterprise Cloud and introducing Bring Your Own GitHub App as a first-class authentication model for enterprise teams that need governed, app-based access to their repositories.

Enterprise GitHub, enterprise identity

Large organizations run on GitHub Enterprise Cloud with EMU (Enterprise Managed Users). In these environments, every identity is governed centrally, tokens are scoped by policy, rotated on schedule, and tied to individual humans.

When an SRE agent needs to access your repositories, the identity it uses matters. With a GitHub App, the agent operates under a service identity registered and owned by your organization. Every repository operation — every clone, every issue query, every file read is attributed to the App’s installation, not to an individual engineer. Your security and compliance teams can trace agent activity to a governed service identity, and your audit logs reflect exactly what happened.

GitHub Apps are the same identity model enterprises already use for CI/CD pipelines, deployment automation, and internal tooling. BYO App extends it to your SRE agent.

How it works

When you bring your own GitHub App to Azure SRE Agent, the authentication flow uses short-lived tokens with explicit permissions: Your organization registers a GitHub App on your GHE instance (or github.com) with the specific repository permissions you choose, Contents Read, Metadata Read, and optionally Issues or Pull Requests.

The App’s private key lives in Azure Key Vault. The agent’s managed identity reads the PEM at runtime, mints a JWT, and exchanges it for an installation token that expires in about an hour. The private key never leaves Key Vault.

Permissions are declared, not inherited. The App has exactly the access you configured at registration. The agent cannot exceed those boundaries regardless of who set it up.

Token refresh is automatic. No human token to expire, no refresh chain to maintain. The agent mints new installation tokens as needed.

For organizations managing multiple GitHub instances, say, one for platform engineering and another for application teams, each instance gets its own GitHub App with its own Key Vault secret. You can assign a different user-assigned managed identity per App for security isolation. Disconnecting one host does not affect others.

What your agent does with GitHub access

Once connected, your agent uses GitHub for more than source code. Repositories hold the artifacts that define how your services run and how your agent reasons about them:

Source code and infrastructure definitions. The agent reads application code, Bicep templates, Terraform configurations, and Dockerfiles to understand what a service actually does — not what the docs say it does.

Skills and runbooks. Teams store agent skills, response plans, and operational runbooks as files in repositories. GitHub access lets the agent load and update these artifacts directly.

Configuration and deployment history. Helm charts, pipeline definitions, environment configs, and release manifests give the agent the context to correlate an incident with what changed and when.

Issues and pull requests. The agent can search issues for known problems, check recent PRs for regression candidates, and create issues or PRs when it identifies a fix.

Logs tell the agent what happened. Code tells it why. Your skills and runbooks tell it what to do about it.

The difference with BYO App is the identity under which all of this happens. These operations occur under your organization’s App identity with the permissions you declared, the audit trail you govern, and the key lifecycle you control.

GitHub Enterprise Cloud hosts

For GitHub Enterprise Cloud domains (*.ghe.com), the Code Access wizard automatically selects BYO App as the authentication method. This is by design, GHE Cloud hosts use App-based authentication exclusively.

The setup:

Create a GitHub App on your GHE instance. Set Contents: Read and Metadata: Read at minimum. Install it on the repositories your agent needs.
Store the private key in Azure Key Vault. Full PEM content as a secret.
Grant the agent’s managed identity Key Vault Secrets User on that vault.
Enter Client ID and Key Vault secret URI in Code Access. The agent validates credentials and loads your repositories.

BYO App on github.com works the same way, useful when your organization’s policy requires App-based authentication even for public GitHub.

Resources

Create new SRE Agent — https://aka.ms/sreagent

SRE Agent Documentation — https://aka.ms/sreagent/newdocs

SRE Agent recipes — https://aka.ms/sreagent/recipes

Build 2026 SRE Agent announcements - https://aka.ms/Build26/blog/SREAgent

Private Plugins with Azure SRE Agent

ebencarek — Tue, 02 Jun 2026 21:09:48 GMT

SRE's and platform teams are building operational skills specific to their infrastructure: investigation runbooks, compliance checks, cost analysis playbooks, deployment verification procedures. The next step is making that work reusable across every agent in the organization without exposing it publicly. Today, SRE Agent supports plugin marketplaces hosted in private GitHub repositories, including GitHub Enterprise. This is part of the Azure SRE Agent announcements at Build 2026.

You can now point SRE Agent at a private repo when adding a marketplace or installing a plugin. Authentication is handled per-marketplace, and supports OAuth, GitHub PATs, and GitHub Apps for GHE tenants.

From one agent to an organization’s plugin catalog

Most teams start with a single SRE Agent connected to their services. The agent learns their infrastructure, runs their runbooks, and handles their incidents. It works well.

Then adoption grows. A second team stands up their own agent. Then a third. Platform engineering wants every agent to run the same compliance checks. Security needs approval hooks enforced consistently. FinOps has cost governance skills that should be standard across the organization. Suddenly the question isn’t “how do I set up my agent,” it’s “how do we share operational knowledge across all of them.”

Without a distribution model, teams end up copying skill files between agents manually. A platform team writes a runbook, shares it over email or a wiki link, and each service team pastes it into their agent individually. When the runbook improves, some agents get updated, some don’t. There’s no version tracking, no central catalog, and no way to know which agent is running which version of which skill.

Private marketplace support solves this.

How Private Plugin marketplace meet enterprise needs

A platform team publishes once, every agent installs. Codify best practices as plugins in a private GitHub repo. Service teams add that repo as a marketplace in their agents and install what they need. Compliance checks, cost governance thresholds, incident playbooks, deployment verification procedures all distributed through versioned plugins.

Each team retains ownership. Security controls which plugins enforce approval hooks. FinOps locks cost thresholds into parameter values. Platform engineering governs infrastructure investigation patterns. The marketplace is the distribution layer for organizational standards.

Versions are pinned, updates are explicit. Each installation locks to the commit at install time. A merged PR upstream does not change any agent’s behavior. Teams promote new versions on their own schedule: validate in dev, promote to staging, then production. Different agents can run different versions simultaneously.

Reuse across environments and tools. The same plugin works across dev, staging, and production agents, and can be reused by local coding agents and other services that support plugins. One source of truth, not separate copies per environment.

Accessing Private Plugin marketplaces

Private repo support adds authentication to the SRE Agent's plugin workflow so your agent can clone and install from repos that require credentials. Authentication is configured once per marketplace. Every plugin within it inherits the credentials.

Auth method	When to use	Setup
OAuth	github.com repos your agent can already access	Uses your existing GitHub connection. One click.
Personal access token	Private repos in other orgs on github.com	Per-marketplace PAT. Scoped to just that marketplace.
GitHub App	GitHub Enterprise (*.ghe.com)	BYO App with private key in Azure Key Vault. Short-lived tokens minted at runtime.

Getting started

In SRE Agent, navigate to Builder > Plugins, then click Add Marketplace and enter the URL of the private marketplace you want to connect to.
Entering the marketplace reference
Then click Connect to GitHub to complete the OAuth sign-in.
OAuth completed
Click Add and you will see the plugins available from your connected marketplace.
Browsing plugins
Click on the plugin to install and in the detail view you can browse the skills packaged with the plugin. click Install to install this plugin.Plugin detail view
You can now see the skills imported from plugins from Capabilities > Skills > Custom SkillsPlugin skill available in skills list

The bottom line

Private repo support turns the Plugin Marketplace from a public skill catalog into your organization’s internal distribution platform for operational automation. Your team writes the plugins. Your agents install them. Your GitHub permissions control who has access.

Try it yourself: create a private repo with a marketplace.json and a few skills, add it as a marketplace in your agent, and install a plugin.

Resources

SRE Agent documentation — https://aka.ms/sreagent/newdocs
SRE Agent overview — https://aka.ms/sreagent/newdocsoverview
Plugin Marketplace capability page — https://aka.ms/sreagent/newdocs/capabilities/plugin-marketplace
Build 2026 SRE Agent announcements - https://aka.ms/Build26/blog/SREAgent

VNet integration for Azure SRE Agent (preview)

sanchitmehta — Tue, 02 Jun 2026 22:54:04 GMT

For many production systems, the logs, databases, private endpoints, repositories, and runbooks an SRE Agent needs to do its job are behind network boundaries your security team already governs. VNet integration for Azure SRE Agent, now in preview, puts the agent's outbound traffic under those same controls - your virtual network, your NSG rules, your private DNS - so it reaches only what your network allows.

The principle is one your security team already applies to every other workload: a component's network access shouldn't depend on the component behaving correctly. Identity governs what the agent can reach. Permissions and hooks shape what it does within reach. The network sits beneath both: it blocks any request to a destination you haven't allowed no matter what the agent decides.

Why egress control matters

Two reasons.

First, the agent reads sensitive things by design. Inspecting logs, code, configuration, and internal systems is the whole point during an incident, which means you have to decide where that data can go. Open egress gives that data a path out of your network - a risk you wouldn't accept for any other production-adjacent workload.
Second, it reasons over text it didn't write - logs, issue descriptions, tool output — which is how prompt injection gets in. Handling that is partly model safety, and Azure SRE Agent runs under Microsoft's Responsible AI standard with safety work from OpenAI and Anthropic. Network controls add another layer: an instruction that tries to reach a destination you haven't allowed can't run, because the network blocks it.

For example, an agent investigating an outage might query Log Analytics, read deployment configuration, and call an internal runbook - all private resources. With VNet integration, those calls follow the routes, DNS, and firewall rules your workloads already use. A request to an external endpoint you haven't allowed fails at the network boundary. It doesn't depend on the model recognizing the risk and refusing; the network stops it either way.

Choose an egress mode

Azure SRE Agent has three egress modes, and you don't have to start at the strongest.

Unrestricted - all outbound traffic allowed
Limited - deny all outbound, allow an explicit list of hosts. Gives you host-level control without setting up a full VNet
Azure VNet - outbound traffic goes through a delegated subnet in your network, with your NSG rules and private DNS applied. The recommended mode for production and regulated workloads.

How Azure VNet mode works

Outbound traffic takes one of two paths, and every call takes exactly one.

Your VNet. Everything not placed on the managed path goes through a delegated subnet in your own network, where your NSG rules, private DNS, and firewall all apply. The agent is just another workload on that subnet, so it can reach what the subnet can reach: databases behind private endpoints, internal services, monitoring stores, and key vaults -the parts of production that aren't reachable from the public internet. The resources that matter most during an incident are usually the private ones. If your network connects to on-premises over ExpressRoute or VPN, the agent can reach those systems too, as long as your existing routes and rules allow it.

The managed infra path. Some destinations go through Azure SRE Agent's managed infrastructure network instead - platform services the agent needs, plus optional categories you turn on: package registries, code repositories, and remote MCP servers. This path skips your VNet, so your NSG rules and Firewall Policies don't apply to it. Treat it as a deliberate exception, used only where you need it.

Why public services start on the managed path

Public services are hard to allow by IP address. GitHub, PyPI, npm, NuGet, apt, and the container registries run on large, changing IP ranges, and they don't map to a single Azure service tag. If your NSG filters by IP and port, keeping those lists up to date is constant work, and when a list falls behind, the agent can't pull a package or read a repository - and an investigation stalls on a networking problem that has nothing to do with the incident.

Each category has a toggle: package registries (PyPI, npm, NuGet, apt), code repositories (GitHub, GitHub Enterprise, Azure DevOps), remote MCP servers, and a list of additional hostnames. Starting with these on the managed path keeps the agent working reliably without maintaining an IP allowlist. For build-time dependencies, that's usually fine.

If you want this traffic inspected too, the next step is name-based (FQDN) egress filtering in your own network. Once your firewall can allow github.com and pypi.org by name, you can move these categories off the managed path and route them through your VNet instead

Configure it

Two decisions: the subnet, and what (if anything) uses the bypass.

Navigate to Settings > Workspace Configuration > Network
Choose Azure VNet as the egress mode.
Select a subnet that is /28 or larger and delegated to `Microsoft.App/environments`.
Decide which categories, if any, use the bypass.
Restrict who can change the egress mode and bypass toggles. These settings widen or narrow the agent's reach, so govern them like any production network control.
Test the outbound behavior before using the agent with production data.

A reasonable setup for most enterprises during preview: use Azure VNet mode, keep package registries and code repositories on the bypass if you need reliable access to them, and route everything else through your VNet. Stricter environments can turn those categories off and rely on their own name-based firewall rules.

What it doesn't cover yet

VNet integration is in preview, with two limitations to know. It covers outbound traffic only - reaching the agent privately from inside your network isn't part of this preview. And connector traffic still routes over the public internet; the governance and credential isolation in Connectors V2 still apply.

Use VNet integration for outbound control of the agent workspace, and combine it with identity, RBAC, tool permissions, hooks, and connector governance for a complete set of controls.

Where it fits

VNet integration doesn't replace identity, RBAC, tool permissions, or connector governance. It controls where traffic can go. The agent still needs the right identity and permissions to access a resource in the first place.

Identity is the foundation: your RBAC assignments decide what the agent can reach. Permissions and hooks shape what it does within reach: allow/ask/deny rules control what runs, and hooks let you inspect or change a tool call before it runs. VNet integration sits underneath, controlling where traffic can go no matter what the agent tries to do.

You want the agent to be capable. You also want a boundary that holds whether or not it is.

Get started

Create an SRE Agent - https://aka.ms/sreagent
Documentation - https://aka.ms/sreagent/newdocs
Recipes - https://aka.ms/sreagent/recipes
Build 2026 Announcement - https://aka.ms/Build26/blog/SREAgent

Managed Connectors for SRE Agent (preview)- Govern what your agent can do

Dalibor_Kovacevic — Tue, 02 Jun 2026 21:12:53 GMT

Giving an agent access to a tool is the easy part. The harder question is what it's allowed to do with that access. "Can the agent copy a file in OneDrive?" mostly answers itself. "Can it copy any file, to any destination, over one that's already there?" is the one that decides whether the integration has a governance layer.

Managed Connectors is built around that second question. It expands the catalog of tools the agent can reach - OneDrive, SharePoint, Google Drive, GitLab, Power BI, Microsoft Security Copilot, with more being added regularly - and pairs it with a governance model that keeps the policy for those tools outside the agent's control. This is part of the Azure SRE Agent announcements at Build 2026

What's new

Managed Connectors is the next generation of our connector experience. It significantly expands the catalog of third-party and first-party SaaS integrations available to SRE Agent and surfaces each one to the agent as a curated set of operations through the Model Context Protocol (MCP) - the same standard the agent already uses for every other tool source.

Governance: the agent gets capability, you keep control

The governance model is the headline of this release, so it's worth being concrete about it. When you add a connector, you walk through a short wizard - Set up connector, Configure tools, Review & Save - and the "Configure tools" step is where the policy is set.

Three things make it different from "just wire the API up to the LLM":

You choose what's exposed - it isn't automatic. A connector might offer 40+ operations; in the wizard you pick the ones the agent can use. The rest aren't shown to the model, so it can't call them.

Parameter policy lives outside the agent. For each selected operation you can mark parameters as user-defined (pinned to a value you specify) or agent-defined (the agent fills it in). On the Microsoft Planner “Create a task” tool, for example, you can choose the group ID from a list of your joined groups – this means that the agent provides the task details but can’t assign it to any arbitrary group, because that isn’t a parameter it sees when invoking the tool.

Per-tool approval is built in. Each operation has an Allow/Ask toggle integrated directly into the creation and edit wizards. "Ask" routes the call through the agent runtime human-in-the-loop approval flow before it executes. On that same Microsoft Planner connector, you might leave read-only tools like “List tasks” or "Get plan details” on Allow, but flip “Delete a task” to Ask so a human must confirm before anything is removed. This is enforced on the agent's runtime; it is not a prompt instruction the model can be talked out of following.

Credential Isolation

No long-lived secrets in the agent. No API keys, no client secrets, no certificates, no OAuth tokens. All service credentials are encrypted at rest and stored outside of the agent’s trust boundary
Automatic token refreshed. Once you consent, the internal connector resource keeps your tokens valid. You won't be asked to re-authenticate unless your service itself requires it.
You consent once, in your own browser, with your own service. SRE Agent never proxies your password or the sign-in flow.
Per-connection authorization. Each connection is bound to the specific SRE Agent instance you set up on and cannot be used by external threat actors.

How it fits together

All of this is stored and evaluated outside the agent loop. Each configured connector becomes an MCP server that the SRE Agent runtime registers as a tool source, the same standard wire format the agent uses for everything else, so adoption on the model side is trivial. Each layer does one job, and the trust boundary between "what the model decided" and "what was actually sent" is explicit and inspectable: the agent never sees the operations you didn't select, never sees the parameter slots you pinned, and cannot bypass approval on operations you marked Ask.

How to try it

Open the SRE Agent portal and go to Builder > Connectors.
Pick a connector from the catalog with the “Preview” label and go through the creation wizard steps.
At the “Set up connector” step, choose how the connector authenticates. Start with “OAuth” if you just want to sign-in and see it working against your own account.
At “Configure tools”, select the operations you want to expose, pin any parameters that shouldn't be agent-controlled, and mark sensitive operations as “Ask.”
Review & Save. The connector is registered with the runtime and immediately available to your agent. You can enable/disable specific tools or connectors in the “Capabilities” section.
Edit connector – after creating the new connector, at any point you can go back and authenticate it with a different account, add or remove operations, update tool parameters and configure approval policies

Resources

Create new SRE Agent — https://aka.ms/sreagent

SRE Agent Documentation — https://aka.ms/sreagent/newdocs

SRE Agent recipes — https://aka.ms/sreagent/recipes

Build 2026 SRE Agent announcements - https://aka.ms/Build26/blog/SREAgent

Shaping what Azure SRE Agent does: Tool Permissions and Hooks

Dalibor_Kovacevic — Tue, 02 Jun 2026 21:11:11 GMT

When an AI agent runs against production, the first question every security team asks is "What can it do, who decided it could, and what stops it from doing something it should not."

Azure SRE Agent reached general availability in March. Since then, teams inside Microsoft and customers running it against real production workloads have asked for the same thing: finer-grained controls over what the agent can do on its own and a clear answer to who governs each call that reaches a tool.

Today at Build 2026, we are releasing global tool access policies as one of a set of new governance controls. This post covers how they work. Tool access policies give security and platform teams a single place to define which tools the agent can invoke, under what conditions, and what requires human approval before it runs. Underneath those policies sits the identity the agent runs as the bedrock that every other control layer depends on. It is defense in depth applied to agent behavior: layers of control, each one holding on its own, so that governing the agent is something you can read, audit, and reason about as you scale it across production.

Identity is the bedrock: managed identity today, agent identity next

Start here, because nothing else matters if you skip it. The identity the SRE Agent runs as, and the Azure RBAC role assignments on that identity, are the most powerful boundary the agent works inside of. If your role assignments do not grant the agent access to a resource, none of the controls below come into play, because the agent cannot reach the resource to begin with. Network rules, tool permissions, hooks, and connector contracts all sit on top of an RBAC story that you write. The features in this post add layers above that floor. They do not replace it.

Today the SRE Agent operates as a managed identity, and your RBAC role assignments on that identity govern what it can do. This is the bedrock, and it is the same model your other Azure workloads already use. You assign roles, you scope them, and the agent inherits exactly what you granted and nothing more.

Everything that follows assumes the bedrock is in place. With identity settled, the next question is the obvious one: where is the agent allowed to send its traffic?

Permissions: govern what the agent does with a tool

Identity decides what the agent can reach. Permissions decide what the agent does with the access it has, down to the individual tool. Two levels cover the range: a point-and-click grid for the common cases, and hooks when a decision needs your own code.

The grid is the easy mode. Every tool the agent can use, built-in tools along with MCP servers, services, and custom tools, shows up in one searchable list with two switches. On/Off sets whether the tool is available at all; turn it off and the agent cannot use it. Allow/Ask sets what happens when it is on: Allow lets the agent run the tool automatically, Ask requires a human to approve every time, except in Autonomous mode. Select tools in bulk to flip a whole category at once, filter by category or permission, and use the Advanced permissions tab when you want rules that apply at global, per-agent, or per-thread scope instead of tool by tool. Defaults stay put until you touch them, and the engine is fail-closed: if a rule cannot be evaluated, the call is blocked rather than allowed. That covers most of what teams need.

Underneath those switches are three rules, allow, ask, and deny, and the Advanced tab is where you set them by scope. Global rules apply to every agent and thread, Agent rules to one custom agent, Thread rules to a single conversation. Deny is the hard one: it blocks the tool outright no matter the run mode, and a deny at a higher scope always wins, so an Allow at thread scope cannot reopen something denied globally. That split is deliberate. A platform team sets the Global guardrails that should never be crossed and the Asks that always need a human, and service teams add their own Allow rules at Agent scope for routine work, without being able to override the guardrails above them.

Platform team, Global scope:

deny: bash(az * delete *) - never delete, on any agent or thread
deny: bash(kubectl delete *)
ask: bash(az webapp restart *) - always confirm, even in Autonomous
allow: bash(az monitor *) - auto-approve monitoring queries

Service team, Agent scope:

allow: bash(kubectl get *) - routine read-only work
allow: bash(kubectl describe *)

Two details make this safe to lean on. Rules match the canonicalized tool invocation rather than the raw text, so enforcement holds no matter how the command was assembled. And fail-closed has a softer edge than a hard stop: a cached last-known-good policy covers transient failures, so a blip in the policy store blocks the call rather than silently widening access.

You can find these under Capabilities > Tools

Tools permissions.Advanced Tool permissions.

The layer worth spending time on is hooks. Allow and Ask answer "should this tool run." Hooks answer "should this specific call run, given exactly what it is about to do." A hook fires before the agent runs a tool and receives the actual call, parameters and all. Your code then decides the outcome and can reshape it: rewrite parameters before they are sent, inject extra context into the pipeline as a user message so the agent reconsiders before its next step, block the call outright, or redirect the agent toward a safer path. Because your code sees the real parameters, the decision can depend on anything you can express in code: which resource the call targets, whether a value falls outside an allowed range, the time of day, the result of an external policy lookup. This is where you write the rule the grid cannot.

Two kinds of hook, mixable on the same agent. Command hooks are a script you write; reach for these when code is enough. Prompt hooks put a separate LLM in the loop as a judge that evaluates the call in context; reach for these when the decision needs reasoning rather than a fixed rule. A real example from our own internal test agent: when the agent tries to list files through the shell with ls or dir, a hook blocks the call. The agent absorbs the signal, reconsiders, and reaches for the ListDir tool instead. The hook did not argue with a human. It shaped what happened next. As with the grid, configure nothing and the agent behaves exactly as it does today. Both are additive.

Authoring one is a short form. You name the hook, pick the event (Pre Tool Use, so it runs before the call), and set a tool matcher, either picked from the tool menu or written as a regex like (FetchWebpage|SearchMemory) with anchors and lookaheads when you need them, so the hook fires only on the calls you care about. You set a timeout and a fail mode (Block, so a hook that errors or hangs stops the call rather than waving it through), and you write the body in Bash or Python. A command hook reads the call as JSON on stdin, the event name, the tool name, its parameters, and the call id, and answers on stdout. Print nothing and exit zero to allow. Return a block decision with a reason to stop the call, and that reason is what the agent reads back. You can also substitute: run a cheaper or safer version yourself, block the real call, and hand your own output back as the result, so the agent never runs the expensive or risky original.

#!/bin/bash input=$(cat) tool=$(echo "$input" | jq -r '.tool_name') # Block one tool, with a reason the agent will read if [ "$tool" = "ExampleToolName" ]; then echo '{"decision":"block","reason":"Blocked ExampleToolName by hook policy."}' exit 0 fi # Otherwise allow: print nothing and exit 0 exit 0

You can find these under Builder > Hooks

Pre Tool Use Hook with inline sample starter code.

Each layer holds on its own

The layers stack. Identity is the floor: your RBAC assignments decide what the agent can reach at all. Permissions, the grid and hooks together, decide what it does with a tool. You author each layer, each one holds whether or not the layer above it behaves as expected, and all of it configures through the same ARM and Bicep surface your platform team already uses, reproducible the way the rest of your Azure estate is.

The upgrade path is additive and non-breaking. Existing agents keep working. Turn on each control when you are ready, in the order your governance requires.

There is more coming. We run Azure SRE Agent inside Microsoft on our own production workloads, so we feel the same gaps you do, and the next round is shaped by what we hear from teams running it in production today. Which control is doing the most for you, and which one are you still waiting on? Let us know and thank you!

Getting started

Create new SRE Agent — https://aka.ms/sreagent
SRE Agent Documentation — https://aka.ms/sreagent/newdocs
SRE Agent recipes — https://aka.ms/sreagent/recipes
Build 2026 Announcement - https://aka.ms/Build26/blog/SREAgent