Weekly Azure Roundup - Foundry agents, AI gateways, and FinOps

by TechHub

This week in Azure, the focus shifted from AI prototypes to production agentic apps, with GPT-5.6 now GA in Microsoft Foundry, stronger Agent Service hosting and observability, and practical IDE support in the Foundry Toolkit for VS Code. FinOps and governance got more actionable too, as MCP toolsets exposed cost and pricing data to agents, and APIM patterns tightened real-time enforcement for BYOK and token controls. On the platform side, Azure API Management introduced an AI Gateway tier in preview, Azure Monitor logs moved closer to Fabric and OneLake via zero-copy style previews, and Terraform AzureRM provider 5.0 GA landed with upgrade-impacting changes. The thread running through everything is clearer operational controls (identity, telemetry, policy, and budgets) that help teams ship AI and cloud workloads with fewer surprises.

This Week's Overview

Microsoft Foundry and Agentic App Development

Azure's AI surface area got more practical this week, with updates that span model availability, agent hosting, IDE tooling, and the plumbing needed to put governance and cost controls around AI features. The common thread is moving from “prompt demo” to production systems with identity, observability, deployment workflows, and clear cost boundaries.

GPT-5.6 GA in Microsoft Foundry (and Agent Service production features)

Microsoft Foundry added GPT-5.6 as generally available across the Sol, Terra, and Luna variants, alongside an APAC Data Zone option for teams with residency and latency requirements. The release is paired with production-focused Foundry Agent Service capabilities, including hosted agents, toolboxes, and built-in observability features such as tracing and evaluation.

For teams pushing to production, the announcement calls out cost-management levers that matter in day-to-day operations, including a model router, prompt caching, and PTU spillover strategies, which builds on last week's focus on treating gateways, telemetry, and budgets as operational controls rather than post-hoc reporting. The end result is a clearer set of knobs for controlling quality, latency, and spend when you are running agents continuously, not just during a pilot.

Foundry Toolkit for VS Code: flatter UI, inline tool workflows, and deeper debugging

The Foundry Toolkit for VS Code shipped a set of July 2026 updates (1.6.3 through 1.6.6) aimed at reducing friction in day-to-day agent development. The extension moves toward a flatter, tabbed resource UI, and it pulls Tool Catalog workflows inline so you can work with tools without constantly switching views.

Debugging also gets more specific: the Agent Inspector now supports event-level inspection, which is a better match for agent runs where you need to understand tool calls, intermediate steps, and failures at particular points in the trace, echoing last week's “policy to proof” theme where traces and metrics become audit-friendly evidence. There is also an Agent Optimization preview geared toward measured tuning and deployment, which signals a shift toward repeatable evaluation rather than ad hoc prompt tweaking.

Building and deploying hosted agents to Microsoft Teams (identity + observability included)

A production walkthrough showed how to take a multi-agent system from local development into Microsoft Foundry Agent Service, then distribute it into Microsoft Teams. It breaks down the choice between Prompt Agents and containerized hosted agents, and it treats identity (Entra ID) and operations (OpenTelemetry plus Application Insights) as first-class requirements rather than afterthoughts.

On the Teams side, the guidance covers using Adaptive Cards and a declarative agent package, which is useful if you want predictable distribution and admin control instead of bespoke bot deployments, and it aligns with last week's guardrails thread by making identity plus OTel-based observability the default posture for deployed agents. If you are already standardizing on DefaultAzureCredential and Azure-native monitoring, this path provides a concrete reference architecture for agent rollouts that meet enterprise expectations.

Adding durable memory to agents with SQL Server (and scaling to Azure SQL)

A tutorial focused on a common gap in “helpful assistant” apps: memory that persists across a session and remains queryable. It demonstrates implementing a SQL Server-backed history provider for Microsoft Agent Framework, starting locally with Docker and then moving the same design to Azure SQL Database or Azure SQL Hyperscale by swapping the connection string.

