Weekly AI Roundup: Governed agents, local models, and TokenOps

by TechHub

This week's Weekly AI Roundup focuses on what it takes to run agents like real software: governed tool access, enforceable runtime boundaries, and measurable cost and quality. GitHub Copilot expanded practical model choice (including Claude Haiku 5.5), brought MXC-powered local sandboxing to GA, and added tighter enterprise controls for JetBrains, code review billing, and usage metrics. On Azure, the story moved toward durable execution and production integrations with Dynamic Workflows, Python agent bindings, and managed connectors, backed by tracing patterns in Foundry and OpenTelemetry-based TokenOps. Security and evaluation rounded out the week with a purpose-built secret detection model, new lessons from AI-assisted vulnerability research, and shared benchmarks and playbooks (ReviewBench and the Agent Experience approach) to make agent behavior testable and improvable.

This Week's Overview

GitHub Copilot: More models, tighter sandboxing, and enterprise controls

Faster model choice and usage controls

Building on last week's expansion of “model choice as policy” across Copilot surfaces (with more top-tier options and admin-managed model policy), GitHub Copilot added Claude Haiku 5.5 as a generally available option, positioned for fast, high-volume coding tasks where latency and token/step usage matter. For teams on usage-based pricing, this gives a practical “cheap and quick” model choice alongside heavier models, with admin control via Copilot model policy so enterprises can limit where it can be used.

On the CLI side, Copilot CLI v1.0.94-0 adds local model discovery from a running Ollama instance via /model, including an in-CLI picker that can add and optionally switch models without restarting. The release also clarifies how offline mode behaves and improves telemetry and provider connection error reporting, which matters when you're trying to make “local-first” workflows predictable for developers.

Local sandboxing goes GA (MXC) and on-device coding expands on Windows

Following last week's local sandboxing public preview in the Copilot app (and the broader theme of “agents as production software” with enforceable boundaries), local sandboxing for Copilot is now generally available across Copilot CLI, the Copilot app, and VS Code Agent Host sessions, powered by Microsoft eXecution Container (MXC). This is the clearest signal yet that “agentic” developer tooling is being treated like production automation: you can apply policy-based restrictions to limit what tools can touch (files, network, credentials) on developer machines, and enforce those policies at the enterprise level.

Microsoft also announced Copilot support for on-device AI coding on new Windows PCs, including automatic routing between local and cloud inference and a local MAI Code 1.1 Flash model build. Combined with MXC sandboxed tool execution, the story is shifting from “agents must be cloud-hosted” to “some tasks can be local, cheaper (zero AI credits), and still controlled,” especially for offline use or sensitive repos.

IDE and org governance: JetBrains updates, code review billing, and metrics attribution

Continuing last week's JetBrains control-surface improvements (tool approvals, per-tool controls, and tighter MCP governance), Copilot for JetBrains shipped a set of enterprise-friendly controls: admins can set enterprise-managed default agent models, developers get a diagnostics “Fix” action that opens inline chat, and there's now an option to disable automatic MCP server startup. The release also tightens compatibility expectations by deprecating JetBrains IDE 2025.1 support (moving teams to a 2025.2 baseline), which is relevant if your org pins IDE versions.

On the governance and cost side, Copilot code review gained org billing controls that decide whether review requests consume a member's Copilot entitlement or the organization's AI Credits budget. There's also a new policy to restrict review requests to users licensed through the org/enterprise, which helps avoid “shadow usage” when external collaborators trigger billable behavior.

GitHub also called out a metrics attribution issue where Copilot SDK-based agent sessions weren't correctly identifying their IDE, leading to undercounted agent activity in usage metrics. The fix requires updating to specified IDE versions, and the note that historical gaps cannot be backfilled is important for teams using adoption/usage metrics for chargeback or rollout tracking.

MCP and agent governance: From capability discovery to runtime enforcement

This week connected the dots between “how agents discover tools” (MCP) and “how enterprises control tool use at runtime” (API gateways, policy, and threat protection). The common thread is moving agent integrations out of ad-hoc IDE settings and into governed infrastructure.

MCP basics and developer workflows

