Weekly AI Roundup: Copilot governance, MCP ops, and AI gateways

by TechHub

This week's AI roundup centers on turning fast-moving model and agent ecosystems into something you can run in production: governed, observable, and cost-controlled. GitHub retired GitHub Models while Copilot continued rotating available models, pushing enterprises to tighten policy management, managed settings, and usage reporting. At the same time, MCP gained more standardized building blocks (including the MCP C# SDK v2.0 and broader IDE integrations), and Azure added more runtime control points through API Management's AI Gateway tier and new cost-management toolsets for agents.

This Week's Overview

GitHub Copilot model churn and enterprise governance

Building on last week's theme of “measure it, govern it, and expect model choice to keep changing,” GitHub retired GitHub Models on July 30, 2026, shutting down the playground, model catalog, inference API, and BYOK that lived under that product. If your team used GitHub Models as a lightweight way to evaluate models or as an inference endpoint, you now need to re-home that work, with GitHub pointing developers to Microsoft Foundry for model access and to Copilot for developer workflows.

At the same time, Copilot is actively rotating models inside its experiences. Gemini 2.5 Pro and Gemini 3 Flash were deprecated across Copilot as of July 31, with guidance to move to Gemini 3.1 Pro (Preview) and Gemini 3.6 Flash. For Copilot Enterprise, that migration may require updating model policies so the replacement models show up in the Copilot Chat model selector in VS Code and on github.com.

