Everything Azure Shipped This Week, Ranked

The week in one paragraph

Sixteen announcements, weighted heavily to Friday, and the shape is unusually clear. Four of the sixteen are Microsoft Foundry agent announcements, and not one of them is about making agents smarter — they are an egress firewall, an enable/disable switch in the Microsoft 365 Admin Center, a supported publishing path, and a native trigger. Four more are Azure Database for PostgreSQL. The rest spread across networking, SQL, OpenShift, payments hardware and SAP-class compute.

The agent cluster is the story, because it marks a transition that happens to every platform capability eventually: the controls arrive, and the thing stops being a feature and starts being an object the organisation has an opinion about.

Agents became something you govern

Read these four together rather than separately and they describe one deliberate move.

An egress firewall, inside the runtime. Network egress controls for hosted agents in Microsoft Foundry reaches public preview, letting customers govern the outbound connections a hosted agent can make. The mechanism is specific: ordered rules matched on destination host, including FQDN with wildcards such as *.contoso.com, with actions to allow, deny, transform outbound request headers, or rewrite the destination.

Two details make this more interesting than a feature note. The rules live in the agent's Responsible AI policy — so outbound network control is being modelled as an AI safety concern rather than a networking one, which is a genuine architectural choice about where the boundary belongs. And they are enforced inside the Foundry-managed agent sandbox before traffic leaves the runtime, so no separate network appliance is required for basic allow and deny. That is egress control that does not need a hub, a firewall or a route table — and therefore does not appear in any of the places a network team currently looks.

An off switch, in the Admin Center. Enable and disable controls for Microsoft Foundry agents in Agent 365 are generally available, giving administrators control over whether a Foundry agent is available for use across their organization — and crucially without requiring developer intervention. Microsoft's own framing is candid: it fills a core governance gap by bringing Foundry agents into the Admin Center alongside other agent types.

An off switch that does not require the person who built the thing is the difference between a capability and a governed capability. It is the same property that makes a Conditional Access policy useful, and post #31 noted that Agent 365 is where agent governance is licensed.

A supported way out, and a supported way to start. Publishing Microsoft Foundry agents to Microsoft 365 Copilot and Teams is GA, replacing a situation where developers had no native path to make their agents operational across Microsoft 365, requiring separate deployment pipelines, bot registrations, and app manifests. And Foundry Routines arrives in preview as a native trigger primitive for running published agents automatically, displacing the external glue such as Logic Apps, Azure Functions, webhooks, queues, custom storage, and separate identity and role assignments that scheduling an agent previously required.

Both of those are the same pattern as the egress control: work that was customer-owned infrastructure becomes platform surface. Which is convenient, and which also moves the audit trail. The glue you assembled was visible in your subscription; the primitive that replaces it is visible in Foundry.

Two dates that will break something if ignored

Both are the quiet kind: no feature, no migration project, just a date after which something stops.

Azure Virtual Desktop endpoints, early October. Beginning in early October 2026, Windows App will begin using three new wildcard fully qualified domain names (FQDNs) for client-side service traffic to Azure Virtual Desktop. The consequence is stated plainly: if your organization applies network controls to devices running Windows App, you must allow these endpoints before activation. If the endpoints are not reachable, users may experience sign-in and connection failures.

This is the highest-priority item of the week for anyone running AVD behind a proxy or an allowlist, and it is easy to miss because it is not a retirement and not a feature. It is a change to what the client talks to, and the failure mode is users who cannot sign in on a Monday.

SAP container images, 14 October. The containerized SAP data connector retired on September 14, 2026 and is unsupported and unmaintained — that date has already passed. The one that has not: container images will be removed on October 14, 2026, preventing new pulls, installation, redeployment, scaling, replacement, and disaster recovery.

Note what survives and what does not. Existing agents keep sending; what dies is your ability to redeploy. So the system works until the day you need to scale it, replace a node, or recover it — the same shape as the AKS OS Guard retirement in issue #5, where images were removed months after support ended. Worth internalising as a pattern: with container-based retirements, the date that matters is image removal, not end of support.

Networking: 3,000 virtual networks and a new protocol

High-scale mesh in Azure Virtual Network Manager is generally available. In available regions customers may connect up to 3,000 virtual networks in a single mesh connectivity configuration by default, with higher scale available by request. The pitch is the removal of toil: manage connectivity across large virtual network environments without creating and maintaining individual peerings.

Three thousand is a number worth registering against the shape of a landing zone. Post #30's model produces a virtual network per application landing zone, so a large estate reaches the hundreds without trying. A default ceiling three thousand means mesh connectivity is no longer the thing that constrains how many subscriptions you vend.

HTTP/3 over QUIC on Application Gateway enters public preview, so the gateway can now serve frontend client connections over QUIC. QUIC improves connection setup time, reduces latency, and provides better resiliency. Frontend only at this stage, which is the usual order — and the honest read is that the benefit is real for mobile and lossy networks and marginal for a well-connected office.

An undo button for a deleted SQL server

Buried in the mid-September Azure SQL roll-up, and more significant than its placement suggests: you can now configure soft delete for the Azure SQL logical server. When deleted, it goes into a soft deleted state and is self-restorable during the configured retention period.

The sentence that matters is the last one: accidental deletes can now be self-recovered within the retention period predictably and consistently, without having to call Microsoft support. Recovering a deleted logical server has historically been a support ticket, which means an outage measured in whatever the queue was that day.