Following last week's emphasis on MCP controls inside IDEs (especially JetBrains per-server and per-tool governance), the practical takeaway is that MCP (Model Context Protocol) formalizes how a model or agent discovers tool capabilities, and it supports both local and remote MCP servers. That matters because it enables repeatable “agent can use these tools” setups across editors, CI-like agent hosts, and production agent runtimes.

On the developer experience side, Copilot updates are making MCP less implicit and more controllable (for example, JetBrains now lets you disable automatic MCP server startup). Tutorials are also starting to treat “turn app features into tools” as a standard workflow, like building a Spring Boot feature in VS Code, exposing it via MCP, then testing the agent-tool loop with Playwright.

Microsoft Agent 365 + Azure API Management: governing MCP tool access at runtime

Building on last week's theme of moving from “MCP everywhere” to enforceable guardrails (identity, policy, and network egress controls), Microsoft announced a public preview integration between Microsoft Agent 365 and Azure API Management to govern and enforce access to MCP servers and tools at runtime. Conceptually, this treats MCP tool calls like any other API call you would protect with an API gateway: you can control authentication, authorization, and policy enforcement centrally rather than depending on each client.

The integration also layers in optional tool threat protection using Microsoft Defender and Microsoft Purview, which is a signal that “agent tool use” is being treated as a security boundary. For developers, the implication is that building MCP servers is likely to start looking more like building internal APIs: you will need clear contracts, identity, logging, and policy-driven access controls from day one.

Building and operating agentic systems on Azure: durable plans, connectors, and traceability

Dynamic Workflows in Azure Functions Hosted Skills (preview)

Following last week's push toward routinized, auditable execution in agent platforms (for example scheduled and event-based runs with history), Azure Functions Hosted Skills introduced Dynamic Workflows in preview: an LLM generates a typed DAG (directed acyclic graph) plan once, then Durable Functions executes it durably with retries, timers, and observability via Durable Task Scheduler (DTS). This is an explicit design shift away from “LLM decides every step in a loop” toward “LLM plans, deterministic runtime executes,” which reduces tokens and latency for fan-out/fan-in workflows.

The runtime design calls out safety validation and tool/sub-agent patterns, and it leans on durable execution semantics (idempotency guidance and at-least-once behavior) that backend engineers already understand. If you've struggled with fragile, expensive multi-turn agents, this is a concrete path to keep LLM reasoning bounded while still supporting dynamic workflow shapes.

Azure Functions Agent bindings for Python (preview)

Building on last week's Agent Framework focus on resilient execution and clearer runtime boundaries, Azure Functions also added Agent bindings for Python in preview, built around Microsoft Agent Framework, so you can embed bounded agentic reasoning while keeping your deterministic function code in control. The guidance includes end-to-end examples for HTTP-triggered functions and Durable Functions orchestrations, plus local run steps and samples to start from.

For teams standardizing on Python for automation, this offers a more structured alternative to rolling your own agent loop inside a function. It also fits cleanly with MCP-based tool ecosystems, since the binding approach can sit alongside tool calling while still enforcing runtime constraints and predictable error handling.

Managed connectors for Azure Functions (public preview)

Continuing last week's theme that production agents need real integration primitives (not just prompts and bespoke wrappers), Azure Functions managed connectors (via Azure Connector Namespace) landed in public preview, giving functions access to connector triggers and typed clients across around 1,700 services. The .NET isolated worker example (processing SharePoint-uploaded RFPs with Azure AI Content Understanding and posting an Adaptive Card to Teams) shows the intended pattern: event comes in, content is extracted, then a workflow action is taken in a business system.

For agentic apps, this matters because connectors reduce the amount of bespoke integration code you have to expose as tools. Instead of writing and maintaining one-off wrappers, you can rely on standardized connectors and typed clients, which can improve reliability and reduce the surface area for security review.

A production-minded intake architecture: API Management + events + correlation IDs

Following last week's emphasis on auditability and end-to-end observability (from OpenTelemetry in Copilot sessions to Foundry tracing), Microsoft published a reference architecture for document-heavy intake pipelines that treats API Management as both a governed front door and an AI gateway. The design combines Logic Apps, Service Bus (including dead-lettering), Functions, Document Intelligence, Foundry models, and Event Grid with CloudEvents, and ties everything together using a single correlation ID for traceability.

