Weekly Azure Roundup - Governable agents and safer execution

by TechHub

This week's Weekly Azure Roundup focuses on what it takes to run action-taking AI agents like real production services: clear ownership, cross-tenant identity, and audit-ready controls. Microsoft shared concrete multitenant governance patterns (central visibility with federated control) and deeper guidance on sandboxing agent execution using AKS or Azure Container Apps, plus managed MCP tools like Playwright Workspaces with strong evidence capture. On the platform side, Azure AI Foundry expanded routing, tool management, and agent features, while data teams got practical updates across Azure SQL vector indexing, Fabric MCP servers and modernization paths, and Databricks governance for coding agents. The rest of the stack rounded things out with new VM SKUs, private AI connectivity via ExpressRoute, clearer VM lifecycle rules, and a steady stream of security, FinOps, and developer tooling improvements.

This Week's Overview

Governing AI agents across tenants (and keeping humans accountable)

Building on last week's focus on making agent systems governable through concrete controls (MCP tool-call mediation, Entra-based authorization patterns, and Foundry observability), Microsoft is pushing harder on agent governance as agents spread across Azure AI Foundry, Copilot Studio, and custom runtimes. A new federated reference architecture shows how to manage agents across multiple Microsoft Entra tenants using Microsoft Agent 365 as a centralized inventory, paired with Microsoft Entra Agent ID for identity and attribution.

The practical pattern is “centralize visibility, federate control”: build agents in local tenants, but enforce policies and runtime guardrails through an Azure API Management AI gateway, with Microsoft Purview covering compliance and data governance. The same design also calls out Open Policy Agent (OPA) for policy decisions and OpenTelemetry for end-to-end tracing, so ops teams can correlate evaluation results, tool calls (including Model Context Protocol (MCP) tools), and runtime behavior.

In parallel, Mark Russinovich's reminder that “AI isn't accountable. You are.” fits the same operational reality: as agents start taking actions, you need explicit ownership, auditability, and escalation paths. Treat agent deployments like production services with clear approvers, logs, and rollback plans, not like experimentation sandboxes that can quietly become business-critical.

Securing and sandboxing action-taking agents

Following last week's run of “secure agent infrastructure” guidance (MCP hosting patterns, APIM fronting, and audited tool-call control loops), teams are converging on the same question: once an agent can execute tools, where do you draw the boundary between “tool interface” and “execution environment”? This week had several concrete Azure patterns that separate MCP tool exposure from isolated runtimes, while improving observability and approval workflows.

Execution boundaries with OpenSandbox and AKS (vs ACA Sandboxes/Dynamic Sessions)

An AKS-based reference implementation shows a clean split between MCP tool interfaces and the sandbox lifecycle manager (OpenSandbox), with runtime isolation provided by Kata Containers. The goal is to keep “agent can call tools” from becoming “agent can freely run code with ambient credentials,” using dedicated credential vaulting and hard isolation to reduce blast radius.

The post also contrasts this approach with Azure Container Apps Sandboxes and Azure Container Apps Dynamic Sessions, which target similar isolation goals with more managed infrastructure. If you are choosing between AKS and ACA for agent execution, the trade-off is mostly control vs operational overhead: AKS gives you deeper control (including Kata configuration), while ACA Sandboxes focus on an opinionated, managed model for microVM-style isolation.

Managed browser automation as an MCP tool (Playwright Workspaces)

Building on last week's MCP security thread (where discoverability, per-user auth, and audit-ready tool execution were the hard parts), Microsoft Playwright Workspaces (hosted “cloud browsers”) are being positioned as a managed tool that agents can call safely over MCP, with built-in diagnostics like logs, traces, screenshots, and video recordings. The example connects a GitHub Copilot app to a remote MCP server that fronts Playwright sessions, and emphasizes evidence capture plus human approval before final submission.

For developers building ticket triage, form-filling, or QA-style agents, this is a useful middle ground: you keep browser execution off your own infrastructure, but still get governance hooks and a consistent tool contract via MCP. The operational win is debuggability, since browser runs come with artifacts you can attach to incidents or evaluations.