This is the same category of improvement as deployment stacks' denySettings from post #28 and management locks from #22: not a new capability, but a change in what an accident costs. Those are usually worth more than the features that get the headline.

The rest, briefly

PostgreSQL had a week. Four announcements: PostgreSQL 18 support for elastic clusters; a logical_replication_slot_sync_status metric showing whether each slot is synchronized, catching up, or in an unknown state, which is exactly what you want when a Debezium pipeline is misbehaving; new and improved troubleshooting guides covering high CPU, memory, IOPS, temporary file usage, and autovacuum issues; and a PostgreSQL skills and MCP plugin in preview, giving AI coding assistants an MCP server that can inspect your live database context, run queries, apply changes, and support database operations.

That last one deserves a raised eyebrow in an identity-focused fortnight. "Run queries and apply changes" is a description of write access, and whatever identity the plugin uses is now a principal worth auditing.

Azure Red Hat OpenShift with hosted control planes is in preview, running the OpenShift control plane as a fully managed service, separate from the worker nodes that run customer applications — the same architectural split AKS made years ago, arriving for OpenShift.

Azure Payments HSM v2 is in preview, where customers retain exclusive administrative control of an isolated, single-tenant Payment HSM cluster while Microsoft manages the underlying infrastructure. And Mdsv4 and Msv4 memory-optimised VMs for SAP arrive in preview on 6th Generation Intel Xeon Scalable processors.

Security advisories

Twelve Azure advisories, eleven of them on Thursday 17 September, and the distribution is striking: ten of the twelve are elevation of privilege, and three sit in AI services.

• AI and ML — CVE-2026-85889 and CVE-2026-85917, both Azure AI Foundry elevation of privilege, plus CVE-2026-68791 Azure Machine Learning information disclosure. Three AI advisories in the same week Foundry shipped four governance features is a coincidence worth noticing rather than reading into.
• Hybrid — CVE-2026-70009 and CVE-2026-69399, both Azure Arc elevation of privilege. Arc reaches into machines you run, so these are worth reading in full rather than assuming the fix is Microsoft's alone.
• Integration and data — CVE-2026-83944 and CVE-2026-70200 Azure Logic Apps, CVE-2026-87701 Cosmos DB, CVE-2026-85878 Azure Database for PostgreSQL, and CVE-2026-69843 Microsoft Fabric.
• Platform — CVE-2026-62874 Azure Billing elevation of privilege, and CVE-2026-83946 Azure Portal spoofing — the only non-elevation entry, and the one most likely to matter to an end user rather than an operator.

A Logic Apps elevation pair is worth a second look given the week's other theme: post #35 established that anyone who can execute code on a resource holds every permission its identities have, and a Logic App is a resource whose entire purpose is executing code with an identity attached.

Beyond the announcements

The Entra blog carried the item most relevant to this series' current phase: replace VPN access with identity-driven security — the argument behind Entra Private Access, and the practical case for the Suite pricing discussed in post #31. Also there: self-service onboarding for Entra App Gallery applications in preview.

On governance, one preview that belongs in Phase 1's territory: Azure Policy custom policy versioning. Built-in policies have carried versions for a while; custom ones have not, which made changing a definition in place the only option and rollbacks a matter of remembering what the JSON used to say. Directly relevant to posts #14 to #17.

The Architecture blog was almost entirely Foundry this week — five posts, including Foundry observability: how to trace, evaluate, monitor and secure AI agents, which pairs naturally with the egress controls above. And the security blog published security fundamentals that materially reduce risk.

What I would act on

1. Check your AVD allowlists before early October. Three new wildcard FQDNs, and if the endpoints are not reachable, users may experience sign-in and connection failures. This is the one with a deadline and a user-visible failure, and it needs a network change rather than a decision.
2. Find any containerised SAP data connector and migrate it. Already retired; images go on 14 October, after which you cannot redeploy, scale or recover. It will keep working right up until the moment you need it not to be fragile.
3. Decide who owns agent egress policy. The rules sit in the agent's Responsible AI policy and are enforced in the Foundry sandbox — not in a firewall, not in a route table. If your network team owns egress, they currently cannot see this, and the answer needs to be deliberate rather than accidental.
4. Turn on Azure SQL logical server soft delete. It converts a support ticket into a self-service restore. There is no design work and no downside.
5. Audit the identity behind any MCP plugin you adopt. The PostgreSQL plugin can run queries, apply changes, and support database operations. Whatever principal it uses deserves the same scrutiny as any other write-capable service account.

Complete inventory — all 16

Every announcement Azure published between 14 and 18 September 2026, from the release communications archive. Nothing summarised away.

Official Azure references

• Network egress controls for hosted agents in Microsoft Foundry
• Enable and disable controls for Microsoft Foundry agents in Agent 365
• New Windows App client-side endpoints for Azure Virtual Desktop
• Retirement Update: SAP container images removed October 14, 2026
• High-scale mesh in Azure Virtual Network Manager
• Azure SQL updates for mid-September 2026
• HTTP/3 over QUIC support in Azure Application Gateway
• Foundry Routines in Foundry Agent Service
• Publishing Microsoft Foundry agents to Microsoft 365 Copilot and Teams
• PostgreSQL skills and MCP plugin for Azure Database for PostgreSQL