The practical takeaway is that “agent memory” does not need a specialized vector store to be useful, especially when the goal is conversational continuity (preferences, prior choices, recent context) rather than semantic retrieval across a corpus, and it complements last week's audit-and-evidence framing by keeping state in systems that are already easy to secure and audit. For teams already comfortable with relational data and operational tooling around SQL, this approach is straightforward to secure, scale, and audit.

MCP (Model Context Protocol) guidance and why it is becoming the “tool wiring” standard

Microsoft continues to lean into MCP (Model Context Protocol) as a standard way for agents to connect to tools and data over a consistent interface (JSON-RPC). The guidance emphasizes interoperability and operational concerns such as security and identity (including Entra ID), which are usually where early agent integrations fall apart.

If you are building internal tools, MCP's value is that it lets you standardize how agents invoke systems (ticketing, inventory, CI/CD, cost APIs) without rewriting bespoke integrations per model or per agent framework, and it picks up directly from last week's mention of MCP tools working cleanly behind centralized APIM policies. The post also includes small MCP server examples, which helps teams get from concept to a minimal working integration quickly.

GeoAI: MARS model for GIS vector extraction + “Physical-World Intelligence” positioning

On the geospatial side, Microsoft added the MARS (Map Autoregressive) model to the Foundry Model Catalog and showed how to use it with Planetary Computer Pro to turn satellite imagery into GIS-ready vector features (buildings, roads, railways, and waterbodies). The workflow is grounded in geospatial standards and formats, calling out STAC for cataloging assets and Cloud Optimized GeoTIFF (COG) as an imagery format that plays well with cloud processing.

A companion piece frames this as “Physical-World Intelligence”, combining earth observation and sensor data (weather, satellite, IoT signals) with enterprise context for operational decisions. For developers, the actionable shift is that data access (Planetary Computer Pro as a GeoAI data plane) and model access (Foundry domain models) are being packaged into a more production-oriented stack, with a GeoAI SDK positioned for at-scale workflows.

FinOps and Governance for AI and Azure Spend

Cost control got unusually concrete this week, with multiple posts treating AI and cloud costs as something you can query, enforce, and audit in near real time. The theme is shifting from after-the-fact reporting to proactive controls embedded in the developer workflow and in platform gateways.

ARM MCP Server adds Cost Management and Pricing toolsets (agent-queryable budgets and forecasts)

Azure Resource Manager's MCP server gained Cost Management and Pricing toolsets designed for AI agents. These toolsets let an agent query and forecast costs, manage budgets and alerts, retrieve pricing, and even analyze AKS spend, all through the same MCP-based tool interface.

The post includes setup steps for using the toolsets from GitHub Copilot Chat in VS Code and from GitHub Copilot CLI by configuring MCP headers, extending last week's MCP-plus-governance storyline by making FinOps data available through the same tool wiring agents already use. If you are experimenting with “FinOps copilots”, this is a meaningful building block because it makes cost and pricing data callable as a tool, rather than something a human has to look up in separate portals.

Governing GitHub Copilot spend with GitHub budgets plus Azure APIM BYOK enforcement

A FinOps guide laid out a two-layer pattern for controlling GitHub Copilot usage-based billing. Layer one uses GitHub's native budgets and usage metrics, and layer two applies BYOK (bring your own key) so IDE/CLI traffic routes through Azure API Management into an Azure AI Foundry (Azure OpenAI) deployment.

Because the enforcement point is APIM, teams can implement real-time token quotas and per-developer monitoring, using policies like llm-token-limit and emitting token metrics with llm-emit-token-metric into Application Insights, which directly continues last week's emphasis on APIM as the control point for entitlements, spend limits, and audit-ready telemetry. This is most relevant for orgs rolling Copilot out broadly, where you need predictable spend and auditability without relying purely on developer self-restraint.