Agent evaluation and observability options (Foundry vs Container Apps vs self-hosted)

Following last week's emphasis that agent observability has to cover correctness (traces plus evaluations, not just uptime), a hands-on comparison walked through three agent observability setups: self-hosted Langfuse on an Azure VM, a Microsoft Foundry hosted agent with Azure-native tracing/evaluation, and a standalone agent on Azure Container Apps instrumented with OpenTelemetry feeding Application Insights and Log Analytics. The underlying theme is that evaluation data (quality, tool correctness, safety) needs to live next to operational signals (latency, errors, cost) if you want to iterate safely.

If you're already standardizing on Azure Monitor, the OpenTelemetry-to-Application Insights path is the most composable for custom runtimes. If you prefer a more integrated agent platform, Foundry's hosted experience reduces plumbing but may constrain how you customize eval pipelines.

Azure AI Foundry updates: routing, toolboxes, and agent features

Building on last week's Foundry and agent-engineering storyline (harnesses, traces/evals, and real reference architectures), September's Microsoft AI updates continued to fill in the “agent platform” surface area in Azure AI Foundry. John Savill highlighted new model additions, changes to Model Router, and a growing set of agent capabilities (including A2A, routines, and voice agent functionality), alongside governance controls that are becoming first-class platform features.

Model Router is also getting more practical guidance for cost and performance tuning. A dedicated walkthrough showed the open-source Model Router Auto Evaluation toolkit, which compares routing behavior against a baseline model (for example GPT-5) and generates an HTML dashboard with quality, cost, latency, and distribution charts so teams can justify when routing is better than pinning to a single model.

On the “tools” side, Azure AI Foundry Toolbox is being framed as a way to centralize an MCP-governed toolset while splitting read-only access from approval-gated actions (refunds, orders, and other state changes). The point is less about adding tools and more about keeping tool growth from exploding token usage and governance complexity, using searchable tool catalogs and human-in-the-loop controls.

Developer agent workflows: Copilot canvases, hosted skills, plugins, and Visual Studio BYOM

Following last week's push toward more structured build-and-ship flows (guided Copilot steps in VS Code, Durable Functions-based hosted skills, and azd-centric deployment loops), GitHub Copilot's “agent as a runnable app” direction is starting to look like an actual workflow instead of a collection of demos. This week connected four parts: shared workspaces (Canvases), local dev/debug for skills (Hosted Skills canvas), distributable governance (plugins), and IDE-level agent features (Visual Studio updates).

Azure Canvases: shared workspaces for Azure tasks inside Copilot

Azure Canvases introduces a plugin-based workspace that pairs Copilot chat with interactive dashboards and guided flows for common Azure tasks. The examples include deploying Azure Functions, querying resources across subscriptions, and reviewing cost/governance signals, which hints at a pattern where operational context sits alongside the chat that is issuing actions.

If you are building internal platform workflows, the key idea is that a canvas can provide structured inputs and guardrails while Copilot handles the narrative and automation. That is a better fit for repeatable tasks than a pure chat thread where context drifts and approvals are ad hoc.

Hosted Skills Canvas in the Copilot app (Azure Functions + azd + MCP)

Building on last week's hosted-skills and Durable Functions dynamic workflow patterns, the Azure Functions Hosted Skills canvas (preview) adds a local, event-driven workflow for running and debugging hosted skills, with triggers, logs, and evidence-backed outputs. It also documents the path from local testing to deployment using Azure Developer CLI (azd), and how to expose a hosted skill as an MCP tool endpoint for agent use.

For teams building internal automations, this tight loop matters: you can iterate on the actual hosted skill code (not just prompts), validate tool outputs, and keep identity clean using managed identity rather than shipping secrets. It is also a clear “skills as deployable services” story, which should make CI/CD and change review more straightforward than treating skills as opaque configurations.

Copilot plugins as the unit of distribution and governance

Guidance on GitHub Copilot plugins focused on packaging versioned instructions, skills, and MCP tool connections so teams can standardize how Copilot behaves across projects. The recommendation is to publish plugins via an internal marketplace, define update rules and precedence, and treat plugin changes like any other shared dependency.

