Weekly AI Roundup: Governed Gateways, Production Agents, Metrics

by TechHub

This week's AI roundup centers on a clear operational shift: centralize access, authorization, and auditability as agents move from demos into real systems. Azure API Management and Foundry's AI Gateway control plane show how teams can enforce token limits, routing, and telemetry, while MCP's enterprise-managed authorization patterns tighten end-to-end tool access using Entra ID and App Service auth. On the engineering side, stable Agent Skills for Python, long-running MCP tools on Azure Functions, and richer MCP outputs push agent tooling toward repeatable, debuggable workflows. Copilot and security updates round it out with repo-level usage metrics, more configurable code review, AI-powered code scanning detections, and agentic autofix that make cost, policy, and least-privilege design part of everyday development.

This Week's Overview

Governed AI gateways and authorization for enterprise agents

A clear theme this week was moving from “AI endpoints everywhere” to centrally governed access, with Azure API Management (APIM) increasingly positioned as the enforcement point for token limits, routing, and auditability - a direct continuation of last week's push for enterprise guardrails (managed settings, spend controls, and audit-grade telemetry) as agentic tool use spreads beyond chat. Microsoft Foundry now includes an AI Gateway control plane that can create or associate an APIM AI Gateway directly from the Foundry admin console, which means teams can apply project-level token limits and governance without moving the data path out of APIM. For App Service-hosted agent architectures, the practical split is important: Foundry handles the project-level wiring and policies it owns, while advanced APIM configuration still lives in APIM itself.

On the authorization side, MCP (Model Context Protocol) is getting a more enterprise-friendly story with the stable MCP Enterprise-Managed Authorization (EMA) extension, plus a contrasting pattern that uses Microsoft Entra ID preauthorization and Azure App Service Authentication - building on last week's MCP trust and tool provenance focus by moving from “which tools are safe” to “how tools get authorized and audited end-to-end”. The guidance gets concrete with an App Service FastAPI MCP server and a local lab that demonstrates the ID-JAG exchange using RFC 8693 (token exchange) and RFC 7523 (JWT bearer), which is the kind of detail you need if you are trying to standardize agent-to-tool access in regulated environments.

The broader architecture guidance reinforces the same direction: use APIM to centralize access to Azure AI Foundry and Azure OpenAI, emit token metrics into Azure Monitor/Application Insights for chargeback and budget alerts, and pair it with edge controls like Azure Front Door + WAF for defense in depth. One of the more actionable patterns described goes further by enforcing per-consumer entitlements, budget-based model downgrades, and streaming token metrics into Application Insights, with a Terraform walkthrough and even examples of routing GitHub Copilot Chat and Copilot CLI through the governed gateway.

Production agent engineering: skills, tools, and long-running workflows

This week's agent content leaned into production mechanics: how you package capabilities, bind tools safely, and make workflows resilient when they run longer than a single request/response. Across Microsoft Foundry, Microsoft Agent Framework, and MCP, the focus was less on “can it demo?” and more on “can it run, be upgraded, be governed, and be debugged?”

Agent Skills for Python reaches stable release

Agent Skills for Python in Microsoft Agent Framework is now stable and positioned as production-ready, with a defined skill packaging format and a progressive disclosure loading model (so agents load what they need rather than everything upfront), which follows last week's emphasis on turning ad hoc tool use into standardized, governable building blocks. The release also calls out governance controls, including human-in-the-loop approval and constraints around script execution, which matters if you are turning “tools” into shared enterprise assets. The announcement includes a Python example using FoundryChatClient with Azure identity credentials, plus pointers to specs, docs, and samples to standardize how teams publish and consume skills.

Built-in Agent Skills arrive in Visual Studio 18.8

Visual Studio 18.8 adds built-in Agent Skills that effectively ship reusable Copilot capabilities for common .NET and Azure work, instead of each team reinventing prompts and playbooks - a natural follow-on to last week's IDE push around token tracking and MCP server trust validation by making “what agents can do” more consistent and easier to govern in the editor. The examples span API endpoint work, performance review, Azure deployment chains (including azd), infrastructure flows with Bicep and Terraform, Kusto (KQL) querying, and Microsoft Foundry tasks, which suggests Microsoft is treating skills as a first-class distribution mechanism. If your org already maintains internal runbooks, this is a signal to start mapping them into skill-shaped assets so they can be reused consistently and governed like code.