Reservation exchange policy change: exchanges end Feb 1, 2027 for services covered by savings plans

Azure announced that starting Feb. 1, 2027, reservation exchanges will no longer be available for services covered by Azure savings plans. Eligible existing reservations will get a one-time final exchange option, but the long-term message is that you need to choose your commitment vehicle (reservation vs savings plan) with fewer “escape hatches” later.

If your organization relies on exchanges to adjust commitments as architectures change, this is a planning item for 2026 procurement cycles. It is also a reason to revisit which workloads are stable enough for reservations, versus which are better matched to savings plans where flexibility and coverage differ.

Measuring agent costs as “cost per accepted task” (and enforcing with gateways + evaluation)

A cost-modeling post argued that token spend alone is a weak KPI for agentic systems, and proposed measuring “cost per accepted task” instead. It describes a controller pattern that combines forecasting, runtime enforcement, and quality-triggered reversion when an agent's output quality drops below thresholds.

The architecture maps cleanly to Azure components: APIM GenAI gateway for runtime control, Azure AI Foundry evaluations for quality measurement, Application Insights and Azure Monitor for signals, and App Configuration for safe rollbacks, effectively turning last week's “policy to proof” loop into an explicit cost-and-quality feedback system. For teams running agents in production, this is a practical framing for connecting cost controls to business outcomes rather than raw usage.

Azure API Management and Edge Networking: AI Gateways, Edge Compute, and Perimeter Constraints

Azure's gateway and edge story advanced on two fronts this week: new AI governance surfaces in API Management, and deeper detail on where programmable compute and perimeter enforcement hit real-world limits. Taken together, these updates help teams design the “control plane” for AI and PaaS traffic with fewer surprises.

API Management AI Gateway tier enters public preview

Azure API Management introduced an AI Gateway tier in public preview, positioned for publishing and governing AI models and MCP servers. The preview centers on “policy cards” (JSON) as a control mechanism, plus OpenTelemetry token metrics so you can observe and attribute AI usage in the same telemetry pipeline you already use for APIs.

After last week's coverage of APIM-based AI gateway patterns (including emitting per-model token metrics without changing client code), this preview reads like the productization of that approach into a first-class tier with standard policy and observability primitives. The preview supports multiple model providers, including Microsoft Foundry and external hosts, which matters if you are mixing vendors or routing between internal and external model endpoints. It also integrates with Azure Policy and common observability backends, making it easier to treat AI endpoints like any other governed API surface rather than a special-case service.

Azure Front Door edge actions: programmable compute with micro-VM isolation and failover behavior

A deep dive explained how Azure Front Door edge actions add programmable execution into the request path without sacrificing hyperscale characteristics. The design leans on Hyperlight micro-VMs to provide strong tenant isolation, which is critical when you are executing user-defined logic at the edge.

Operationally, the piece emphasizes predictable resiliency patterns, including circuit-breaker-like behavior with fast-fail and fallback, and explicit “fail-open” considerations, extending last week's defense-in-depth guidance (Front Door + WAF in front of governed AI gateways) into what you can safely run at the edge. If you are planning to run authentication transforms, request filtering, or AI-adjacent routing logic at the edge, this is a useful look at the trade-offs and failure modes you should test with Game Days before rollout.

Network Security Perimeter scale limits updated (watch the 200 rule-elements-per-profile transition)

Azure Network Security Perimeter published updated hard limits, including higher caps for perimeters and associated PaaS resources. The notable tightening is a stricter limit of 200 rule elements per profile, with a transition period running through 10/31/26.

If you have been modeling large numbers of granular rules inside a single profile, this change may force you to redesign how you partition perimeters or how you structure rule sets. Teams should inventory current rule-element counts now, then plan remediation work before the transition window closes to avoid enforcement surprises in late 2026.

