Weekly AI Roundup: Safer Agents, MCP Tooling, Copilot Governance

by TechHub

This week's AI roundup focuses on what it takes to run agents in production: move safety from prompt rules into enforceable environment controls, and make every tool call and permission boundary auditable. GitHub Copilot expanded shared agent sessions into Microsoft Teams and Slack while adding canvases and session management so collaborative work stays visible, reviewable, and tied to spend. MCP continued to solidify as the tooling layer for agents with connectors, hosted servers, and portable packaging, and Foundry updates added structured outputs and clearer guidance on when to choose prompt agents versus hosted orchestration. Across it all, the theme is practical governance - budgets, managed settings, approvals, and observability that keep agent-driven work predictable.

This Week's Overview

Agent safety shifts from “prompt rules” to “environment controls”

Building on last week's emphasis on multi-agent safety boundaries (Kars on Kubernetes) and approval-gated operations assistants, Microsoft shared a clear safety lesson from redesigning Azure SRE Agent: instead of trying to constrain an agent purely through instructions, move enforcement into the surrounding environment where the agent cannot bypass it. The redesign centers on microVM sandboxing for isolation, secretless authentication mediated by an egress proxy, and secret scrubbing before any data reaches the model context.

The practical impact is a more defensible architecture for production-grade agents: the agent operates with least privilege by default, risky actions require risk-based approval (especially production mutations), and sensitive data exposure is reduced even when prompts or tool outputs are messy. If you are building your own agent workflows, this is a concrete blueprint for where to place guardrails: at the network boundary, identity boundary, and execution boundary, not inside the agent's “brain.”

GitHub Copilot moves further into collaborative, multi-surface agent work

Following last week's shift toward “agents as workflow infrastructure” (comment-triggered automations, session tracking, and policy-driven governance), this week's Copilot news converged on the same theme: agent sessions are no longer confined to an IDE chat pane. Previews in Teams and Slack, plus new “canvas” and session-management patterns, point toward shared, durable workflows where multiple people can steer an agent, review progress, and control spend and risk.

Shared agent sessions in Microsoft Teams (public preview)

GitHub introduced a public preview for starting shared Copilot cloud agent sessions from Microsoft Teams using @GitHub, with progress tracked in a dedicated code channel. The workflow emphasis is collaboration: discussions happen where teams already coordinate incidents and feature work, while the agent runs in a cloud sandbox.

Admin and governance hooks are part of the story: the preview mentions AI credit and sandbox billing controls, plus an optional extra approval requirement for Copilot-attributed pull requests. For teams adopting agent-driven changes, that “extra approval” toggle is a practical way to keep human review as a policy, not a convention.

Copilot's coding agent arrives in Slack (public preview)

A parallel public preview brings Copilot's coding agent into Slack via @GitHub, supporting shared sessions that can triage issues, investigate failures in a secure sandbox, and open pull requests from conversations. Slack Code channels aim to keep agent work scoped and discoverable, instead of mixing it into general chat streams.

For developers, this pushes agent workflows closer to where alerts and requests land, but it also raises the bar for admin controls and auditability. If your organization already routes operational work through Slack, this preview suggests Copilot sessions can become another “first responder” surface, as long as sandboxing and permissions are configured conservatively.

Canvases, parallel sessions, and “My work” make agent work trackable

Building on last week's “make agent work measurable” thread (ROI views, agent activity breakdowns, and more session UX in the Copilot app/VS Code), GitHub continued to fill in the workflow primitives around agents: Copilot canvases provide a durable surface for plans, decisions, progress, and approvals, so work does not disappear into chat history. The post calls out the real trade-off developers are seeing with agentic work: upfront AI credit cost can be higher, but repeated workflows can pay back if the canvas becomes reusable process.

On the execution side, the Copilot app can run multiple agent sessions in parallel by isolating each session with git worktrees, then tracking in-flight tasks on a centralized board. For day-to-day usage, the Copilot app's “My work” pane helps tie agent sessions back to issues and pull requests, and it supports custom views so teams can align the tool with their backlog conventions.

MCP (Model Context Protocol) keeps expanding as the “tooling layer” for agents

Following last week's MCP push around interoperability and packaging (Agent Plugins 1.0) plus hosted endpoints (Azure DevOps Remote MCP Server GA), MCP kept showing up as the common way to attach real tools and governed data access to agents. The week's updates focused on making MCP easier to adopt (less manual wiring), more portable (standard packaging), and more enterprise-friendly (hosted endpoints, access controls, and observability).

