Microsoft’s IQ Share moves context across tenants—but not the source security policy

Microsoft Fabric’s new IQ Sharing preview gives data teams a cleaner way to expose a lakehouse, warehouse or supported mirrored item to another organization. The producer creates a Share, the recipient accepts it into a workspace in another Fabric tenant, and Fabric builds read-only mirrored items backed by shortcuts to the producer’s data. No guest identity is required in the producer tenant, and Microsoft says the data is not copied. Microsoft’s launch post and product documentation describe the preview.

The useful addition for analytics and AI teams is that a shared lakehouse can carry Markdown files containing definitions, descriptions and usage guidance. That gives the recipient a package containing both data and human-readable context rather than forcing definitions through a separate email or wiki. Those files are guidance, however: Microsoft says they do not automatically configure downstream analytics or data agents.

The sharing unit is the first control decision

IQ Sharing exposes an entire supported Fabric item, not selected tables or files. Tables added to—or deleted from—an already shared item are automatically reflected for consumers. That makes the relationship low-maintenance, but it also expands the review surface: a table added next month can become visible without a new invitation.

Microsoft explicitly tells producers to review both current contents and future additions. If a partner should see only a curated subset, the safer pattern is to place that subset in a dedicated item before sharing it. Microsoft’s older External Data Sharing option remains the table-or-file-level alternative.

Source security rules do not travel

The largest caveat is in the product documentation: OneLake security rules on the source item are not honored when consumers access data through IQ Sharing. Teams should therefore treat the Share’s item boundary and recipient list as the effective cross-tenant authorization boundary, rather than assuming row-, column- or table-level OneLake rules will constrain the recipient.

That changes the deployment checklist. Validate the contents in a nonproduction item, confirm every recipient identity, use an expiration date, and test revocation. Ownership matters too: Microsoft warns that expiration, deletion, revocation or loss of the Share creator’s source access can interrupt the recipient’s downstream analytics.

Agents require another hop

Recipients cannot directly use the resulting OneLake Mirrored Item in Fabric data agents, ontologies, semantic models or notebooks. Microsoft requires an intermediate lakehouse with shortcuts to the mirrored item’s data. That extra hop should be included in lineage, access reviews and failure testing; accepting a Share alone does not make its context agent-ready.

The preview has no service-level agreement and Microsoft does not recommend it for production workloads. The practical trial is narrow: create a dedicated nonproduction data product, attach its definitions, accept it in a separate tenant, then test table additions, expiration and revocation before attaching any semantic model or agent. IQ Sharing removes the copy pipeline, but it does not remove the need to design the security and lifecycle boundary.