A migration guide tackled an awkward but common constraint: legacy apps that hard-code a private IP and cannot be changed easily. The proposed pattern uses Private Link Service Direct Connect with a Private Endpoint plus a site-to-site VPN, allowing a phased migration while preserving the IP expectation.

The post includes a lab-style deployment and a validation checklist, which is especially useful when you are dealing with overlapping address spaces or brittle network dependencies. If you are migrating regulated or long-lived systems where refactoring is not realistic on the migration timeline, this approach provides a concrete bridge pattern.

Observability and Data: Azure Monitor Logs Moving Into Fabric/OneLake

Microsoft continued to connect operational telemetry with analytics workflows, with multiple Fabric previews aimed at making logs queryable in OneLake without duplicating data. The practical story is that KQL-based operational signals are being pulled closer to Spark, Power BI, and cross-domain analytics so teams can correlate incidents with business outcomes faster.

Share Azure Monitor Logs to Fabric (preview) as Delta Parquet without duplicating data

A public preview enables sharing Azure Monitor Logs from Log Analytics workspaces into Microsoft Fabric OneLake as Delta Parquet, designed to avoid data duplication. This unlocks scenarios like Power BI reporting, Spark analytics and ML, and correlating telemetry with business datasets for near real-time response in Fabric.

This builds on last week's push to treat telemetry as “proof” by widening who can analyze the same operational evidence (without copy-heavy ETL), while keeping Log Analytics as the operational source of truth. The positioning suggests a workflow where Log Analytics remains the source for operational logging, while Fabric becomes the place where analysts and data engineers can run broader workloads without ETL pipelines copying the same log tables repeatedly. For developers, it is a signal to think about schema, retention, and access control early, since logs are no longer confined to the monitoring team.

OneLake mirroring expands: Azure Monitor tables and AWS Glue Iceberg metadata-based mirroring (preview)

Fabric also introduced preview support for mirroring Azure Monitor (Log Analytics) tables and AWS Glue Data Catalog-managed Apache Iceberg tables into OneLake using a metadata-based, zero-copy approach. The “zero-copy” emphasis matters when datasets are large and constantly changing, and when you want governance and discoverability without moving bytes around.

For teams spanning Azure and AWS, the Iceberg mirroring via AWS Glue Data Catalog is a practical interoperability story, especially if you are standardizing on OneLake as the consumption layer. The post includes setup steps for both sources, which should help teams validate whether mirroring fits their security and latency requirements.

Cross-domain intelligence with Azure Monitor data in Fabric (preview)

Another preview focused more on the “why”: using Azure Monitor data inside Fabric to connect operational telemetry to business impact through analytics workflows. This is the same idea as log sharing and mirroring, but framed around decision-making loops rather than data movement.

If your incident reviews routinely ask “what did this outage cost us” or “which customers were affected”, this direction points to building repeatable correlations between monitoring signals and business dimensions. It also raises governance questions, because operational logs often contain sensitive identifiers that need careful handling when they enter broader analytics environments.

Retention governance for Log Analytics at scale (policy-driven)

A governance post addressed the cost side of logs: keeping workspace defaults low, then setting per-table analytics retention, and using long-term retention only where required. This approach matches how log value varies by table (security events vs verbose traces), and it avoids paying premium retention across everything by default.

The post includes an open-source Azure Policy initiative using DeployIfNotExists with audit and remediation support, plus ARM and PowerShell deployment options. If you are operating many workspaces across subscriptions, the policy-based approach is the difference between “best effort” retention hygiene and enforceable standards.

Infrastructure as Code and Developer Tooling

Tooling updates this week focused on reducing drift between local workflows, CI/CD, and what actually lands in Azure. The biggest “watch item” is Terraform AzureRM provider 5.0 GA, which includes behavioral changes that will affect upgrade planning and pipeline reliability.

Terraform AzureRM provider 5.0 GA: new defaults, opt-in preflight validation, and deprecation removals

