Weekly ML Roundup: Fabric Governance, RTI Controls, and Agents

by TechHub

This week's ML roundup focuses on making Microsoft Fabric deployments more governable and production-ready, from delegated OneLake shortcuts that tighten zero-copy security across workspaces and tenants to new outbound access controls for Real-Time Intelligence (RTI). On the streaming side, Eventstream connectors picked up practical upgrades like private networking, Kafka and Service Bus support, and mTLS, while preview features point to broader CDC and IoT ingestion coverage. We also saw Fabric move further toward repeatable operations with a public data agent API, GA item recovery with REST restore, and an AI-assisted CLI path for migrating Synapse Spark and pipelines. Outside Fabric, SkillOpt and MCP-based SQL Server tooling both reinforce a shared lesson for agent builders: skills, tools, and permissions are the control plane that keeps agent behavior reliable and bounded.

This Week's Overview

Microsoft Fabric OneLake shortcuts: delegated identity and zero-copy governance

Delegated OneLake Shortcuts entered preview as a new authentication option for Microsoft Fabric that avoids the scaling and governance limits of pure pass-through access, building on last week's “governed one lake plus federated query” thread by tightening how zero-copy sharing actually enforces security across workspace and tenant boundaries. Instead of every downstream consumer needing direct access to the source, delegated shortcuts use a delegated identity model so Fabric can enforce OneLake security consistently when sharing data across workspaces and even across tenants.

This matters if you are standardizing on OneLake shortcuts for “zero-copy” distribution patterns (sharing data without physically duplicating it) but still need reliable enforcement of table- and column-level security. In practice, the preview gives architects another lever for cross-tenant sharing and external storage scenarios where pass-through identity can be hard to manage at scale.

Aaron Merrill's deep dive complements the announcement by walking through how OneLake evaluates permissions for shortcuts, including the difference between passthrough and delegated shortcuts and how intersection-based permission evaluation works. The “intersection” behavior is the key operational detail: effective access is determined by the overlap of permissions across the shortcut path, which can surprise teams if they assume permissions only apply at the source or only at the destination.

Microsoft Fabric Real-Time Intelligence hardening and ingestion upgrades

This week clustered around two themes in Fabric Real-Time Intelligence (RTI): tighter outbound controls at the workspace boundary, and more production-ready ingestion paths for Eventstream. Together they push RTI closer to a default-secure posture while removing friction for common streaming integrations.

Workspace Outbound Access Protection (OAP) expands across RTI experiences (Preview)

Workspace Outbound Access Protection (OAP) is now in preview across Fabric RTI experiences, providing a central way to define what outbound routes are allowed or blocked from a workspace, and it mirrors last week's emphasis on making AI-assisted operations safer by adding a clear, enforceable control plane around where RTI components can call out. The announcement calls out coverage across Eventstream, Eventhouse, KQL QuerySet, Real-Time Dashboard, Activator, and Fabric/Azure Events, which is important because RTI solutions often mix several of these components in one workflow.

For developers and platform teams, OAP is effectively an outbound egress policy layer for RTI that helps prevent accidental data exfiltration or unexpected cross-boundary calls as teams iterate. It is especially relevant if you are consolidating multiple projects into shared workspaces or allowing self-serve RTI creation, where outbound destinations can otherwise sprawl.

Blocking cross-workspace event consumption by default for Azure and Fabric events (Preview)

A related preview applies OAP specifically to Azure and Fabric events in the Real-Time hub, changing the default posture for cross-workspace event flows as a practical follow-through on the governance-first Fabric direction we covered last week. Cross-workspace event consumption is blocked by default unless you explicitly allow the Real-Time Events connector via data connection rules, which makes these event routes behave more like controlled integrations than implicit trust relationships.

If your organization uses multiple Fabric workspaces to separate environments (dev/test/prod) or teams, this change is a practical guardrail. It also means you may need to update rollout checklists: event-driven solutions that previously “just worked” across workspaces might now require explicit allow rules before they can consume events.

Eventstream connectors: private networking, Kafka/Service Bus, and mTLS go GA; more previews land

