Security teams should treat AI skills as governed access paths to sensitive data, not just convenient productivity features. Start with complete inventory, then map which lakehouses each skill reaches, who built it, and who can use or share it. Apply sensitivity labels, endorsement controls, and review underlying data exposure so citizen development does not create invisible access to corporate information.
Why AI skills in Fabric need governance, not just enablement
AI skills in Microsoft Fabric are best treated as governed access pathways, because they can surface or transform data from lakehouses without behaving like a traditional report or notebook alone. The security question is not only what the skill does, but which data it can reach, how it is published, and whether users can redistribute its outputs into wider business workflows.
That changes the control model. A business-built skill can inherit data exposure from the underlying Fabric environment, while also adding a new distribution layer that may be easier to share than the source data itself. Security teams therefore need a clear owner, a visible inventory, and a decision rule for when a skill is allowed to move from experimentation into business use.
When teams manage the skill lifecycle, the goal is to keep the convenience of citizen development without letting the skill become an undocumented access path. The most useful way to think about it is as a governed data product with an AI interface, not as a harmless prompt wrapper. Enterprise AI Copilot Security Guide is a useful companion for the broader pattern of oversharing, connector governance, and sensitive-data exposure in enterprise AI rollouts.
What security teams should inventory and map first
The first governance step is a complete inventory of AI skills, including who built each one, which workspace it lives in, what data sources it touches, and who can invoke or share it. That inventory should be explicit about lakehouse reach, because the same skill can look benign at the user interface while reading from highly sensitive tables underneath.
Security teams should also map the privilege path, not just the content path. Ask whether the skill is reading data directly, relying on delegated permissions, or depending on a broader workspace role that could expose more than the builder intended. Where the skill is tied to reusable templates or shared datasets, review whether one business user can accidentally create many skills with the same hidden reach.
Because the AI skill layer sits close to the data platform, treat the inventory as a control boundary, not a spreadsheet exercise. The practical question is whether you can answer, at any point, “what data can this skill access, and who can extend that access?” without having to reverse-engineer the implementation. AI Infrastructure Workload Identity Guide is relevant where the skill depends on broader platform identities, pipelines, or service access behind the scenes.
For external governance framing, NIST AI Risk Management Framework and ISO/IEC 42001:2023 AI Management System Standard both support the idea that AI features need ownership, traceability, and risk oversight rather than ad hoc approval.
How to control sharing, endorsement, and data exposure
Once the inventory exists, governance should focus on what changes the blast radius: who can use the skill, who can share it, and whether the result can be promoted beyond the original team. Sensitivity labels are useful, but only if they are applied consistently to the underlying data and respected by downstream sharing behavior. Endorsement controls matter for the same reason, since a business-built skill can gain legitimacy quickly once it is presented as an approved internal tool.
The important control decision is whether the skill is allowed to expose data that the builder should not broadly publish in another form. If the skill summarizes or composes from multiple sources, security teams should assume that the output may reveal more than any one source table would on its own. That is why the underlying data exposure review has to happen before broad distribution, not after someone notices that the skill is useful.
Current guidance also suggests paying close attention to permissions inheritance and reuse. A skill that is harmless in a sandbox can become a sensitive access path when copied into a more privileged workspace or shared with a wider audience. AI Security Platform Buyer’s Guide is helpful when teams are comparing tools and controls for inventory, policy enforcement, and review workflow around AI features.
For security control mapping, NIST Cybersecurity Framework 2.0 fits the governance, identification, protection, detection, and recovery responsibilities around AI skills as data-access mechanisms, while NIST SP 800-53 Rev 5 Security and Privacy Controls provides a stronger control-catalog lens for access control, auditability, and configuration oversight.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 provides the primary governance reference for this topic.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Skills should only reach the data their purpose requires. |
| AU-2 — Event Logging | Skill use and sharing need traceable evidence for review. | |
| CM-8 — System Component Inventory | Inventory is essential to govern all AI skills and their data reach. | |
| Recommendation — Restrict each skill to the minimum data access needed for its function. Log skill creation, access, sharing, and data queries. Maintain a complete inventory of AI skills, owners, and connected datasets. | ||
Practitioner Guidance
What to prioritise: Treat the first approval gate as “can this skill reach sensitive data, and can we explain that reach in one sentence?” If the answer is no, postpone rollout until the data path, sharing path, and owner are all visible.
What to verify: Verify three things before trusting a skill in production use: the exact lakehouses it can query, the identity or role it uses to do so, and whether sharing the skill expands access beyond the original builder’s intent. If any of those are unclear, assume the control model is incomplete.
Common mistake: Teams often govern the prompt or the label and ignore the data path. That misses the real risk, which is that a simple business-facing skill can become an easy-to-share wrapper around a much broader set of data permissions.
Practitioner takeaway: The right governance model is to approve AI skills the way you would approve a sensitive internal access path, with traceable ownership, scoped reach, and reviewable sharing, not just with a checkbox that the skill exists.
Related resources from NHI Mgmt Group
- How should security teams govern AI agents that business users can create and customize across Microsoft 365?
- How should security teams stop data leakage when business users build reports on shared semantic models in Microsoft Fabric?
- How should security teams govern API keys used for generative AI access?
- How do security and platform teams govern agent workflows when business users can build them visually?