Terraform AzureRM provider 5.0 reached general availability, and it comes with changes that matter for both new projects and upgrades. The release highlights new defaults around Azure Resource Provider registration, an opt-in Azure preflight validation during terraform plan (via the Azure Preflight Validation API), and removal of deprecated resources and properties.

In practice, you should expect upgrade work where older resources or fields were already on borrowed time, and you should budget time to run plans in a safe environment before rolling provider 5.0 across all pipelines. If you enable preflight validation, it can catch provider/platform mismatches earlier, but you will want to evaluate how it affects plan times and CI noise for large estates.

Azure Developer CLI (azd) July 2026: extension install, uninstall, CI/CD behavior, and Foundry modeling

The July azd roundup covered versions 1.27.0 through 1.29.0 with quality-of-life improvements and a few deployment workflow changes. Highlights include improved extension install behavior, a new azd tool uninstall command, and support for Azure App Service container deployments.

For teams running azd in automation, the update calls out non-interactive CI/CD behavior, which is often where “works locally” scripts fail when prompts appear in pipelines. There is also Azure AI Foundry resource modeling in azure.yaml, which helps keep AI resource definitions closer to the app template rather than scattered across manual portal steps.

Azure SDK July 2026: Rust Storage SAS improvements and Python management GA

The July 2026 Azure SDK release included a new Rust crate for Azure Storage user-delegation SAS (shared access signatures), which is useful for building time-bound access flows without account keys. Several Python management libraries also reached GA for App Service, Resource Health, and Data Boundaries, which helps teams that automate governance and operational tasks through Python.

If you are maintaining internal tooling across languages, these updates are a reminder to check SDK maturity before committing to a language stack for management-plane automation. GA status for the Python management packages reduces risk for long-lived ops scripts and platform engineering tooling.

GitHub Copilot agent experiences arrive in Visual Studio (Preview), with .NET/Azure skills

Visual Studio's July update added a new Agent (Preview) inside Copilot Chat built on the GitHub Copilot SDK. The update also includes built-in .NET and Azure skills, selected-code review actions, organization-level custom instructions, and improved context features like branch attachment.

For Azure developers, the key point is that Copilot is being positioned less as autocomplete and more as an orchestrated assistant that can apply domain skills and consistent org guidance, which pairs with last week's APIM-based BYOK and telemetry patterns as the “other half” of governance (controls in the IDE plus controls at the gateway). If you manage developer environments, org-level instructions become another governance surface to align coding patterns, security expectations, and cloud usage conventions across teams.

Security, Compliance, and Policy

Security updates this week mixed platform capabilities (policy and auditing) with compliance-driven deadlines. The pattern is that “secure by default” continues to move left into policy, identity, and workload configuration, rather than being handled purely by downstream detection.

CIS Benchmark auditing for Linux on Azure is now GA (Azure Policy + Machine Configuration)

Built-in CIS Benchmark auditing for Linux workloads is now generally available using Azure Policy with Machine Configuration, powered by the kompli engine. The announcement lists supported Linux distributions and CIS benchmark versions, and it extends to Azure Arc-enabled servers, which matters for hybrid fleets.

From an operations standpoint, the GA release makes it easier to standardize compliance checks across subscriptions and environments and to query results at scale using Azure Resource Graph. If you have been relying on custom scripts or third-party scanners to check CIS alignment, policy-based auditing can reduce tooling sprawl, but you should still validate how findings map to your internal exception process.

Azure Policy exemptions gain “Compliance Substate” for better visibility into what exemptions are masking

Azure Policy exemptions now include a Compliance Substate property that shows whether exempt resources would be compliant or non-compliant if the exemption were removed. This closes a common governance gap where exemptions hide the true state of a resource, making it hard to prioritize remediation or decide whether an exemption is still justified.

The update includes instructions for enabling the column in the Azure portal and querying the field across subscriptions with Azure Resource Graph. For governance teams, this makes exemptions less of a blind spot and more of a controlled, reportable mechanism.

