Weekly AI Roundup: Agent Governance, Costs, and Resilience Drills
Welcome to this week's Weekly AI Roundup, where the common thread is taking agentic AI from demos to operations: more automation, more guardrails, and more ways to prove what happened. Azure pushed reliability toward standardized, automatable determinations with its internal “Brain” system and scenario-first Chaos Studio Workspaces that can plug into Copilot and MCP. GitHub Copilot news focused on enterprise governance and spend controls (managed-settings.json, credit pools, session limits, and audit-grade agent session streaming) alongside rapid model lineup changes and the approaching GitHub Models shutdown. Across MCP, Foundry, Fabric, and IDEs, the story is clear: tool use is expanding (browser automation, vision inputs, CI diagnostics), so security, provenance, and repeatable evaluation need to expand with it.
This Week's Overview
- Azure reliability gets more “agentic” - and more testable
- Copilot in enterprise environments: model churn, governance, and spend controls
- GitHub Models retirement: July 30 shutdown with brownouts
- Model picker changes: deprecations and new availability (Claude and Kimi)
- Centralized settings: managed-settings.json GA and defaulting to auto model selection
- Cost controls and attribution: AI credit pools, per-user budgets, and session limits
- Telemetry and auditability: agent session streaming and usage metrics improvements
- Safer automation in CI: Copilot CLI in Actions without a PAT
- Agents and MCP: building blocks for tool use, governance, and long-running work
- Microsoft Foundry and Fabric: production paths for models, agents, and migrations
- Copilot feature surface area expands: vision, browser tools, IDE coverage, and deeper reviews
- Security and governance for agents: MCP trust, telemetry, and supply chain risks
- Other Artificial Intelligence News
Azure reliability gets more “agentic” - and more testable
Mark Russinovich outlined two complementary pieces of Azure's reliability story this week: an internal AI layer that reasons about platform health, and a new, scenario-first way for customers to continuously prove their own application resilience. The throughline is standardization - turning messy telemetry and failure modes into repeatable determinations, gates, and drills you can automate.
Brain: Azure's internal AIOps “digital twin” for health and automation
Azure introduced “Brain”, an internal reliability intelligence layer that builds a digital twin of Azure health by combining Azure Resource Graph inventory, telemetry, dependency signals, and customer impact. Rather than treating incidents as isolated alerts, Brain produces standardized “health determinations” that can drive automated operational actions.
For developers and platform teams, the key idea is that reliability work is shifting from reactive dashboards to policy-driven automation. Brain is positioned to feed agentic workflows and “deployment gates”, meaning rollouts can be blocked or slowed when the platform detects risk patterns, not just when a single metric trips.
Chaos Studio Workspaces: curated outage drills with scenario reports (plus MCP and Copilot hooks)
Azure Chaos Studio added Chaos Studio Workspaces (public preview), which reframes chaos engineering around scenarios instead of individual faults. Workspaces recommend and run curated outage drills across your Azure resources, then generate structured scenario reports that correlate what happened with Azure Monitor signals.
The practical win is repeatability: you can start from a scenario catalog (for example, an Entra ID outage scenario) and consistently produce evidence of resilience gaps and mitigations, instead of hand-rolling experiments per service. The preview also adds integrations for driving Chaos Studio via a GitHub Copilot Skill and an MCP (Model Context Protocol) server, which builds directly on last week's MCP-through-everyday-workflows theme by turning resilience drills into something an agent can run, document, and follow up on.
Copilot in enterprise environments: model churn, governance, and spend controls
A lot of GitHub Copilot's week was about making AI usage easier to govern at scale: centrally managing client settings, tracking and auditing agent activity, controlling which models appear, and putting real budget boundaries around usage-based billing. The other big theme is model lineup changes, including deprecations and a hard platform retirement deadline.
GitHub Models retirement: July 30 shutdown with brownouts
Following last week's note that GitHub Models was already closed to new customers, GitHub confirmed that GitHub Models will be fully retired on July 30, 2026, including the playground, model catalog, inference API, and BYOK endpoints. Two brownouts are scheduled ahead of time (July 16 and July 23), which should be treated as operational fire drills to flush out dependencies you might have missed.
If you built internal tooling around the GitHub Models inference API or used BYOK endpoints, you need a migration plan now. The announcement points developers toward alternatives like Azure AI Foundry, but the core action item is inventorying integrations and replacing calls before the brownouts reveal them in production.
Model picker changes: deprecations and new availability (Claude and Kimi)
Building on last week's Opus model lifecycle changes and broader “what model is my team using” concerns, GitHub announced that Gemini 2.5 Pro and Gemini 3 Flash will be deprecated across GitHub Copilot experiences on July 31, 2026, with Gemini 3.1 Pro and Gemini 3.5 Flash recommended as replacements. Copilot Enterprise admins may need to explicitly enable the replacement models via model policies so they show up in Copilot Chat selectors in VS Code and on github.com.
On the “what's new” side, Anthropic Claude Sonnet 5 is now generally available in GitHub Copilot, and Claude Opus 4.8 (fast mode) rolled out in preview for faster output token speeds in interactive and agentic workflows. GitHub also made Kimi K2.7 Code generally available as a selectable Copilot model, with Business and Enterprise policy controls and usage-based billing considerations called out.
- Upcoming deprecation of Gemini 2.5 Pro and Gemini 3 Flash
- Claude Sonnet 5 is generally available for GitHub Copilot
- Claude Opus 4.8 (fast mode) is now in preview for GitHub Copilot
- Kimi K2.7 Code is generally available in GitHub Copilot
Centralized settings: managed-settings.json GA and defaulting to auto model selection
This is a direct follow-on to last week's push for enterprise guardrails (including permission prompt policies and auto mode going GA): Enterprise managed-settings.json is now generally available for GitHub Enterprise Cloud, using a file stored in a .github-private repository to centrally govern Copilot client settings. Enforcement applies in supported clients like VS Code and Copilot CLI, which means you can finally treat Copilot configuration like code (reviewable, versioned, and auditable).
On top of that, enterprises can now default the model setting to auto in managed-settings.json, so Copilot uses automatic model selection for new conversations by default (VS Code 1.126+). Teams still can change models per conversation where allowed, but this sets a sane default posture for large rollouts.
- Enterprise managed-settings.json is generally available
- Enterprises can default to auto model selection
Cost controls and attribution: AI credit pools, per-user budgets, and session limits
After last week's step toward per-user credit visibility in reporting, GitHub expanded cost center support for Copilot usage-based billing with AI credit pools, letting enterprises cap how much of the monthly included Copilot AI credits each cost center can consume (currently via the REST API). It also added per-user AI credit budgets at the cost center level, so budgets automatically follow users as they join or leave cost centers or enterprise teams (creation also currently via REST API, with UI support planned).
At the execution level, Copilot CLI and the GitHub Copilot SDK added public preview support for AI credit session limits. You can set caps like --max-ai-credits (and use /limits) so interactive or scripted runs stop when they hit the session budget, including spend across subagents and background work.
- Cost centers now support AI credit pools
- Per-user AI credit budgets available for cost centers
- Set AI credit session limits in Copilot CLI and SDK
Telemetry and auditability: agent session streaming and usage metrics improvements
This continues last week's direction of making agent activity measurable (from usage metrics expansion to per-user credit reporting) by pushing audit-grade detail into the pipeline: Copilot agent session streaming entered public preview for GitHub Enterprise Cloud, letting organizations stream or query agent session usage records (prompts, responses, and tool calls) across Copilot clients. You can send this data to a SIEM or event collector through audit log streaming (Microsoft Purview is supported as a streaming endpoint), or pull the last 48 hours via a REST API.
GitHub also improved Copilot usage metrics reports in three ways: Copilot CLI now reports suggested lines of code, more users have IDE/plugin details surfaced via server-side telemetry, and AI credit usage is attributed more accurately to organizations and enterprises. Together, these updates make it easier to answer “who used what, where, and what did it cost” with fewer blind spots.
- Copilot agent session streaming is now in public preview
- Improved accuracy and coverage in Copilot usage metrics reports
Safer automation in CI: Copilot CLI in Actions without a PAT
This builds on last week's tightening of enterprise permission boundaries for Copilot CLI by removing a common CI secret: Copilot CLI can now run in GitHub Actions using the built-in GITHUB_TOKEN instead of requiring a personal access token (PAT). That removes a common source of long-lived secrets in CI while keeping Copilot policy and permissions in the normal GitHub controls model.
The post also calls out how organization billing and spend controls work for AI credits, which matters if you are turning Copilot CLI into a standard step in workflows. If you plan to scale agentic automation in CI, this change reduces the security overhead that often blocks adoption.
Agents and MCP: building blocks for tool use, governance, and long-running work
This week added practical guidance and new infrastructure for agentic systems that call tools (especially via MCP), plus sharper warnings about MCP-specific supply chain risks. The common theme is moving from “agents can call tools” to “agents can call tools safely, at scale, and in production workflows.”
kars: a Kubernetes-native runtime for agents with sandboxes and CRD governance
kars was introduced as an open-source, Kubernetes-native runtime for running AI agents on AKS. It focuses on operational isolation and control: per-agent sandboxes (including AKS Pod Sandboxing), CRD-based governance integrated with the Microsoft Agent Governance Toolkit (AGT), and an end-to-end encrypted inter-agent mesh (AgentMesh).
For teams already standardizing on Kubernetes, kars reads like a reference architecture for productionizing agents with a cluster-first approach. The CRD model is important because it lets platform teams express policy and governance as Kubernetes resources, instead of burying rules inside app code.
Long-running MCP tools on Azure Functions: Durable Functions as a stopgap pattern
MCP's synchronous tool call pattern breaks down when a tool's work takes minutes (or longer) and you need retries, checkpoints, and state. A guide showed how to implement long-running MCP tools using Azure Functions with Durable Functions, returning a workflow_id that clients can poll until MCP's Tasks extension is broadly supported.
This is a useful pattern if you are exposing enterprise tools (migrations, reports, remediation jobs) through MCP and you cannot guarantee quick completion. It also pairs well with governance because Durable Functions give you explicit state transitions and better observability hooks than “one big request”.
Bringing MCP into CI: automated build diagnostics via the Binlog MCP Server
Following last week's preview of the MSBuild Binlog MCP Server as an agent-friendly troubleshooting surface, a .NET guidance post demonstrated running the Microsoft Binlog MCP Server inside GitHub Actions to analyze MSBuild binlogs when PR builds fail. The workflow posts root-cause comments with suggestions, and the authors shared evaluation results comparing tool-based setups to a no-tools baseline, plus a catalog of additional Binlog MCP tools.
The practical implication is that MCP does not have to live in a chat window. You can treat MCP servers as reusable, auditable tool endpoints inside automated pipelines, which is often a better fit for teams that want deterministic diagnostics and consistent feedback loops.
Microsoft Foundry and Fabric: production paths for models, agents, and migrations
Azure and Fabric both pushed “make it real” updates this week: a production-grade model endpoint story for Claude on Azure, and APIs and CLI skills that bring Fabric agent and migration workflows into normal engineering pipelines.
Claude GA in Microsoft Foundry: Azure-native identity, routing, and evaluation
This complements last week's theme of shifting from ad hoc BYOK setups to governed platforms (and tracks with GitHub pointing GitHub Models users toward Foundry): Anthropic Claude is now generally available in Microsoft Foundry on Azure, framed as a production path for agentic applications with Azure-native identity and governance (including Microsoft Entra ID), data-zone options, and consolidated billing. The post highlights Foundry capabilities like model routing, continuous evaluation via the Foundry control plane, and agent optimization.
For teams choosing between “bring your own API key” and a governed enterprise setup, the Foundry pitch is about operating models like first-class cloud resources. Zero data retention (ZDR) options and control-plane evaluation are especially relevant if you are building agents that touch sensitive data and you need repeatable quality checks.
Fabric data agent API goes public, and Synapse migrations add AI-assisted CLI skills (preview)
Microsoft Fabric made its data agent API public, enabling programmatic creation, configuration, updating, and publishing of Fabric data agents via the Fabric REST API and SDK outside the Fabric portal. That matters if you want agents to be part of your infrastructure-as-code story, not something configured manually per workspace.
Separately, Fabric introduced a preview of AI-assisted command-line migration skills to move Azure Synapse Spark artifacts and Synapse pipelines into Microsoft Fabric. The workflow is described as guided phases with automatic refactoring and a migration report that flags blockers, which is the kind of “assist, then verify” tooling teams need for large migrations.
- Fabric data agent API is now public: Build Fabric data agents into your tools and pipelines
- AI-assisted Synapse Spark and pipeline migration to Microsoft Fabric from the command line (Preview)
Copilot feature surface area expands: vision, browser tools, IDE coverage, and deeper reviews
Across GitHub Copilot and IDEs, this week was about expanding what the assistant can “see” and “do” (images, PDFs, and browsers), plus improving agent ergonomics in editors and making PR review more rigorous when changes get complex.
Copilot Vision GA: image and PDF inputs across Chat and CLI
Copilot vision is now generally available, enabling image and PDF attachments in GitHub Copilot Chat (VS Code and github.com) and in the Copilot CLI. It applies to all Copilot plans and removes the need for the Editor Preview Features policy for Business and Enterprise, which should simplify rollout.
For developers, this is a concrete workflow upgrade: you can paste a screenshot of an error, attach a PDF spec, or share UI mocks directly in a Copilot session without workarounds. As with any multimodal input, enterprise teams should align this with data handling rules (what is allowed to be attached, retained, or logged).
Browser tools GA in VS Code: agents can drive real web flows
This week's browser automation capabilities land in the same trust-boundary territory we highlighted last week with the AutoJack MCP WebSocket chain: Browser tools for GitHub Copilot in VS Code are now generally available, letting agents run scripted flows in a real browser, capture page content, and collect console errors. The announcement also calls out privacy defaults plus enterprise admin controls for enabling and restricting the feature, and it ties into existing concepts like Workspace Trust.
This pushes Copilot closer to end-to-end testing and debugging workflows, where the agent is not limited to reading code but can reproduce a bug, observe browser errors, and report back with steps and evidence. If you adopt it broadly, plan for guardrails around what sites can be visited and how captured content is handled.
Medium depth code review preview: higher reasoning for tougher PRs
GitHub demoed a new Copilot code review “medium depth” option (public preview) that uses a higher reasoning model to deliver more thorough pull request feedback. The focus is complex and security-sensitive changes, and administrators can enable it at the repository or organization level.
If your team tried AI reviews and found them too shallow, this is aimed at closing that gap. It also implies you may want different review depth policies for different repos (for example, deeper reviews for auth, crypto, or infra code) rather than a one-size default.
Copilot agent reaches JetBrains, and VS Code 1.127 improves agent session UX
This expands on last week's JetBrains and Copilot CLI investment by making “agent mode” more consistent across IDE surfaces: GitHub Copilot Agent is now available in JetBrains AI Assistant through agent client protocol support, exposed via the AI agents tab. The rollout positions Copilot as a first-class selectable agent inside JetBrains IDEs, with model selection and reasoning-depth controls and workflows like summarizing a project, reviewing a README, and running tests with code coverage evaluation.
On the VS Code side, a 1.127-focused update highlighted Copilot session management and agent review ergonomics: session list drag-and-drop, chat input banners, editor gutter feedback for reviewing agent changes, session layout tweaks, a troubleshoot skill for agent behavior, and visibility into subagent credit usage. Together, these changes tighten the feedback loop for teams that are starting to treat “agent runs” as a normal dev activity that needs organization, review, and cost visibility.
- GitHub Copilot Agent is now available in JetBrains AI Assistant
- Copilot Agent is now available in JetBrains AI Assistant
- Visual Studio Code and GitHub Copilot - What's new in 1.127
Security and governance for agents: MCP trust, telemetry, and supply chain risks
This week's security items were consistent: once agents move from reading to acting, the governance problem shifts from “what did the model say” to “what did the model do, with what tools, under what policy, and how do we prove it.”
MCP tool poisoning risks and practical mitigations across Microsoft controls
This extends last week's AutoJack lesson (trust boundaries around MCP endpoints) into the supply chain layer: a Microsoft Security analysis warned that MCP tool metadata (like descriptions) can be poisoned to manipulate an agent's behavior and trigger data exfiltration or unsafe actions. The post maps mitigations to concrete controls across the Microsoft stack, including Prompt Shields, Purview DLP (data loss prevention), Entra Agent ID, Defender, and Sentinel, making it a useful checklist for threat modeling MCP-based tool ecosystems.
The key takeaway for builders is to treat tool descriptions and schemas as part of the agentic supply chain. Review, sign, validate, and constrain tools like you would dependencies, and assume “instructions” can be adversarial even if they look like documentation.
Broader Microsoft Security updates: scanning, local agent protections, and recovery
Microsoft's June 2026 security roundup included “MDASH” (private preview) for agentic vulnerability scanning, plus Microsoft Defender protections for local AI agents and MCP servers (preview). It also called out Entra Backup and Recovery going GA and continued expansion across Defender for Cloud and Microsoft Purview for multicloud and data security.
For dev and platform teams, this reinforces that “agent security” is becoming a first-class product area, not a DIY exercise. If you are rolling out MCP servers internally, start aligning them with your existing Defender/Sentinel/Purview strategy early, before tool sprawl makes consistent policy hard.
Visual Studio June update: token tracking and MCP server trust validation
This is a natural follow-on to last week's focus on token efficiency and cost visibility, but pushed into the IDE's daily workflow: Visual Studio shipped a June update that refreshes the Copilot Usage window with token-based tracking and alerts, which makes individual and team-level usage more legible. It also adds trust validation for MCP servers, addressing a key enterprise concern: whether the tool endpoints your assistant is calling are known and approved.
The update also made the GitHub Copilot modernization agent for C++ MSVC upgrades generally available, which will matter to teams migrating toolchains and needing repeatable, guided refactors. Taken together, the theme is “trust your tools” by making both cost and tool provenance visible in the IDE where developers actually work.
Other Artificial Intelligence News
Azure's weekly update roundup continued to mix AI platform news (Azure AI Foundry model availability, Copilot model updates) with adjacent infrastructure items like VM restore points, blob integrity improvements, and PII/quantum-safe notes. If you track Azure changes operationally, it's a useful single video to scan for cross-service deltas that can affect AI workloads indirectly (storage, migrations, and compliance controls).
GitHub Issue fields reached GA, bringing typed metadata to issues across organizations and projects, and importantly making those fields accessible via MCP server access for AI tools like Copilot. That is a quiet but meaningful step for building agents that can reliably read and write structured project context, rather than scraping labels and freeform text.