Long-running MCP tools on Azure Functions with the MCP Tasks extension

MCP tool calls are often synchronous today, which breaks down when a tool needs minutes rather than seconds (builds, data jobs, provisioning, or batch processing). Following last week's Durable Functions “stopgap” pattern for long-running MCP tools, the updated guidance introduces the MCP Tasks extension and a Durable Functions pattern that keeps compatibility with today's request/response MCP clients while still supporting long-running work. The samples in Python and .NET are especially relevant if you are exposing operational tools to agents and need predictable completion, retries, and state management.

Returning richer outputs from MCP servers (images and interactive apps)

Tool output is not limited to text, and this matters for agent UX inside IDEs where developers want artifacts, not paragraphs - building on last week's Copilot Vision and browser tooling expansion by pushing multimodal outputs through the MCP tool boundary itself. A Python FastMCP server example shows returning binary image results and interactive MCP apps, integrating Azure AI Search and Azure Blob Storage, and consuming the results from GitHub Copilot in VS Code. For teams building internal tools, this expands what “tooling” can look like: dashboards, previews, and visual outputs that are still governed by the same tool boundary.

Foundry agent building goes community-first (round tables and a structured course)

Microsoft continues to push practical enablement around Foundry-based agents, with Discord round tables on two concrete areas: browser-capable agents using the Browser Automation Tool (BAT) and scaling production agents using Foundry Toolbox, Skills, and Tool Search - effectively the “how do we adopt this safely” counterpart to last week's GA browser tools and broader tool-use governance trend. Both events emphasize the same guardrails - oversight, isolation, and observability - which mirrors the broader shift toward governed agent operations.

Separately, a seven-lesson course lays out a full path from prototype to production using Microsoft Agent Framework and Microsoft Foundry, including multi-agent design, evaluation, hosted deployment, data sovereignty via capability hosts, and centralized tool governance with Foundry Toolbox. If you are trying to standardize “how we build agents here,” this is closer to an operating playbook than a feature demo.

GitHub Copilot and AI-assisted development: governance, customization, and measurement

This week tightened the loop between AI-assisted development and the things teams actually need to run it at scale: measurable adoption, configurable review behavior, and clearer model and integration options across IDEs and mobile. The updates also show GitHub steering Copilot toward being an auditable part of the SDLC, not just a developer convenience.

Copilot usage metrics expand from org-level to repo-level detail

GitHub added GitHub Copilot app activity to the usage metrics API, so enterprise and organization 1-day and 28-day reports now include daily active users and more granular totals for sessions, requests, prompts, and tokens - extending last week's metrics improvements and agent session streaming theme into more actionable “where is this used” visibility. In parallel, repository-level Copilot usage metrics are now generally available via REST API endpoints that provide daily per-repository pull request activity for Copilot coding agent and Copilot code review. For platform teams, this enables chargeback/showback, targeted enablement (which repos are using what), and better governance conversations based on real usage rather than anecdotes.

Copilot code review gets more configurable and more “enterprise-shaped”

Copilot code review added multiple controls that make it easier to standardize behavior across repositories while still allowing repo-specific intent, which builds on last week's medium-depth review preview by adding the configuration surface you need to operationalize review policies. Custom instructions are now read from the PR head branch, more instruction file names are supported, and repositories can define setup steps via copilot-code-review.yml (useful when tests, generators, or build steps are required for meaningful review). Reviews also now run behind a configurable default-on firewall, and organization runner settings are split from Copilot cloud agent so you can pick runner types independently.

GitHub Mobile now closes a practical workflow gap by adding “Fix with Copilot” directly from Copilot code review PR comments on iOS and Android, accessible from both the PR main view and individual review comments. This turns Copilot review feedback into a tighter loop when you are triaging on the go.

Model choice and BYOK options broaden across IDEs

Copilot for JetBrains expanded bring-your-own-key (BYOK) capabilities to support OpenAI-compatible custom endpoints, added richer plugin-based customizations, and introduced Claude provider support for custom agents in preview - continuing last week's model picker churn and “governed vs BYOK” tension by widening the set of endpoints teams will need to manage. The same update mentions local sandboxing and Copilot CLI debugger skill improvements (both in preview), which will matter if you are trying to keep agent execution more controlled on developer machines.