HIPAA on Azure Databricks: enabling Compliance Security Profile (CSP) with a Sept 1, 2026 deadline

Guidance for Azure Databricks explained how to enable the Compliance Security Profile (CSP) for HIPAA, including prerequisites like Azure VNet encryption and supported VM series. It also outlines tooling choices for enablement (including Terraform) and validation steps for rollout.

The post flags a September 1, 2026 deadline and notes CSP enablement is intended to be permanent, so this is not a toggle to experiment with casually. If you operate HIPAA-regulated workloads on Databricks, the practical next step is to inventory impacted workspaces and schedule enablement work with time for validation and any required infrastructure changes.

Microsoft Security July 2026: agentic SecOps concepts, prompt injection defenses, passkeys-by-default

Microsoft's monthly security update included Project Perception (an agentic SecOps concept) and new Microsoft Defender protections that specifically call out prompt injection and protection for cloud agents. On the identity side, Entra updates include a push toward passkeys-by-default, and Purview updates target DLP and insider risk investigation workflows.

For Azure operators, the key signal is that “agent security” is being treated as a first-class category alongside identity and endpoint protection, which connects back to last week's governance stack (Entra, Defender, Purview, APIM) as the security controls that make agent automation defensible in enterprise environments. If you are deploying internal agents that can take actions, you should track these Defender and Entra changes closely because they influence what “safe by default” looks like for automated operations.

Reliability and Resilience Patterns for Regional Architecture

A reliability guide mapped common ways teams distribute workloads across Azure regions, focusing on the risk drivers and recovery trade-offs rather than prescribing a one-size-fits-all architecture. The value is in naming patterns clearly, then tying them to RTO/RPO expectations and real Azure service constraints.

Zoran Jovanovic outlines five patterns (Single, Failover, Parallel, Segmented, Portable), and connects each to decisions like active-active vs active-passive and whether Availability Zones are sufficient or true multi-region is required. For developers, this helps convert vague resilience goals into explicit architecture choices, with an emphasis on what Azure services can and cannot support cleanly across regions.

Other Azure News

Several updates landed across compute, data, and hybrid management, mostly as “keep an eye on this” items rather than single feature launches. John Savill's weekly roundup touched a wide range of services, including AKS updates, networking changes like Azure Firewall HTTP header insertion and NAT64 on NAT Gateway, APIM AI Gateway coverage, Azure Monitor log mirroring into Fabric, PostgreSQL Flexible Server regional expansion, and security items such as Azure Enclave and Key Vault symmetric keys.

On hybrid and multicloud operations, the Azure Arc Server June Forum recap highlighted an Arc Server AI Agent for onboarding and troubleshooting, plus Azure Arc Multicloud Connector public previews for GCP and detected EKS clusters. It also included ESU timeline guidance for Windows Server 2016/2012 and SQL Server 2016, which is relevant if you are using Arc as part of your lifecycle management strategy.

Microsoft Fabric's July 2026 feature summary rolled up improvements across CI/CD and Git integration, OneLake governance actions, Spark Runtime 2.0 and release channels (including Apache Spark 4.1), diagnostics and performance features, and Real-Time Intelligence updates across Eventstream and Eventhouse. If you are building pipelines that blend operational logs, streaming, and analytics, these Fabric changes intersect directly with the Azure Monitor-to-OneLake previews called out earlier.

For application workloads, a community template collection showed how to “bring your own orchestrator” to Azure Container Apps Jobs, integrating 13 orchestrators (Airflow, Temporal, Argo, Durable Functions, Logic Apps, and others) where the orchestrator remains the control plane while ACA Jobs runs containerized tasks. And for beginners building RAG-based assistants, a guide walked through creating an IT support agent using Azure AI Foundry with Azure OpenAI Service plus Azure AI Search, then optionally wiring actions through Azure Functions, Logic Apps, or Power Automate.