This is the missing piece for larger organizations: without a distribution mechanism, every team reimplements the same tool wiring and prompt policies, and you cannot reliably audit what an agent was configured to do at the time of an incident. Plugins give you a concrete artifact to version, review, and roll back.

Visual Studio September update: BYOM for agent mode and MCP-aware Git agents

Visual Studio's September update pushed agent workflows further into the IDE, including Bring Your Own Model (BYOM) for Copilot agent mode so organizations can choose which model powers the experience. It also added Copilot-assisted fixes for NuGet Audit warnings from the Error List, plus a Git agent for pull request exploration that supports MCP server connections.

The more interesting implication is that MCP is becoming a common integration layer across Copilot experiences (IDE agents, hosted skills, tool servers). If your tooling strategy depends on durable integrations, investing in MCP-based tool endpoints now is likely to pay off across multiple Copilot surfaces.

Azure infrastructure: new VM families, private AI connectivity, and clearer lifecycle rules

Azure's core infrastructure updates this week touched performance, capacity sourcing, and planning for retirement. The throughline is more options (new SKUs and hybrid capacity patterns), paired with more explicit guidance on what “supported” means over time.

Lasv5 and Laosv5 VMs reached general availability, using 5th Gen AMD EPYC (Turin) and targeting storage-optimized workloads with large local NVMe, higher IOPS, and up to 200 Gbps networking compared to the prior generation. These SKUs are most relevant for I/O-heavy databases, caching tiers, and analytics scratch workloads that benefit from fast ephemeral storage.

Separately, Microsoft described “AI Points of Presence (AI PoPs)” as an architecture for privately connecting third-party GPU capacity into Azure using ExpressRoute. The pitch is a consistent operating model for distributed AI infrastructure, with private connectivity as the baseline so you can extend capacity without turning your training/inference fleet into a patchwork of public endpoints and one-off ops processes.

Finally, Azure published a standardized Virtual Machine Lifecycle policy with four stages (Current, Extended, End of Life, Retired), clarifying what happens to availability, quotas, purchasing options, and support/SLA expectations at each stage. If you manage long-lived fleets, this is a signal to integrate lifecycle checks into regular governance (for example via Azure Advisor and Azure Service Health) rather than discovering retirements late.

Data and AI foundations: vector search in Azure SQL, plus Fabric and Databricks governance

Building on last week's “data and agent hygiene” theme (continuous evaluation, retention controls, and audit-ready telemetry), Microsoft's “data foundation for Copilot and agents” theme showed up across Azure SQL, Microsoft Fabric, and Azure Databricks. The common thread is building governed context layers (semantic, vector, lineage) that can safely feed agent experiences.

Azure SQL Database Hyperscale vector indexing (DiskANN) for RAG at scale

Azure SQL Database Hyperscale is leaning into retrieval-augmented generation (RAG) scenarios with DiskANN-based vector indexing, with performance claims up to 1B rows and sub-second search in the showcased examples. The engineering discussion covered practical behaviors like filtering, DML support, and how the index behaves beyond toy datasets, which is often where vector search features fall apart.

The team also stated that vector index support is generally available in Azure SQL PaaS and Microsoft Fabric SQL, which matters if you want consistent capabilities across operational databases and analytics surfaces. If you already store app data in SQL, this opens a path to keep embeddings and vector retrieval close to transactional data without introducing a separate vector database by default.

FabCon/SQLCon Barcelona: Fabric IQ, Database Hub/agents, and MCP servers

FabCon and SQLCon EU updates emphasized Fabric IQ as a governed semantic/context layer for Copilot and agent experiences, along with new observability, billing, and database management features. Announcements also highlighted the preview Database Hub experience and preview database agents that aim to provide AI-assisted operations, tying database management into the same “agentic” direction as the rest of the stack.

Fabric's September 2026 feature summary adds more concrete platform pieces: governance policies, CI/CD deployment plans, better Git integration, OneLake catalog/search improvements, and explicit MCP servers (including Fabric Core MCP Server and Fabric IQ MCP Server). For developers, the signal is that MCP is being used not only for app tools, but for data and governance surfaces too.