The concrete operational detail to copy is the correlation ID strategy: agents and AI calls often fan out across tools, and without end-to-end IDs you end up with “works on my machine” debugging. If you're building regulated or high-volume intake, this architecture is a useful starting point for getting governance, observability, and failure handling right early.

AI costs and observability: measuring token economics and debugging agent runs

Running large models on Spot and instrumenting the full stack

Building on last week's push to treat agent sessions like production workloads with OpenTelemetry-backed observability, a hands-on guide explored running Qwen3.8-27B on an Azure H100 Spot VM (reported as ~$2 pricing in the example) using vLLM and LiteLLM, then instrumenting the stack with OpenTelemetry into Azure Monitor/Application Insights. The key point is not just “it runs,” but that you can quantify real token economics vs compute cost and visualize it in Azure Managed Grafana, which is what you need to decide whether Spot-based hosting actually saves money for your traffic patterns.

For teams considering self-hosting, the instrumentation approach is the takeaway: push OTLP spans/metrics/logs into the same system where you already debug services, and treat model serving like any other production dependency. Without that, “cheap GPU” experiments tend to become reliability surprises.

Tracing slow/wrong agent runs in Azure AI Foundry

Following last week's throughline that auditability requires both enforceable controls and telemetry (for example sandboxing plus trace export), a troubleshooting walkthrough showed how to debug slow or incorrect agent runs by enabling server-side tracing in Azure AI Foundry via Application Insights. Once traces are flowing, you can inspect model/tool spans and query recurring issues with KQL (Kusto Query Language), which turns “the agent felt off” into something you can actually triage.

This is a useful pattern even if you are not on Foundry: agentic systems fail across boundaries (model calls, tool calls, retries, timeouts), so you need distributed tracing and a repeatable way to identify which step regressed. If you already use Application Insights, this gives you a direct path to integrate agent runs into existing operational dashboards.

Secret detection and AI security: purpose-built models and operational lessons

GitHub Secret Protection expands with a fine-tuned detection model

Building on last week's security reality check (token theft campaigns and why least privilege needs to be the default), GitHub rolled out a purpose-built, fine-tuned model for context-aware leaked secret detection across secret scanning alerts, push protection, and GitHub Copilot /security-review. The practical change is broader and more accurate coverage for “unstructured secrets” (the messy real-world cases that regexes miss), with clear separation between what checks are included vs what consumes GitHub AI Credits, plus admin controls to budget and manage usage.

A companion post argues that secret exposures are scaling with the volume of code pushed and highlights GitHub's move to a fast ModernBERT-based classifier for push protection expansion. The message for developers is that secret protection is becoming more proactive and more integrated into the places you work (push time and Copilot surfaces), so you should expect fewer “it slipped to main” incidents but also more policy conversations about credit usage and enforcement on GHES/GHEC.

Scaling AI-assisted vulnerability research: reproducibility and cost trade-offs

Following last week's focus on agentic attacks and defensive detections (and the need for measurable, repeatable response), Microsoft Security's FORGE Lab shared three operational lessons from frontier AI vulnerability research: focus on reproducible evidence, manage reasoning-cost trade-offs, and build a continuous validation/remediation loop that turns findings into shipped fixes across Windows and open source. The framing is important because it treats AI not as “one more scanner,” but as a system that needs calibration and feedback loops to avoid wasting effort on false positives or expensive reasoning paths.

A related CISO-focused post connects that idea to vulnerability management practices, recommending changes in patching, triage, and defense-in-depth, and calling out techniques like AI “harnesses” (including MDASH) plus Baseline Security Mode and secure-by-default controls. Even if you're not a CISO, the developer implication is that more vulnerabilities will be found earlier and in greater volume, so product teams should invest in faster validation pipelines and safer defaults to keep remediation throughput realistic.

Agent quality and evaluation: benchmarks and “Agent Experience” as an engineering practice

ReviewBench: an open benchmark for AI code review agents