On the Visual Studio side, updates focus on helping developers pick and manage Copilot models by comparing capabilities like context window size and vision support, and monitoring context window and plan usage during longer chats. A separate Visual Studio Copilot update also calls out usage tracking and alerts for usage-based billing, trust validation for MCP servers, GA for C++ modernization agent scenarios, and tighter PR workflows with Copilot Chat, which collectively points to Copilot becoming more operationally visible inside the IDE.

Copilot meets Jira, and “skills libraries” get overdue maintenance advice

GitHub shared a quick setup walkthrough for the Copilot for Jira integration: install from the Atlassian Marketplace, authorize GitHub (including SSO considerations), enable orgs, and create a draft pull request directly from a Jira work item. For teams trying to reduce “context switching tax,” this is a lightweight path to connect ticket context to code changes without building custom glue.

At the same time, a practical warning landed for teams building up Copilot “skills” folders: they tend to accumulate broken entries and duplicates across tool-specific folders, and those failures can be silent - a useful counterpoint to last week's push toward centrally managed settings by highlighting that “configuration as code” only works if the code gets maintained. The proposed stocktake checklist and shell one-liners to find missing SKILL.md files and duplicates are a good reminder to treat skill libraries like codebases that need CI, ownership, and periodic cleanup.

AI security and supply chain: scanning, autofix, and least-privilege agent design

Security updates this week show AI being used in two directions at once: improving detection and remediation in developer workflows, and tightening the security model around agents that can take actions. The practical takeaway is that AI-driven capability is expanding, but so is the need to control identity, access, and audit trails.

GitHub code scanning adds AI detections on PRs and agentic autofix

GitHub code scanning now shows AI-powered security detections directly on pull requests, expanding coverage beyond CodeQL-supported languages and frameworks. The feature is in public preview for GitHub Advanced Security customers and uses AI credits with a GitHub Copilot license, so teams should consider budgeting and policy upfront before enabling broadly.

Agentic autofix for code scanning alerts is also in public preview, where Copilot explores the repository, generates and validates fixes by rerunning CodeQL, and opens a draft pull request - extending last week's theme of agents acting in CI with stronger auditability and spend controls into the security pipeline itself. Triggering is available through multiple paths (including the REST API), and billing spans both AI Credits and GitHub Actions minutes, which makes it important to align usage with runner strategy and security workflow expectations.

On-demand security reviews in the Copilot app

The GitHub Copilot app now has a /security-review slash command in public preview that runs an on-demand security review of in-flight code changes, returning prioritized findings and suggested fixes - a natural complement to last week's medium-depth review direction by applying “deeper reasoning” to security checks earlier in the workflow. It is positioned as a lightweight check that complements code scanning, Dependabot, and secret scanning, which can fit well in early development before a full pipeline run. For teams, the key is deciding where this fits in policy: as a developer self-check, a PR requirement, or an optional coaching tool.

Least privilege for AI agents, plus SQL Server 2025 outbound AI connectivity controls

Microsoft published a least-privilege model for AI agents that emphasizes dedicated agent identities, task-scoped RBAC, safe tool allowlists, and end-to-end audit logging, explicitly calling out prompt injection risk and the need to reduce blast radius - directly building on last week's MCP tool poisoning guidance by turning the mitigations into an explicit identity-and-access blueprint. The guidance aligns with the direction of MCP authorization work and governed gateways: treat tool access as a security boundary, not a convenience.

SQL Server 2025 outbound AI connectivity features are now generally available with a strong emphasis on secure enablement of external REST invocation and external model objects. The guidance highlights permissioning, authentication, endpoint restrictions, and SQL-native monitoring via SQL Server Audit and Extended Events, which is critical if database workloads start making AI calls that could otherwise become invisible egress.

Black Hat focus: supply chain attacks and Copilot-assisted defense workflows

Microsoft previewed its Black Hat USA 2026 presence with a focus on defending trust in the face of AI and supply chain attacks, including ongoing npm campaigns and GitHub-focused detection research - continuing last week's framing that once agents can act, the supply chain problem shifts from model output to tool and dependency integrity. The post also points readers to hands-on skilling resources across Microsoft Defender, Microsoft Sentinel, and Microsoft Security Copilot, which signals continued convergence between SOC workflows and developer platform telemetry.

Cost, observability, and evaluation for agents in real environments

