Fabric gives data agents a dependency graph—but not a change-approval system

Microsoft has exposed Microsoft Fabric’s lineage graph through two REST operations, giving software—and explicitly AI agents—a supported way to retrieve an item’s upstream sources and downstream consumers. The launch turns what was previously a visual portal workflow into a programmable surface for impact analysis, catalogs, CI/CD checks and agent context. Each response contains related items, typed relation edges and referenced workspaces. Microsoft Fabric announcement

For data-agent teams, the useful change is not another natural-language interface. It is access to dependency evidence. An agent asked where a reported number came from can traverse upstream relations; one asked whether a table change is safe can enumerate downstream reports, semantic models and pipelines instead of inferring connections from names or prompt context. Microsoft describes this as grounding AI responses in Fabric’s actual dependency graph. Microsoft Fabric announcement

What the API actually returns

The platform adds GET operations for /relations/upstream and /relations/downstream. Calls require workspace and item IDs plus beta=true. Microsoft’s reference says the caller needs read permission on the item and an Item.Read.All or Item.ReadWrite.All delegated scope; users, service principals and managed identities are supported. The response separates items, relations and workspaces, allowing clients to resolve dependencies that cross workspace boundaries. Downstream API reference) Upstream API reference)

The relation vocabulary is more useful than a flat list. Microsoft documents edges including Datasource, PushData, Orchestration, Shortcut, CascadeDelete, WeakAssociation and HiddenInWorkspace; it also says the set can expand over time. The item-type list already includes warehouses, lakehouses, notebooks, pipelines, semantic models, SQL databases, ontologies and Data Agents. Downstream API reference)

Treat lineage as evidence, not authorization

The practical architecture is to place this read operation before a proposed change: retrieve the downstream graph, show the affected artifacts, and then hand the decision to a separate policy or approval layer. That separation matters because the relations API reports dependencies; Microsoft does not present it as a write-control or approval mechanism. The launch post’s examples include pre-delete impact checks and CI/CD validation, while the API itself requires only item read access. Microsoft Fabric announcement Downstream API reference)

Teams should also resist treating one successful traversal as a production guarantee. Both reference pages label the operations beta, require the explicit beta query parameter, warn that behavior may change, and say the APIs are not recommended for production use. A sensible evaluation therefore tests permission visibility, cross-workspace coverage, unsupported edge types and stale or missing lineage before any agent is allowed to recommend—or trigger—a destructive change. Downstream API reference) Upstream API reference)

Fabric’s preview supplies a missing piece of agent context: a machine-readable map of where data came from and what depends on it. It does not supply the final decision boundary. That is precisely why the API is valuable: it can make an approval artifact concrete without pretending that a dependency graph is permission to act.