MCP Connectors and hosted MCP servers reduce integration overhead

A preview from Azure Integration Services introduced an MCP Connectors canvas extension for the GitHub Copilot app that lets developers connect hosted MCP servers from Azure Connector Namespace without manually configuring endpoints or authentication headers. It also describes user-scoped MCP configuration that works across the Copilot app and Copilot CLI, with security behaviors like secret rotation and access policies designed to reduce “sticky credential” mistakes.

In a related walkthrough, Microsoft showed how Azure Connector Namespace (preview) can host MCP servers and connect them to Azure SRE Agent, reducing the burden of running and securing remote MCP endpoints yourself. The example uses a SQL MCP flow built with Azure Developer CLI (azd) and managed identity authorization, which is the direction many teams want for production: identity-native access instead of long-lived keys.

A portable packaging format for skills and MCP servers: Agent Plugins 1.0

Following last week's focus on standardizing agent packaging for cross-client reuse, Agent Plugins 1.0 proposes a portable package layout for Agent Skills and MCP server definitions that can be consumed by VS Code, Copilot CLI, and other conformant clients. The key implementation detail is separation: a shared, tool-agnostic core with Copilot-only customizations isolated in a namespaced folder, so enterprises can standardize on one package without losing product-specific tuning.

If your team is building internal skills and tool integrations, a portable format matters because it reduces fragmentation between IDEs and surfaces (CLI vs editor vs chat). It also aligns with managed settings and governance models where admins want to approve a single artifact and know exactly what it enables.

MCP meets data platforms: Fabric Warehouses, SQL MCP, and Cosmos DB tooling

Microsoft Fabric announced a preview of a Fabric Data Warehouse MCP Server (remote) plus Skills for Fabric, so MCP-compatible agents can execute T-SQL against Fabric Warehouses and follow Fabric-specific guidance for authoring, querying, and operational diagnostics. The preview highlights Microsoft Entra ID OAuth 2.0 as the authentication model, which is an important signal for enterprise readiness.

On the SQL side, Microsoft continued to position SQL MCP Server (built on Data API Builder and MCP) as a governed way for agents like GitHub Copilot to query SQL Server, Azure SQL, and Fabric SQL Database without granting direct raw SQL access. In parallel, Azure Cosmos DB outlined new developer tooling that brings Copilot into the VS Code Query Editor with schema sampling and consent-based query execution, plus Cosmos DB-specific agent skills and optional MCP support via Cosmos DB Shell and local testing with the Cosmos DB Emulator.

Microsoft Foundry expands agent capabilities (and clarifies architecture choices)

Building on last week's Foundry “build, run, distribute” storyline (Agent Framework, Foundry Agent Service, Harness/Toolboxes, and IQ endpoints), Foundry updates this week were about two things developers routinely struggle with in production agent systems: getting richer capabilities (structured outputs, tool access, connector patterns) and picking the right runtime ownership model (prompt-only vs hosted orchestration you operate and observe).

Claude on Azure gets structured outputs, web tools, and MCP connectivity

Microsoft AI Foundry added five Claude capabilities for Azure-hosted deployments: structured outputs, web search, web fetch, an MCP connector, and tool search. The post includes API examples in Python and TypeScript and calls out production concerns like cost, security, and observability, which is where these features tend to succeed or fail.

The structured outputs feature is especially practical for developers building agents that hand off results to downstream code, because it reduces the amount of brittle parsing you need around “almost JSON” responses. The MCP connector and tool search features fit the broader direction of standardizing tool access, so the agent can discover and call tools without every integration being bespoke.

Prompt Agents vs Hosted Agents: decide by runtime ownership and ops needs

Following last week's focus on day-two operations (durable orchestration, built-in OpenTelemetry traces, and approval gates), Microsoft published guidance for choosing between Prompt Agents and Hosted Agents in Foundry Agent Service, framing it around runtime ownership: who controls orchestration, state, and operations. The takeaway is that prompt-based approaches can be sufficient for simpler flows, but code-based hosted runtimes become necessary when you need enterprise governance, deeper observability, and operational controls that go beyond a single request/response.

This is useful as a planning tool for teams deciding whether to start with “agent in a prompt” prototypes or invest early in an operable runtime. If your requirements include auditing, stateful workflows, retries, and integration with monitoring, the guidance nudges you toward hosted orchestration sooner.

Cost, governance, and enterprise controls for AI tooling

