29 October 2026 · A fortnightly briefing on .NET, Azure and practical AI-assisted engineering.
There has been no shortage of AI announcements this fortnight, but a few developments deserve attention because they change what engineering teams actually need to do. There is an urgent .NET patching job, more mature ways to run coding agents inside established delivery controls, and a useful shift towards choosing where models run without rebuilding the entire agent stack. Here is what I would prioritise.
1. .NET security: this is a patching week, not an upgrade debate
Microsoft released out-of-band .NET security updates on 25 October for .NET 8, 9 and 10, plus .NET 11 RC3. One fix addresses a Brotli decompression buffer-overflow vulnerability (CVE-2026-111497), which can affect applications processing Brotli-compressed data. Another fixes unsafe Linux tarball ownership metadata (CVE-2026-114148). Microsoft also says the 13 October fixes for a socket memory-corruption issue and a Blazor WebAssembly debugger issue were incomplete and has re-released them.
The updated versions are .NET 8.0.33, 9.0.22 and 10.0.14; .NET 11 RC2 users should move to RC3. The Brotli issue can involve ASP.NET Core request decompression, HttpClient automatic decompression or the compression APIs; the first two features are not enabled by default. Microsoft says .NET Framework is not affected by this out-of-band release.
What I would do: inventory the runtime on actual hosts with dotnet --list-runtimes, then separately identify self-contained executables and containers. A runtime update on the server does not patch an application with a bundled runtime. Rebuild, republish and redeploy those workloads, and verify the resulting versions. This is precisely why maintaining an estate inventory matters more than simply chasing the next major .NET release.
2. GitHub Agentic Workflows moves into the delivery pipeline
On 28 October, GitHub made Agentic Workflows generally available. Teams can describe repeatable reasoning tasks in Markdown, compile them into conventional GitHub Actions workflows and run an agent within existing runner and policy boundaries. Examples include CI failure investigation, issue triage, documentation improvements and test generation.
The security model matters as much as the feature: the workflows are read-only by default, run in sandboxed containers behind an agent firewall, validate outputs and use a separate threat-detection job before applying proposed changes. They also support other coding agents, rather than insisting on a single provider.
What I would do: pilot one low-risk, auditable job — for example, summarising failed builds with evidence and proposing a remediation PR. Require checks, human review and a measured benefit before expanding to automated code modification. These are engineering workflows, not an excuse to bypass engineering controls.
3. Local and cloud models are becoming choices within the same workflow
GitHub Copilot Fusion became generally available on 28 October, offering task-based model selection and multi-model orchestration. On the same day, local-model routing entered experimental preview. In supported Copilot CLI, app and VS Code experiences, Fusion can consider an on-device model as well as cloud models. Manually configured local models are supported in the CLI on Windows, macOS and Linux, subject to provider/model eligibility.
There is an important caveat: local routing is not offline operation. GitHub says Fusion’s routing decisions still happen in the cloud. It is worth testing latency, data handling, task quality and actual cost rather than treating “local” as an automatic privacy guarantee.
For C# teams, Microsoft’s 19 October Copilot SDK example makes the separation between agent runtime and model provider explicit. Its .NET 10 sample sends inference to a Microsoft Foundry or Azure OpenAI deployment via ProviderConfig, using Entra ID or an API key. The local Copilot CLI runtime is still needed — bringing your own model is not the same as removing the runtime dependency.
What I would do: compare a small local model and a cloud model against the same real repository task. Measure accepted output, human review time and cost per successful change, not model rankings alone.
4. Microsoft Foundry is turning agent execution into managed infrastructure
Microsoft introduced the Copilot harness in Foundry Agent Service on 28 October as a public preview, alongside the general availability of long-running resilience for hosted agents. The managed harness provides agent execution, reusable skills, connected tools, bounded delegation and source-controlled agent definitions; teams still define tools, permissions and domain-specific processes.
That distinction matters. A model is only one component of a production agent. The harder parts are reliable execution, controlled side effects, recovery, identities, observability and auditability. In regulated or business-critical software, the durable process should remain explicit even when the next action is suggested by an LLM.
What I would do: prototype on a non-critical workflow with a known input and verifiable output. Test interruption and recovery, least-privilege tool access, cost controls and approval boundaries before connecting an agent to live customer or financial operations.
5. Browser automation offers a pragmatic route into legacy systems
On 19 October, Microsoft’s Foundry Browser Automation Tool reached general availability. Built around managed Playwright Workspaces, it lets agents navigate web interfaces, including private applications connected through Azure networking, without operating their own browser infrastructure. The platform includes observability and human oversight.
This is particularly relevant when an established business system does not expose a usable API. Browser automation can bridge a gap while proper integration is planned. But it is more fragile than a documented API, and security-sensitive or irreversible actions still need explicit checks and approval. I would start with read-only investigation or reconciliation before allowing writes.
6. A small but worthwhile Blazor update
On 27 October, Microsoft announced that Infragistics has opened more than 50 Blazor controls under the MIT licence and is contributing directly to Blazor. Its work includes .NET 11 analyzers that flag unnecessary StateHasChanged() calls and potentially stale authentication-state usage. This is not a reason to replace an existing component library, but it is worth evaluating for new internal tools and upgrading code-quality checks.
The practical takeaway
The pattern across these announcements is fairly clear: the interesting improvement is no longer simply getting an AI model to produce more code. It is making execution dependable, choosing the right tool and model for the job, and keeping the resulting changes observable and reviewable. Start with the security updates, then choose one agent workflow where you can measure genuinely useful results.
If you are working through similar decisions on an established .NET estate, these earlier articles may help: Should You Maintain or Rewrite a Legacy .NET Application? and From Legacy to Modern .NET: An AI-Assisted Migration Playbook. I also help teams with practical .NET modernisation and business automation — without turning every problem into an AI project.
Peter French · peterfrench.dev