Teams keep hitting the same wall with agents: it is easy to generate output, but expensive to validate, operate, and measure it reliably. This week had unusually practical guidance on what costs money (and why), how to instrument usage, and how to run evaluations that do not collapse under variance.

Billing clarity for the Azure Copilot Observability Agent

Azure Monitor now has clearer guidance on how billing works for the Azure Copilot Observability Agent, including how Azure Agent Credits (AAC) apply and what types of interactions cost what today (chat, deep investigations, and autonomous operations). The post also explains where usage appears in-product and in Azure Cost Management, which helps platform owners build alerts and budgets before rolling the agent out to a large operations group - a parallel to last week's Copilot AI credit pools and per-user budget controls, but on the Azure operations side. If you are trialing autonomous operations, the key operational change is that “more capability” now implies a more explicit cost model you need to manage.

Evaluating agents without paying for real APIs, and building AX evals that hold up

Testing agent skills against real APIs is costly and non-deterministic, especially when rate limits, changing data, and transient errors skew results. A Dev Proxy-based approach lets you emulate API responses locally while keeping production URLs unchanged, which is useful when you want repeatable tests without rewriting client code or setting up complex mocks per service.

For teams trying to measure “agent quality” rather than “one lucky run,” guidance on building reliable Agent Experience (AX) evals focuses on representative prompts, precise pass/fail/skip criteria, calibrating LLM judges, and repeated runs to separate variance from real improvements - a continuation of last week's “prove what happened” direction, but applied to quality gates instead of audit logs. Taken together, these posts push evaluation toward the same discipline as performance testing: controlled inputs, repeatability, and clear acceptance gates.

Load testing Copilot Studio agents with realistic multi-turn traffic

A concrete performance testing pattern landed for Copilot Studio agents by simulating multi-turn Direct Line conversations over HTTP and WebSockets with Locust, then running the same workload in Azure Load Testing. The walkthrough includes Key Vault-managed secrets, multipart file upload support, and baseline latency results from a 30-minute cloud run, which gives teams a starting point for capacity planning beyond single-turn “hello world” tests. If you are shipping customer-facing agents, the key operational shift is to treat multi-turn conversation state and back-end tool latency as first-class load testing variables.

The economics of AI-assisted changes: generation is cheap, ownership is not

An engineering perspective from GitHub argues that AI-assisted coding changes the economics of small feature requests: generating a first patch can be cheap, but validating, reviewing, testing, and owning the change remains expensive - which fits neatly with last week's emphasis on spend controls and auditability by explaining why governance work does not go away when generation gets easier. The suggested practice is to replace long scope debates with constrained “price check” patches that include a real diff and tests, so teams can make decisions based on evidence rather than speculation. In practice, this fits well with agent-assisted workflows as long as teams keep tight boundaries around authorization, feature flags, and test coverage.

Other Artificial Intelligence News

Visual Studio Code 1.129 continues the migration toward a more explicit agent architecture, including Agent Host Protocol (AHP), changes to the Agents window, and guidance on migrating prompt files into skills, which reinforces the broader shift to reusable, governable agent capabilities. VS Code also highlighted “local-first” options with Language Model Providers and Ollama, plus a small workflow tip on sharing the Integrated Browser with Copilot to provide running-app context during development.

Microsoft published additional platform-level context work: the IQ Platform (Work IQ, Fabric IQ, Foundry IQ) frames how Microsoft plans to add organizational context via OneLake-backed data foundations, ontology models, and managed RAG-style retrieval, ranking, citations, and memory. On the data side, Fabric Eventstreams updates (2026 Q2) included GA Kafka and Service Bus connectors, a GA SQL operator with event-time processing and testing, and new AI Skills to generate and deploy eventstream topologies via REST APIs with Git-based version control.

Several deeper builds and learning resources also landed: a reference implementation for giving agents short-term and durable memory on Azure App Service (Redis + Cosmos DB vector search with managed identity and azd/Bicep deployment), an autonomous Teams-driven multi-agent “prototype factory” using OpenClaw + MCP inside Hyper-V-isolated Azure Container Apps dynamic sessions, and a free course that modernizes a legacy ASP.NET app to .NET 10 using the Copilot modernization agent and deploys to Azure App Service. There were also community/tutorial items on adding OpenTelemetry tracing to a .NET agent harness and implementing tool approval loops with Ollama, plus a case study showing how Copilot helped GitHub ship an accessibility fix in PRs by navigating unfamiliar code.