Building on last week's push to make Copilot measurable (including PR review stage metrics and more configurable code review effort), GitHub introduced ReviewBench, an open offline benchmark for AI code review agents built from representative GitHub pull requests, multi-source ground truth, and calibrated evaluation metrics. The distinction between grounded vs augmented scoring is a practical one: it separates “did the agent review what was actually in the PR” from “did it add helpful extra context,” which helps teams measure improvements without rewarding hallucinated-but-plausible feedback.

If you're building or buying AI code review, this creates a shared way to evaluate changes and publish results on a leaderboard. It also provides a clearer contract for internal experimentation, because you can run offline evaluations against consistent PR sets before you ship a new model, prompt, or tool integration to your developers.

Agent Experience (AX) Playbook: diagnosing why agents fail with your tech

Continuing last week's evaluation-driven governance theme (measure failures, apply controls, rerun tests), Microsoft published the Agent Experience (AX) Practitioner Playbook, a repeatable method for evaluating how AI coding agents use a technology, diagnosing common failure patterns, and validating fixes in docs, MCP tools, plugins, CLIs, and APIs. The related AX explainer frames evaluation in terms of propensity (will the agent discover and attempt to use your integration) vs efficacy (will it use it correctly), and it emphasizes tracking both quality and task cost.

The immediate use case is for teams maintaining platforms or SDKs: if agents keep misusing your API or failing to find the right command, you now have a structured way to reproduce the behavior and link it back to something you can ship (documentation changes, better errors, improved tool schemas). The playbook also introduces an “AX Practitioner” skill to guide teams through the evaluation process while they run it, which can help standardize how different orgs measure agent readiness.

Azure AI and data platforms: choosing document tech, Ray on Azure, and governed business grounding

Document extraction choices: Document Intelligence vs Content Understanding

Following last week's intake and manufacturing architecture examples that stressed “messy inputs, structured outputs, and evaluation,” a practical comparison broke down where Azure Document Intelligence and Azure Content Understanding overlap (OCR/layout) and where they diverge in approach. The main decision point is whether your workload is best served by purpose-trained document models for extraction or generative, schema-based extraction that can flex with unstructured content and multimodal scenarios.

For developers building RAG (retrieval-augmented generation) or intake pipelines, this guidance helps avoid a common failure mode: treating document parsing as a solved problem and then discovering late that accuracy and evaluation metrics do not match business outcomes. The post also connects the choice to evaluation criteria, which is useful when you need to justify model selection beyond “it looks good on a few samples.”

Anyscale on Azure reaches GA for Ray on AKS in your subscription

Building on last week's AKS-and-governance direction for running AI workloads safely at scale, Anyscale on Azure is now generally available, providing an Azure-native way to run Ray on AKS in the customer subscription while Anyscale operates the control plane. The integration leans on Azure governance and identity primitives (ARM, Azure Policy, Entra ID, RBAC) and supports private connectivity, which matters for enterprises that want distributed ML/AI workloads without punching holes in network policy.

For teams already using Ray, the GA milestone reduces the operational burden of building and securing a multi-tenant Ray platform from scratch. For teams evaluating Ray, this positions it as a more “cloud-governed” option on Azure, where cluster lifecycle and access control can align with the same policies you use for other platform workloads.

Microsoft Fabric maturity and grounding agents in governed semantics

Continuing last week's thread that production agents need durable, governed context (not just bigger models), a FabCon 2026 recap highlighted Fabric IQ as a way to ground Copilot and agents in governed business semantics, alongside new on-demand compute options and stronger monitoring/governance capabilities. The theme is that “data platform maturity” is becoming a prerequisite for reliable enterprise agents, because agents need consistent definitions (metrics, entities, semantic models) to avoid conflicting answers across teams.

If you're trying to connect agents to business workflows, this reinforces a practical sequencing: get the semantic layer and governance right (for example, via OneLake and semantic models), then wire agents and tools on top. Without that, retrieval and grounding tend to amplify organizational inconsistency rather than reducing it.

Other Artificial Intelligence News

Several items this week focused on “agents in real apps” and the developer workflows around them, from UI components to spec-driven development patterns and hands-on demos that show how teams actually build with these tools.