Fabric Data Factory and guided modernization from ADF/Synapse to Fabric

Fabric Data Factory updates expanded mirroring sources, multicloud copy/distribution, and transformation options across Power Query, Dataflow Gen2, notebooks, and dbt, with richer monitoring through a Monitoring Hub. A notable thread is MCP-based AI assistance across operations, which suggests Microsoft is making operational help (and potentially automation) part of the pipeline authoring and monitoring experience.

Microsoft also published a guided modernization path from Azure Data Factory (ADF) and Azure Synapse Analytics to Fabric, including a “view in Fabric” upgrade experience, assessment-first migration, and migration assistants for Spark and dedicated SQL pools. For teams with large estates, this framing matters because it encourages phased adoption (assessment, then targeted migrations) instead of a risky platform cutover.

Azure Databricks: Lakeflow and governing coding agents

Following last week's Databricks posts on continuous evaluation and retention as baseline production hygiene, on the Databricks side, Lakeflow is being positioned as a unified layer for ingestion (Lakeflow Connect), transformation (Spark Declarative Pipelines), and orchestration (Lakeflow Jobs), with Unity Catalog providing governance and lineage. The developer takeaway is that “pipeline glue” is moving into a more unified interface, but governance still lives in the catalog layer, not in individual jobs.

Databricks also shared a governance story for coding agents using the Unity Gateway CLI (ug), reusing Unity Catalog permissions plus rate limits (QPM/TPM) and account budgets. Smart Routing (beta) and usage tracking via system tables (for example system.ai_gateway.usage) plus OpenTelemetry export are part of the model, which aligns closely with the broader Azure shift toward auditable agent operations.

Hybrid and end-to-end Azure: SQL Server on Azure Local and Azure Virtual Desktop resiliency

This continues last week's hybrid thread (bringing agents to private workloads and treating “private connectivity plus control planes” as the real end-to-end requirement), and hybrid and desktop virtualization both got concrete GA milestones focused on resiliency and sovereignty. The updates make it easier to keep data and control planes in the right place without giving up Azure management.

SQL Server on Azure Local is now generally available, supporting connected and disconnected operations, and targeting regulated, sovereign, and edge environments. The announcement also highlighted Foundry Local on Azure Local (preview) to run AI inference close to SQL Server data while keeping processing on-premises, which is a clear pattern for “inference near data” without shipping sensitive datasets to the cloud.

Azure Virtual Desktop reached GA for regional host pools (starting in East US 2 and Central US), storing host pool metadata in-region to reduce cross-region dependencies and improve resiliency and data sovereignty. The practical constraint to note is that you cannot mix regional and geographical objects, so teams need to choose a deployment scope upfront and align it with compliance and availability requirements.

Other Azure News

Cost and spend governance got several pragmatic upgrades, from model pricing and expanded usage metrics to better-scoped optimization recommendations across org hierarchies. If you run multi-subscription estates, management group-scoped savings plan and reservation recommendations should reduce the “optimize one subscription at a time” drag, while the September FinOps roundup is a useful checklist for AI-related pricing and billing changes.

Security teams got a detailed reminder that identity weaknesses can become CI/CD compromises, with Storm-3068 using self-service password reset compromise to pivot into Azure DevOps and abuse trusted pipelines to harvest Kubernetes credentials. The same week also brought Azure Network Security Perimeter metrics to GA in public cloud, making it easier to alert on allowed/denied access patterns through Azure Monitor dashboards, workbooks, and metric alerts.

For application and platform engineers, there were useful building-block updates: the Azure Connectors SDK (preview) brings Logic Apps connectors into .NET apps (including .NET 10 isolated-worker Functions) with managed identity policies and trigger registration; Azure Developer CLI (azd) added azure.yaml project layering, per-phase concurrency limits, and versioned gRPC extension contracts; and the Azure SDK September release added Azure AI Search preview API support across languages plus stabilized auth and storage components.