Microsoft Fabric documents whose permissions an AI agent acts with, but not who reviews what it creates. Its six-part CI/CD platform (Microsoft Learn, 2026) never mentions agents as authors, and its MCP server overviews never mention Git or deployment pipelines, so in Atlan’s side-by-side read of Microsoft Learn (September 2026), commit and review for agent-made items fall to your team.
What stays open is narrow: who commits an agent’s item, whether a review gate applies to its changes, and which identity and MCP server it uses.
| Question | What Microsoft Learn says (September 28, 2026) |
|---|---|
| What a coding agent can change | Through the Core MCP Server (preview): workspaces, items, folders, and workspace roles (Core MCP overview) |
| Whose permissions apply | The authenticated identity’s Fabric RBAC permissions (MCP servers overview) |
| Audit coverage | Core: supported operations, under the executing identity; local: doesn’t itself emit Fabric audit logs (MCP servers overview) |
| How items reach Git | An admin connects the workspace; changes are committed from the source control panel or API (Git integration process) |
| Review gate for agent-made items | Not documented in the CI/CD, Git, Skills, or MCP pages |
What counts as an agent-created Fabric item?
An agent-created Fabric item is any lakehouse, notebook, pipeline, semantic model, or workspace that an AI coding tool creates or modifies through Skills for Fabric or a Fabric MCP server, rather than a person in the portal. According to Microsoft’s Skills for Fabric overview (Microsoft Learn, 2026), skills are “reusable instructions that teach AI coding tools how to work with Microsoft Fabric workloads,” open source under MIT in the microsoft/skills-for-fabric repository (GitHub).
Microsoft’s five-step flow (Microsoft Learn, 2026) ends with Fabric resources created or modified end to end, and one documented example has the agent set up Git integration and a deployment pipeline. CI/CD is one more task an agent does when asked.
Skills for Fabric is Microsoft’s version of the agent skills pattern, so agent skills enterprise safety applies. Authorship is a different seam from Fabric AI agent governance questions, which covers ontology status, refresh, and permissions for context-reading agents.
Skills for Fabric vs. Fabric MCP servers
Skills teach the agent what to do, and MCP servers do it, per Microsoft. What Fabric’s own MCP servers let an agent do maps the Core, local, and workload-specific servers, and the split mirrors the general agent skills vs. MCP distinction.
Skills can also direct an agent to call Fabric REST APIs directly, so an item can be agent-created with no MCP server in the path. Authorship is the new variable, and Fabric’s lifecycle docs don’t name it yet.
How does Fabric’s CI/CD stack treat an item an agent created?
Fabric’s CI/CD stack treats an agent-created item like a person’s, because its rules are scoped by item type and workspace, never by author. Microsoft’s CI/CD overview (Microsoft Learn, 2026) names six components (Git integration, deployment pipelines, the Fabric REST APIs, the Variable library, the Fabric CLI, and Terraform with fabric-cicd) and mentions no AI agent, Copilot, or MCP server.
Agents appear in the Git integration overview (Microsoft Learn, 2026) only as items to version, such as Data Agents on its supported-items list; unsupported item types are ignored.
Authorship starts to matter at the commit. Per the Git integration process (Microsoft Learn, 2026), a workspace admin connects the workspace to Git, and new or modified items wait under Changes until an identity with Contributor rights and Git contribute permission commits them.
That identity need not be a person, which follows from the RBAC model. The Commit To Git API (Microsoft Learn, 2026) accepts any Contributor-or-higher caller with configured Git credentials, and deployment pipelines (Microsoft Learn, 2026) move content across two to 10 stages, by hand or by API.
Lifecycle mechanics by creation path
| Mechanic | Person-created item | Agent-created item (Skill or MCP) |
|---|---|---|
| Git eligibility | Item type and connected workspace | Same, creator-agnostic |
| Reaching Git | Someone commits from the panel or API | Same; no automatic commit documented |
| Deployment stages | Two to 10, default three | Same stages; no agent-specific gate |
| Audit entry | Logged under the person’s identity | Core: logged under the executing identity, no documented agent marker |
Once an item is under version control, the stack works, and for agents that means review happens only if someone decides it should.
Does Fabric’s audit log show who or what made the change?
An audit entry in Fabric names the identity that made a change, but Microsoft documents no way to tell a coding agent from a person, and coverage depends on the MCP server. Per the Fabric MCP servers overview (Microsoft Learn, 2026), Fabric records supported Core operations under the identity that executes them, an authenticated identity that “can differ from the person interacting with the MCP client.” The local server “doesn’t itself emit Fabric audit logs.”
Signing in to the Core MCP Server (Microsoft Learn, 2026) uses your own Microsoft Entra ID account. Each Fabric operations agent, by contrast, is an item with its own Microsoft Entra Agent ID, which the operations agent guide (Microsoft Learn, 2026) says keeps agent actions distinct from human actions for auditing.
The MCP docs describe no such marker for a coding agent, and audit log search (Microsoft Learn, 2026) filters by user, returning all users and service accounts by default.
Core vs. local MCP server, on audit and identity
| Fabric Core MCP Server (remote) | Fabric MCP Server (local) | |
|---|---|---|
| Status | Preview | Open source, runs as a local subprocess |
| Identity | Entra ID sign-in; the authenticated identity’s permissions | Configured credentials for live operations |
| Creates workspaces | Yes | No |
| Fabric audit logs | Supported operations, under the executing identity | Doesn’t itself emit; the underlying service may record some |
That is the AI agent identity problem in Fabric form. An audit entry that names a person for an agent’s change records who was accountable, not what acted, and decision traces for AI agents exist because incident reviews need both.
Three lifecycle questions Fabric’s docs leave to your team
Fabric’s CI/CD, Skills, and MCP docs leave three lifecycle questions without an official answer, though the permission and audit model is coherent: the same RBAC and logging rules apply to every identity, human or agent. The closest guidance is the Core MCP Server’s Considerations section (Microsoft Learn, 2026), which warns that “autonomous or misconfigured clients may perform destructive actions” and asks for least-privilege roles and review of agent tool calls and approval settings.
That covers the call itself, not the item’s life afterward, and draws the line between an autonomous agent and a copilot at a client setting.
- Who commits an item an agent creates, and may the agent commit its own work through the Commit To Git API?
- Is any review expected between an agent’s change and production, beyond your pipeline stages?
- Should a coding agent working under a person’s sign-in be distinguishable in the audit log, as operations agents are?
Two accurate documentation sets, and no documented owner for the step between them.
It is the agent sprawl problem one level down: unreviewed artifacts instead of untracked agents. According to Veracode’s Spring 2026 GenAI Code Security Update (Veracode, 2026), only 55% of AI code-generation tasks produce secure code, even as syntax correctness exceeds 95%.
The FabCon Europe 2026 program (ESPC, 2026) lists session TH28, “From Code to Cloud: CI/CD and Agentic Development in Microsoft Fabric,” led by Microsoft’s Aviv Ezrachi and Teddy Bercovitz, and FabCon Europe 2026 sessions by role sorts the related talks. The authoring surface is live; its lifecycle rule isn’t.
What can your team do about agent-created items now?
The agent-authorship gap mostly closes with policy, once your team decides how an agent’s work reaches review.
- Connect every workspace an agent can write to Git. Each connection needs an admin, and an unconnected workspace has no Git history.
- Separate the identity that creates from the one that ships. Give the MCP client’s identity least-privilege roles, such as Contributor in a development workspace only, per the AI agent access control pattern.
- Protect the branch. Fabric commits need a branch policy allowing direct commits, so a protected branch routes agent changes through Microsoft’s admin-run checkout-branch and pull request path.
- Choose Core or local per class of change. Only the Core server documents audit coverage for its operations, so route writes through it; an MCP gateway can enforce the choice.
- Scale review to risk. A June 2026 arXiv paper, Graduated Human Oversight for Agentic Code Generation (arXiv, 2026), sorts agent coding tasks into three oversight tiers by regulatory impact, customer proximity, reversibility, and data sensitivity.
Client approval settings live in the AI agent harness your tool runs in, and owning the policy is the job of an AI center of excellence.
Check inputs too: a pipeline built on undocumented tables is a tidy artifact on untrusted data. What makes data AI-ready and an AI-ready data checklist belong in the same review as the commit, because AI-ready data comes before agent authorship.
Is your Fabric setup covering agent-created items?
Six checks, each answerable from settings you already have, show whether your tenant covers agent-created items, alongside the runtime controls in the enterprise AI agent guardrails checklist.
| Check | Why it matters | Where to look |
|---|---|---|
| Is every agent-writable workspace connected to Git? | Unconnected workspaces have no Git history | Workspace settings, Git integration |
| Which MCP server does the agent use? | Only Core documents audit coverage for its operations | Agent or client configuration |
| What Fabric role does the agent’s identity hold? | Core MCP can create workspaces and grant roles | Workspace access settings |
| Can that same identity commit and deploy? | If yes, creation and review collapse into one actor | Git permissions, pipeline access |
| Does a branch policy block direct commits? | Forces agent changes through a pull request | Azure Repos or GitHub branch rules |
| Who reviews Purview audit entries, and how often? | Nothing flags agent-originated changes for you | Purview audit search cadence |
Any row you can’t answer marks the gap in your tenant. AI guardrails tools compared covers runtime enforcement, and securing multi-agent systems covers what changes once several agents share a workspace.
How Atlan approaches context for agent-created assets
The authorship question follows agents onto any platform they write to directly, and Fabric’s audit events cover only Fabric. When an agent’s Fabric pipeline feeds a dbt model and a Tableau dashboard, reconstructing what changed means reading across systems, the problem behind governing AI agents across multiple clouds.
Atlan is the Context Layer for AI, built to sit across those systems, with connectors spanning warehouses, BI tools including Power BI, dbt, and orchestrators. The Context Lakehouse stores that context on Apache Iceberg with time travel, so every historical state stays queryable and a team can reconstruct the context an agent saw when it acted.
Context Agents work the gaps: Sage finds where two teams define the same metric differently, and Vera scores assets on completeness, accuracy, and freshness. Fabric’s Git integration governs the artifact, while the enterprise context layer carries what it means: context engineering decides which definitions count as certified, and clear context layer ownership settles who signs off. The rollout sequence is in how to implement an enterprise context layer for AI.
Governing agent-created Fabric items starts before the first commit
Fabric’s CI/CD tooling doesn’t care who authored an item, which is its strength and its gap. Permissions, Core audit logging, and Git support are documented; who commits and reviews an agent’s work before production is not.
Microsoft may yet write that rule, and the FabCon Europe 2026 guide tracks the week it could surface. Until then, run the six checks, write the answers down, and decide what happens the first time an agent creates something nobody asked to have checked in: does it wait in the source control panel, or does it ship?
FAQs about governing agent-created Fabric items
1. What is Skills for Fabric and how does it work?
Skills for Fabric is Microsoft’s open-source, MIT-licensed set of SKILL.md instruction files that teach AI coding tools, Claude Code and GitHub Copilot CLI among them, how to work with Fabric. The tool matches a prompt to a skill, then calls Fabric APIs to create or modify items.
2. Do items created through Fabric’s MCP servers automatically show up in Git integration?
No. An item reaches Git only if an admin has connected its workspace, and even then it waits as an uncommitted change until an identity with Contributor rights and Git permissions commits it. Item types that Git integration doesn’t support are ignored, never saved or synced.
3. What’s the difference between Fabric Skills and Fabric MCP servers?
Skills teach an agent what to do, and MCP servers do it. A skill is static markdown loaded into the agent’s context; an MCP server is an executable process that calls Fabric. An agent can also create items through REST APIs with no MCP server involved.
4. Does Fabric’s audit log show whether an AI agent or a person made a change?
Not as a documented category. Supported Core MCP Server operations are logged under the executing identity, and the local MCP server doesn’t itself emit Fabric audit logs. Fabric’s operations agents get their own Entra Agent ID, but the MCP docs describe no equivalent for coding agents.
5. Who is responsible for reviewing an AI agent’s changes to a Fabric workspace?
Your team is, because Microsoft’s documentation doesn’t assign it. The Core MCP Server guidance asks you to review agent-generated tool calls and client approval settings, but commit, pull request review, and deployment approval stay policy decisions. A practical default is whoever owns the workspace’s Git branch.
6. Can an AI agent create a Fabric workspace or database without a human approving it first?
Yes, if its identity has the permission and its client doesn’t require approval. The Core MCP Server can create workspaces and items such as lakehouses whenever the authenticated identity’s role allows it. Microsoft recommends least-privilege roles and client approval settings as the safeguards.
Sources
- Skills for Fabric overview, Microsoft Learn
- microsoft/skills-for-fabric, GitHub
- Introduction to CI/CD in Microsoft Fabric, Microsoft Learn
- Overview of Fabric Git integration, Microsoft Learn
- Git integration process, Microsoft Learn
- Git: Commit To Git REST API, Microsoft Learn
- Overview of Fabric deployment pipelines, Microsoft Learn
- Fabric MCP Servers overview, Microsoft Learn
- Fabric Core MCP Server overview, Microsoft Learn
- Create and configure operations agents, Microsoft Learn
- Track user activities in Microsoft Fabric, Microsoft Learn
- Spring 2026 GenAI Code Security Update, Veracode
- Governed AI-Assisted Engineering: Graduated Human Oversight for Agentic Code Generation in Regulated Domains, arXiv
- FabCon Europe 2026 program, ESPC