Fabric Eventstream connectors added several generally available capabilities that reduce the gap between prototype streaming and production deployments, extending last week's real-time + AI Skills examples with the connectivity and transport-security features teams typically need before they can standardize ingestion. The update highlights GA private network support, GA Kafka and Azure Service Bus connectors, and GA support for custom CA and mTLS, which is a practical checklist for teams that need controlled connectivity and stricter transport security for ingestion.

On the preview side, Eventstream is adding workspace identity authentication for Event Hubs, richer IoT Hub metadata, Oracle CDC ingestion, and HTTP pagination. Taken together, these previews point toward fewer bespoke ingestion services: you can standardize more streaming and change-data-capture sources directly into RTI, then layer governance and outbound controls (like OAP) on top.

Fabric automation and lifecycle tools: public data agent API, item recovery, and AI-assisted Synapse migration

Fabric also shipped a set of changes aimed at operational maturity: automating agent setup via API, recovering deleted items with configurable retention, and accelerating migration from Synapse with AI-assisted CLI tooling. The throughline is reducing reliance on click-ops in the portal while improving safety nets and repeatability.

Fabric data agent API becomes public for REST/SDK-driven workflows

The Fabric data agent API is now public, enabling teams to create, configure, update, and publish Fabric data agents programmatically using the Fabric REST API and SDK, and it picks up directly from last week's “agents, skills, and evaluation” thread by making agent rollout and configuration something you can actually standardize in CI/CD. That opens the door to treating agents as deployable artifacts in your pipelines instead of one-off portal resources, which is useful if you are managing multiple environments or stamping out consistent configurations across workspaces.

Because the announcement explicitly positions this for building Fabric data agents into external tools and pipelines, it should fit naturally into infrastructure-as-code style practices, even if the implementation is REST calls and SDK usage rather than a single declarative template. If your org is experimenting with MCP (Model Context Protocol) or other agent frameworks, having a supported API surface for agent lifecycle management is a step toward more controlled rollouts.

Item Recovery reaches GA with recycle bin and REST restore support

Item Recovery in Microsoft Fabric is now generally available, adding a Workspace Recycle bin and restore capabilities via REST API for supported deleted items, which complements last week's push toward more operable production workflows by adding a concrete safety net for high-churn workspaces. Tenant admins can configure retention up to 90 days, which turns accidental deletions from an incident into a routine restore, especially in high-churn workspaces.

The REST API angle is the operational win for larger teams: you can build automated recovery workflows, integrate with internal tooling, or at least document a repeatable restore process that does not depend on a single admin's portal access. It also pairs well with broader governance work, since retention policies become another tenant-level control to standardize across business units.

AI-assisted Synapse Spark and pipeline migration from the command line (Preview)

A preview of AI-assisted command-line migration skills aims to move Azure Synapse Spark artifacts and Synapse pipelines into Microsoft Fabric with guided phases, automatic refactoring, and a migration report that detects blockers, continuing last week's theme of “make ops and changes safer” by packaging migrations as repeatable, report-driven runs instead of one-off manual projects. For teams planning a phased migration, the “blocker detection” and report output are as important as the refactoring itself, since they help you prioritize what must change before cutover.

The CLI-based approach also suggests a more repeatable migration process than one-time portal wizards, which matters when you have multiple Synapse workspaces or need to run dry runs across environments. Because the tool targets both Spark and pipelines, it is positioned for end-to-end workload moves, not just notebook translation.

Other Machine Learning News

Microsoft Research described SkillOpt, a method for improving an AI agent by treating its natural-language “skill” file as a trainable parameter and optimizing it through bounded text edits using trajectory feedback plus validation gating, which reads like a research analogue to last week's enterprise agent learning loops (measurable feedback, gated iteration) but applied at the skill layer rather than via model fine-tuning. The takeaway for builders is a concrete recipe for making agent behaviors more reliable and transferable without fine-tuning, by iterating on compact skill artifacts under automated evaluation.

Separately, a Data Exposed MVP Edition episode showed how to give GitHub Copilot controlled visibility into SQL Server using MCP servers, including a custom DMV-based toolset for operational insights and a Data API Builder approach for application data with permissions defined in configuration, extending last week's MCP-based agent patterns beyond analytics engines into database operations with explicit permission boundaries. If you are experimenting with agents in production environments, both pieces reinforce the same pattern: treat the agent's context surface area (skills, tools, and permissions) as the real control plane.