For admins, GitHub added multiple controls aimed at keeping fast-moving model availability from becoming chaos. A new policy for Copilot Business and Enterprise can enable newly generally available models by default (with org/enterprise opt-out and exclusions for open-weight models and models outside GitHub's data retention agreement), and team-based targeting for model policies is now in public preview so you can set enterprise defaults but grant extra models to specific teams. Enterprise managed settings also expanded to cover the GitHub Copilot app and Copilot cloud agent via managed-settings.json, and the Copilot app now has a dedicated access policy separate from the Copilot CLI policy so you can govern them independently.

Two more knobs landed for Copilot operations and risk management. A new enterprise managed setting (remoteControl) lets you restrict remote control to managed devices, including modes like requireSSO, disabled, or enabled. Usage metrics also got more actionable: Copilot app usage is now attributed to individual users and included in feature/model/language rollups in the Copilot usage metrics API, with expanded token and code activity metrics.

MCP and agent tooling becomes more operational (and more standardized)

Following last week's push toward governed MCP authorization and long-running, production-grade tool execution, a clear theme this week is that “agent integrations” are shifting from ad-hoc glue to something you can standardize, govern, and observe. That shows up in the MCP (Model Context Protocol) ecosystem (spec updates, SDK releases, and product integrations) and in more production-focused patterns for debugging, tracing, and deployment.

MCP C# SDK v2.0 aligns to the 2026-07-28 spec

The official MCP C# SDK shipped v2.0, implementing the 2026-07-28 MCP specification. The big shift is stateless-by-default MCP over HTTP, plus standardized routing headers to make intermediaries and gateways simpler.

v2.0 also adds Multi Round-Trip Requests (MRTR), which enable interactive tools without forcing you into session-oriented designs. The release notes call out backward compatibility guarantees and deprecations, and introduce opt-in Apps and Tasks extension packages so you can keep a smaller core dependency if you do not need those capabilities.

Copilot code review adds GA support for agent skills and MCP connections

After last week's focus on making Copilot code review more configurable and “enterprise-shaped,” Copilot code review now generally supports agent skills and MCP server connections across Copilot Pro, Pro+, Business, and Enterprise. That means review-time automation can be backed by your own tools, but with guardrails: the MCP tool calls are read-only in the code review context.

Configuration is split between defining skills (via SKILL.md) and wiring MCP servers and tokens, which makes it easier to reuse the same tool integrations across repos while keeping credentials out of documentation. If you have internal policy requirements, this is also a forcing function to standardize how you provision and audit MCP access across teams.

VS Code Copilot updates keep leaning into agent workflows

Building on last week's VS Code shift toward explicit agent architecture and skills migration, the July 2026 Copilot in VS Code releases (v1.127-v1.131) continued to center the Agents window as the place where “multi-step work” happens. Highlights include workflow improvements in the Agents window, multi-chat sessions (including Claude support), and chat/model updates like Copilot Vision GA and BYOK support directly in the Agents window.

Two small but practical details stand out for day-to-day use. You can run terminal commands from chat using a ! prefix, which shortens the loop between suggested fixes and validating them locally. And VS Code 1.131 demos show more transparency about subagents (session information surfaced in the Agents window) alongside a dictation mode, with a reminder that enterprise policies and Copilot plans can affect what your developers actually see.

New developer-facing MCP experiences: build log analysis and .NET skill discovery

Following last week's Agent Skills stabilization and richer MCP tool outputs, a preview MSBuild Binlog Analyzer for VS Code shows how MCP can make “tooling as chat” practical. It uses GitHub Copilot Chat backed by the Microsoft.AITools.BinlogMcp MCP server to explain build failures, analyze the performance critical path, compare builds, and detect regressions from .binlog files.

On the agent side, Microsoft Agent Framework added MCP-based Agent Skills discovery for .NET so an agent can discover and load skills from an MCP server on demand. The API centers on the Microsoft.Agents.AI.Mcp package and a UseMcpSkills builder, and the release explicitly calls out safety controls for archive-based skills (important if your skills can be packaged and transported rather than hand-authored).

JetBrains Copilot adds observability and tighter model controls for agent flows

Continuing last week's BYOK expansion in JetBrains (and the growing need to manage endpoints and spend), GitHub Copilot for JetBrains shipped improvements that matter most once you operationalize agents. OpenTelemetry export configuration is improved for agent workflows, and model-management controls now include token limits for BYOK/custom endpoints.

The release also adds MCP servers and custom agents in Claude agent flows, which is another sign that MCP is becoming the shared integration layer across IDEs rather than something tied to a single client. If you are trying to standardize agent behavior across toolchains, this is the direction you want, but it increases the need for consistent policy, auditing, and secrets management.

Microsoft Foundry and Azure AI: shipping models, agents, and geospatial workflows

Building on last week's Foundry focus on agent production mechanics (skills/tooling and repeatable workflows), this week combined “core platform” updates in Microsoft Foundry with new applied workflows, especially around agent service production features and GeoAI (geospatial AI). The net effect is more options for hosting and governing agents, plus a stronger story for data+model co-location (data zones and Planetary Computer Pro).

GPT-5.6 goes GA in Microsoft Foundry (plus new production controls)

GPT-5.6 (Sol, Terra, Luna) is now generally available in Microsoft Foundry. Alongside the models, the announcement emphasizes production features in Foundry Agent Service such as hosted agents, toolboxes, and observability (tracing and evaluation), plus an APAC Data Zone for teams that need regional deployment options.

The practical developer angle is cost and operational control. Microsoft calls out mechanisms like model router, prompt caching, and PTU (provisioned throughput unit) spillover, which are the kinds of features you need once you are balancing latency, quota, and cost across multiple apps and teams.

Foundry Toolkit for VS Code improves agent debugging and introduces optimization preview

Following last week's emphasis on observability and evaluation as first-class agent requirements, the Foundry Toolkit for VS Code shipped multiple July updates (1.6.3-1.6.6) focused on tightening the loop from building to debugging to tuning. The resource UI moved to a flatter, tabbed layout, and Tool Catalog workflows can run inline, reducing context switching when you are wiring tools into an agent.

Agent development got more introspectable with event-level Agent Inspector debugging, and there is an Agent Optimization preview aimed at measured tuning and deployment. That positions the toolkit as more than a deployment helper, it is moving toward an “agent workbench” where evaluation and iteration are first-class.

GeoAI expands with MARS in the Foundry Model Catalog and Planetary Computer Pro

Microsoft highlighted a concrete GeoAI workflow with MARS (Map Autoregressive), a geospatial model in the Foundry Model Catalog. The walkthrough shows how to use Planetary Computer Pro to convert satellite imagery into GIS-ready vector features like buildings, roads, railways, and waterbodies, using common geospatial formats and conventions.

For developers building mapping or operations analytics, the key is that this is not just “image-to-text”. The output is GIS-native vector data, and the pipeline references staples like STAC catalogs and Cloud Optimized GeoTIFFs (COGs), making it easier to plug into existing geospatial tooling and storage patterns.

AI gateways and cost governance for agentic systems

After last week's deep dive on using APIM and Foundry AI Gateway control planes to centralize limits, routing, and auditability, this week's cost and governance posts converged on the same idea: once agents can call tools and models freely, you need both budget guardrails and runtime enforcement. Azure API Management (APIM) and MCP-based tool access are becoming the backbone for that kind of control.

Azure API Management adds an AI Gateway tier (public preview)

Azure API Management introduced an AI Gateway tier in public preview, positioned specifically for publishing and governing AI models and MCP servers. The preview uses policy-card controls (JSON) and OpenTelemetry token metrics, and it is designed to integrate with Azure Policy and common observability backends.

For teams standardizing access across multiple model providers, the important detail is that it is not limited to one host. The announcement explicitly mentions support for multiple providers including Microsoft Foundry and external hosts, which makes it a practical choke point for quota, logging, routing, and compliance controls.

ARM MCP server adds Cost Management and Pricing toolsets for agents

The Azure Resource Manager (ARM) MCP server gained Cost Management and Pricing toolsets that let agents query and forecast costs, manage budgets and alerts, retrieve pricing, and analyze AKS spend. The setup guidance shows how to call these tools from GitHub Copilot Chat in VS Code and from the GitHub Copilot CLI, using MCP configuration headers.

The practical implication is that FinOps actions can become tool calls, not tickets. That can be helpful for self-service cost visibility, but it also increases the need to scope permissions carefully because “budget management” and “pricing queries” quickly turn into organization-level controls.

Copilot spend governance: budgets first, then runtime quotas via BYOK routing

This week's budget-and-quota guidance extends last week's shift toward repo-level usage visibility and operational cost controls by showing how to enforce spend at multiple layers. Two guides focused on GitHub Copilot budgets and how to avoid surprise overages. One walks through GitHub's enforcement order across included AI credits, user-level budgets, and enterprise/cost-center overage budgets, with an emphasis on enabling “Stop usage when budget limit is reached” if you want hard caps. Another guide shows how to combine GitHub's native budgets and usage metrics with BYOK routing through Azure API Management into an Azure AI Foundry (Azure OpenAI) deployment, enabling real-time token quotas and per-developer monitoring (for example via policies like llm-token-limit and emitting token metrics to Application Insights).

Taken together, the pattern is layered controls: use GitHub budgets to bound billing exposure, then use APIM as the enforcement point for per-request limits and observability. That is especially relevant now that Copilot model availability is broadening and usage-based billing is more prominent for certain models and workflows.

Security: captive-portal AiTM, agentic SecOps, and more AI red teaming

Building on last week's focus on supply chain integrity and least-privilege tool binding for agents, this week blended very practical threat intel (how travelers get targeted via captive portals) with platform work that treats AI agents as both defenders and potential new attack surfaces. The message for developers is to expect identity flows, device trust, and prompt/tool security to show up in more “normal” engineering decisions.

Midnight Blizzard's CaptiveCrunch campaign targets travelers via captive portals

Microsoft Threat Intelligence detailed CaptiveCrunch, a Storm-2945 (Midnight Blizzard) campaign targeting travelers by manipulating captive portal traffic to deliver malware and steal credentials and tokens. A notable technique is abuse of Microsoft Entra ID device code authentication, which can be attractive to attackers because it is designed for input-constrained devices and relies on users completing a verification step elsewhere.

The write-up includes concrete tradecraft details (including CornFlake RAT and ChocoShell PowerShell infostealer) plus hunting queries and mitigations for Microsoft Defender and Microsoft Sentinel. For organizations with traveling staff or BYOD realities, the defensive takeaways center on tightening device code flow monitoring, hardening token protections, and ensuring your detection content covers captive-portal and “adversary-in-the-middle” (AiTM) patterns.

Microsoft Security's July update: agentic SecOps and prompt injection defenses

Continuing last week's thread that agent capability expands the need for explicit authorization boundaries and audit trails, Microsoft's July 2026 security update framed “agentic SecOps” as an explicit product direction via Project Perception, and it called out new Microsoft Defender protections aimed at prompt injection and cloud agents. On the identity side, it highlighted Entra changes such as passkeys-by-default, and on the data side it covered Purview enhancements for DLP and insider risk investigations.

For teams deploying internal agents, this is a reminder that “agent security” is not only model safety. It spans identity defaults, tool authorization boundaries, logging, and policies that reduce how often a user can be tricked into granting an agent more access than intended.

External Red Team Alliance (EXTRA) expands AI safety testing capacity

Microsoft announced the External Red Team Alliance (EXTRA), expanding AI red teaming through academic funding and a distributed network of external specialists. The goal is to improve safety and security testing for frontier AI systems by bringing in outside expertise and scaling evaluation coverage.

For developers, the practical consequence is that evaluation expectations will keep rising. If you ship an agent that interacts with sensitive tools or data, assume threat modeling and red-team style testing (prompt injection, tool misuse, data exfiltration) will increasingly be a baseline, not an exceptional requirement.

New models and efficiency work: larger contexts, smaller “flash” models

Following last week's “model choice keeps broadening” story across Copilot and IDEs, model announcements this week landed on both ends of the spectrum: very large context windows for certain workflows, and smaller models optimized for cost and throughput. For developers, the decision is increasingly about matching the model to the interaction pattern (long-context investigation vs fast iterative coding vs high-volume security triage).

Grok 4.5 lands in Copilot with a 500k-token context window

Grok 4.5 (xAI) is rolling out as a selectable model in GitHub Copilot. GitHub highlights up to a 500k-token context window, multimodal inputs, and configurable reasoning effort, and it notes that usage-based billing applies and Business/Enterprise admins must enable it via model policy (it is off by default).

If you have workflows like large repo comprehension, multi-document architecture review, or long debugging transcripts, a large context window can reduce chunking and retrieval overhead. The trade-off is that governance and cost controls matter more because long contexts can amplify token spend quickly.

MAI “Flash” models focus on performance per token and per dollar

Microsoft published a broader strategy note on optimizing the “frontier performance curve” by co-optimizing models with harnesses and reinforcement-learning environments, referencing MAI “Flash” model releases and hardware like Maia 200. The focus is not only benchmark scores, but also cost-efficiency metrics that translate into product constraints like latency budgets and spend controls.

In a more developer-facing example, VS Code shared early results for MAI-Code-1-Flash in GitHub Copilot Chat for VS Code. The post emphasizes both quality metrics (acceptance, code/commit survival) and efficiency metrics (tokens per turn, turns per commit), positioning the model as a lightweight option for fast, iterative workflows, especially in “Auto” model selection flights.

Building with agents: from unit tests to production deployments

Building on last week's emphasis that production agents need repeatable workflows (skills, long-running tools, evals, and observability), a lot of this week's agent content is less about model novelty and more about shipping reliable software with agents in the loop. That includes test generation that validates against real repo workflows, and production guidance for identity, observability, and distribution.

A polyglot unit-test agent that learns repo conventions and runs the tests

The dotnet/skills project introduced code-testing-generator, an open-source polyglot unit-test agent that learns a repository's conventions, generates unit tests, and validates that they build and run in the repo's normal test workflow. Benchmarks in the post claim higher task completion and fewer failures than stock GitHub Copilot, with the biggest gains on vague prompts and diff-based test requests.

The important implementation detail is the validation loop. Generating tests is only useful if they compile and pass in the same CI workflow developers already use, and the agent's approach is designed around that practical constraint (with related concepts like code coverage and mutation testing discussed as quality signals).

Deploying multi-agent systems to Teams with Foundry Agent Service

This guide is a practical continuation of last week's “prototype to production” Foundry enablement thread by showing what it looks like to ship the same patterns into a real distribution channel. A production-focused guide walked through taking a multi-agent system from local development into Microsoft Foundry Agent Service, including the difference between Prompt Agents and containerised hosted agents. It covers identity using Entra ID (for example DefaultAzureCredential), observability via OpenTelemetry/Application Insights, and packaging/distribution into Microsoft Teams using Adaptive Cards and a declarative agent package.

For teams trying to get beyond demos, the value here is the end-to-end shape of a deployable agent: consistent identity, traceability, and a distribution channel that fits how users already work. It also highlights the operational overhead you should plan for early, like secrets management, telemetry pipelines, and permissions boundaries for tool access.

Agent teams with Agent Framework, Copilot CLI/SDK, and Squad

Following last week's agent engineering focus on standardized skills and tool boundaries, Microsoft published a guide to wrapping a Squad multi-agent team as a Microsoft Agent Framework AIAgent so it can be used from the GitHub Copilot CLI/SDK. The walkthrough includes C# dependency injection setup, session configuration, and OpenTelemetry tracing that flows through subagents.

This is a practical bridge between “agent orchestration frameworks” and “developer tools people actually use”. If you want agent teams to be adopted, wiring them into existing Copilot CLI workflows and instrumenting them so you can debug subagent behavior is a concrete path.

Other Artificial Intelligence News

GitHub and VS Code continued to publish small workflow tips for using Copilot day to day, from voice prompting and dictation to “prompt hygiene” for reducing avoidable token spend. These are low-stakes changes, but they hint at where interfaces are going: more spoken interaction and more tooling that nudges you toward reusable, standardized agent behaviors.

Visual Studio and the Copilot app both kept pushing on “agentic” UX, but in different directions. Visual Studio's July update added a new Agent (Preview) in Copilot Chat built on the GitHub Copilot SDK, with built-in .NET/Azure skills, org-level custom instructions, and branch attachment for richer context. The Copilot app content focused more on hands-on usage patterns like stacked sessions/stacked pull requests for ordered refactors, plus customization options such as themes, sounds, dictation/transcription models, and MCP server connections via BYOK providers.

Several broader platform updates and perspective pieces are worth skimming if you are building AI into production systems. Azure's weekly update included items relevant to AI operations (APIM AI Gateway mention, Azure Monitor log mirroring to Fabric), while Fabric's July feature summary and Fabric data agents updates continued to tighten CI/CD, governance, and MCP-based integration paths. On the architecture side, posts on token economics (cost per accepted task), reusable agent capability design (skill vs sub-agent), and separating real AI value from hype all pointed toward the same lesson: measure outcomes, control blast radius, and treat observability and policy as product features.

Deprecations and migrations continued outside Copilot too. Fabric Data Agent integrations that call the OpenAI Assistants API directly need to move to the Data Agent MCP endpoint ahead of the August 26, 2026 shutdown, while internal SDK and portal experiences will migrate to the OpenAI Responses API. If you have custom integrations, now is the time to inventory where you rely on Assistants semantics (threads, tool calls) and map them to the MCP endpoint or Responses API behavior before the deadline.

Microsoft Research introduced Echoverse, a set of deep, stateful synthetic environments with database-grounded verifiers for training computer-use agents, along with released code, datasets, and a technical report for four worlds. This kind of work matters if you are tracking where “computer-use agents” are headed, because the core challenge is evaluation: grounded verifiers are one way to score whether an agent actually did the right thing in a stateful environment.