Building on last week's Copilot ops focus (managed settings growth and cost/usage reporting that admins can act on), the conversation is shifting from “how do we enable Copilot?” to “how do we keep it fair, predictable, and auditable?” This week brought practical tips for reducing token burn, plus enterprise controls for enforcing policy across IDEs and collaboration surfaces.

Reduce token usage and keep sessions focused

Two guides focused on lowering Copilot token usage by being intentional about context and tooling. GitHub's walkthrough explains how Copilot Chat uses context and tokens, then demonstrates commands like /context, /init, and /compact (plus copilot-instructions.md) to keep sessions grounded while trimming prompt history.

A separate VS Code-focused guide adds pragmatic tactics like model selection, compressing tool output, cache-friendly workflows, and concise prompting, all framed around usage-based billing. Put together, they reinforce a workflow pattern: treat agent sessions like a resource you manage, not an unlimited chat window.

Budgets, cost centers, and managed settings for enterprises

A governance walkthrough mapped out an end-to-end model for GitHub Copilot billing: seat assignment, cost centers, included AI credit caps, cost-center budgets, and user-level budgets (ULB). This is the kind of operational scaffolding teams need once Copilot use spreads beyond a pilot group and finance wants consistent rules.

On the policy enforcement side, GitHub Copilot for JetBrains added enterprise managed settings so admins can centrally govern plugins and marketplaces, control MCP server access, configure OpenTelemetry, and restrict agent permission modes like Bypass Approvals and Autopilot. Combined with the new Teams/Slack shared session previews (which mention billing controls and extra PR approval options), the direction is clear: collaboration-first agents require admin-first guardrails.

Copilot in the developer workflow: from debugging to modernization

Echoing last week's theme that Copilot value increases when it is embedded into repeatable workflows (not one-off chats), a set of practical tutorials this week showed Copilot being used less as a “chat assistant” and more as a workflow accelerator: generating config, driving modernization checkpoints, and wiring tools into real test and automation loops.

Debugging and day-to-day dev tasks in VS Code

VS Code highlighted a tight workflow for debugging scripts with Copilot: ask it to inspect package.json, then generate a launch.json so you can run scripts under the built-in VS Code debugger. The key value is reducing the friction of remembering debug configuration formats and flags, which helps teams standardize on debuggable scripts rather than ad-hoc terminal runs.

Modernize legacy .NET apps with guided Copilot checkpoints

Visual Studio's modernization experience showcased upgrading a .NET Framework sample app to .NET 10 using guided checkpoints for assessment, planning, and step-by-step execution. The walkthrough calls out common migration work like moving to ASP.NET Core and migrating Entity Framework 6 to EF Core, which are the parts that usually generate the most churn in large codebases.

For teams sitting on legacy line-of-business apps, the practical takeaway is that Copilot's value is highest when paired with a structured workflow (assessment → plan → execute) rather than free-form prompting. That also aligns with canvas-style planning patterns where you can keep decisions and progress visible across iterations.

Tool-augmented Copilot: MCP servers and end-to-end testing loops

Building on last week's MCP interoperability push (plugins and allowlists) and this week's MCP connector/hosting work, several tutorials reinforced the pattern of giving Copilot real tools via MCP, not just asking it to “imagine” outcomes. One session demonstrates extending Copilot with built-in tools and MCP servers, installing the Playwright MCP server, automating a browser session, and switching from Chrome to Microsoft Edge.

Another tutorial applies the same stack to end-to-end testing for a Spring Boot app in VS Code, using Copilot to run Playwright browser tests and then review the tool calls used during validation. This is useful beyond testing: it demonstrates an auditable agent workflow where the “actions” are explicit tool calls you can inspect.

Other Artificial Intelligence News

Following last week's observability and governance push (built-in OpenTelemetry for Azure Functions agents and “Zero Ops” approval patterns), Azure Copilot added direct access to specialized agents (troubleshooting, deployment, optimization, resiliency) and introduced tenant-level controls in the Azure Copilot Admin Center to enable agents without preview allowlisting. This is a meaningful governance step because it turns “which agents can run” into an admin-controlled capability, not a per-user experiment.

On the operations side, Microsoft published patterns for agent observability and downstream automation: using OpenTelemetry traces shipped to Application Insights (with KQL queries for auditing), and extending Azure Monitor issues from the Azure Copilot Observability Agent into Action Groups for Teams notifications (via Logic Apps) and custom routing (via Azure Functions). Separately, a FinOps guide showed how to make token and Copilot spend reportable by building a customer-owned “meter map” from the Azure price sheet and joining it onto FOCUS cost rows for consistent classification.