Weekly .NET Roundup: Secure Scanning and Practical Agent Workflows
Welcome to this week's Weekly .NET Roundup, where the themes are clear: tighter security scanning and more practical, governed agent workflows. CodeQL 2.26.0 adds AI prompt injection detections and improves query accuracy across languages, which is relevant for .NET repos that mix C#, JavaScript/TypeScript, and GitHub Actions-heavy CI. On the productivity side, Copilot's new upgrade canvas, real-world cross-repo agent automation patterns, and Agent Framework updates (orchestration patterns and stable skills) show how teams are turning agents into repeatable workflows. We also cover VS Code Copilot governance details, Logic Apps Standard moving closer to Functions-style hosting for .NET, and the growing link between agent platforms (Foundry) and UI patterns in Blazor.
This Week's Overview
- Security scanning for .NET codebases: CodeQL 2.26.0 and new AI prompt injection checks
- Copilot and agentic workflows are getting more “end-to-end” for .NET teams
- VS Code for .NET: Copilot model configuration and the next Insiders train
- .NET in Azure integration: Logic Apps Standard leans further into Functions hosting
- Foundry and Blazor: building blocks for agent-driven experiences
- Other .NET News
Security scanning for .NET codebases: CodeQL 2.26.0 and new AI prompt injection checks
CodeQL 2.26.0 shipped for GitHub code scanning with a security-oriented set of updates that .NET teams will feel even when the headline is not C#. Building on last week's shift toward production-grade agentic workflows (with more tool calling and structured outputs inside real repos), the release adds new JavaScript/TypeScript detections for system prompt injection, which matters for .NET apps that embed JS/TS in front ends, build pipelines, or agent-style tooling around APIs.
The release also includes multiple query accuracy improvements across C#, Go, Python, Swift, and GitHub Actions. If you rely on CodeQL to gate merges, this is a good week to review whether updated queries change alert volume or reduce false positives, especially in repos with mixed .NET + JS/TS code or GitHub Actions-heavy CI.
Copilot and agentic workflows are getting more “end-to-end” for .NET teams
This week connected three adjacent threads: Copilot moving from chat into guided upgrade work, teams operationalizing agentic automation inside GitHub, and Microsoft Agent Framework maturing the building blocks (orchestration patterns and skills) to ship multi-agent systems in production, continuing last week's theme of moving from demos to governed workflows you can host, secure, and observe.
Modernize .NET apps with the Copilot upgrade canvas
GitHub Copilot upgrade now includes an interactive “upgrade canvas” in the GitHub Copilot app that pulls .NET modernization into a single workflow. Instead of bouncing between assessment notes, package update attempts, and build troubleshooting, the canvas is positioned as the place where planning, code changes, and build failures come together.
The same upgrade flow is available in Visual Studio, VS Code, and the GitHub Copilot CLI, which makes it easier to adopt without changing where your team works day to day. Practically, this is aimed at the unglamorous parts of upgrades (NuGet package updates, cascading build errors, and incremental fixes), so it is worth evaluating on a real repo with CI enabled to see how it surfaces failures and next steps.
A real-world pattern: agentic cross-repo docs PRs (and how they kept it secure)
The .NET Aspire team shared how they use GitHub Agentic Workflows to generate cross-repo documentation pull requests from merged product PRs, which pairs neatly with last week's “agent harness” discussions by showing what governance looks like when an agent is allowed to act across repo boundaries. The interesting detail is the operational design: they used a safe-outputs handler plus tightly scoped GitHub App permissions to satisfy security review while still letting an agent open PRs across repositories.
If you have struggled to automate “last-mile” maintenance work (docs, samples, changelogs) because the security model gets complicated once you cross repo boundaries, this case study is a concrete reference architecture. It also includes the contract they enforce via frontmatter and rollout metrics that show faster documentation turnaround, which helps when you need to justify the engineering effort internally.
Microsoft Agent Framework: orchestration patterns 1.0 and stable Agent Skills for .NET
Microsoft Agent Framework announced orchestration patterns reaching 1.0 across both Python and .NET, covering sequential and concurrent flows, group chat, handoff, and “magentic” orchestration, building on last week's introduction of the Agent Framework “harness” approach by moving key coordination patterns into a more formal, versioned shape. The key implementation angle is the builder approach that generates runnable workflows, including an example using MagenticBuilder with FoundryChatClient and Azure identity credentials.
In parallel, Agent Skills for .NET reached a stable release with an open packaging format and production controls like approval (human-in-the-loop gating), filtering, caching, and controlled script execution. For .NET teams building internal agents, the practical takeaway is that “skills” are becoming a first-class unit you can standardize, review, and govern instead of wiring one-off tool calls into each agent.
- Agent Framework’s Orchestration Patterns Reach 1.0
- Agent Skills for .NET Is Now Released
- Agent Harness: Scaling the claw or harness capabilities
VS Code for .NET: Copilot model configuration and the next Insiders train
VS Code updates this week were less about editor features and more about how Copilot behaves in enterprise setups, plus the usual steady cadence in Insiders, extending last week's editor focus from “new capabilities” into the operational details teams hit when they standardize Copilot across environments.
VS Code 1.128: Copilot utility model defaults and enterprise policy constraints
The VS Code 1.128 Copilot update focused on configuration and governance: setting the default utility model for BYOK (bring your own key) setups, and walking through how enterprise policies and pricing plans can change which Copilot features appear. If you administer developer environments, the practical work is verifying the “why is this feature missing” cases by mapping plan and policy to UI availability.
For individual developers, the takeaway is that model selection is increasingly part of day-to-day Copilot tuning rather than a hidden admin-only decision. That matters when you want consistent behavior across teams (for example, ensuring the same utility model for quick tasks versus heavier reasoning models for refactors).
VS Code 1.129 (Insiders): tracking the milestone as it lands
VS Code 1.129 (Insiders) is in its rolling release-note phase, with links into the commit log and the list of closed issues in the 1.129.0 milestone. Following last week's notes on incremental VS Code changes that can affect Copilot UX and cost/usage reporting, this is mainly a reminder to watch the milestone list for C# Dev Kit, debugging, and editor regressions before they hit Stable.
.NET in Azure integration: Logic Apps Standard leans further into Functions hosting
Azure Logic Apps updates continued to tighten the relationship between Logic Apps Standard and Azure Functions, with a specific direction of travel toward out-of-proc hosting for .NET 10. This also follows last week's broader push to bring identity, governance, and “real app” hosting concerns into integration surfaces: the July 2026 Logic Apps Aviators newsletter called out dynamic connector connection names and new GA management capabilities for MCP servers in Azure API Management, which signals more investment in governable integration + agent tooling.
For developers building integration-heavy .NET systems, Local Functions are the practical part to internalize. Logic Apps Standard Local Functions let you ship workflow-scoped .NET code inside the same Logic Apps project, which changes how you package, test, and deploy when compared to maintaining separate Azure Functions apps, especially once CI/CD needs to move connectors, workflows, and code as one unit.
Foundry and Blazor: building blocks for agent-driven experiences
Two threads worth watching together are (1) platform capabilities for building and running agents and (2) UI patterns for turning agent output into real product experiences, continuing last week's MCP + Blazor storyline by expanding both the backend platform (Foundry) and the frontend patterns (generative UI).
Microsoft Foundry's June 2026 digest is packed: Claude became GA on Azure, agent distribution expanded into Microsoft 365 Copilot and Teams, and there were updates across Toolboxes/Tool Search, Routines, Agent Optimizer, Memory (including TTL and procedural memory), and observability via OpenTelemetry tracing. Foundry Local on Azure Local and the Voice Live API also point to more scenarios where .NET apps can run agent experiences near where data lives, or add real-time voice interfaces.
On the UI side, the Blazor Community Standup explored generative UI patterns where agents dynamically create and adapt app experiences using AG-UI and A2UI, alongside the Microsoft Agent Framework. For .NET teams building line-of-business apps, the key question is where the boundary sits between your “safe, typed UI” and agent-generated UI, and what guardrails (schemas, allowed components, review flows) you need before this is usable beyond demos.
- What’s New in Microsoft Foundry | June 2026
- Blazor Community Standup: Generative UI with AG-UI & A2UI
Other .NET News
Andrew Lock continued his .NET 11 preview series with a look at improvements to System.Diagnostics.Process output handling, including safer APIs to read stdout/stderr as text, lines, or bytes, plus a helper to run a process and capture output in one call, which continues directly from last week's .NET 11 preview coverage around low-allocation and tooling-friendly APIs. If you have ever hit deadlocks or awkward async plumbing when capturing process output in build tooling or test harnesses, these APIs are worth tracking as .NET 11 progresses.
A couple of community tutorials showed practical Agent Framework usage with locally running Ollama models, including enabling an agent to read a local text file via the Microsoft.Agents.AI.Harness NuGet package and displaying token usage in a .NET console app. These are small, but useful reference points if you want to prototype locally without wiring up hosted model infrastructure.
VS Code also promoted more lightweight learning and workflow tips, including free hands-on “VS Code Learn” courses and a short overview of using VS Code Tasks (tasks.json) to rerun common project commands from inside the editor.
- Improvements to reading Process outputs: Exploring the .NET 11 preview - Part 5
- How AI agent can read local file in .NET Agent framework harness with Ollama
- How to display AI agent token usage in .NET Agent Framework and Ollama
- VS Code Learn: free hands-on courses from the VS Code team
- Save time with VS Code Tasks