/fabric-policies-cli

name: fabric-policies-cli
description: "Author, review and manage Microsoft Fabric governance policies and PolicySet items. Invoke before clarifying underspecified lockdown requests or missing intent, identities or scope. Discover current contracts and roles, map scenarios to rules, and execute one approved API lifecycle. Not catalog audits or KQL policies. Triggers: Fabric policy, PolicySet, governance rule, latest Fabric policies, policy contract review."

> **Telemetry — MANDATORY.** Every `api.fabric.microsoft.com` call must carry > `x-ms-fabric-skill: fabric-policies-cli` (`az rest`: `--headers "x-ms-fabric-skill=fabric-policies-cli"`), > including every LRO poll, `fabric_lro` and retry. Snippets omit it — add it anyway.

Fabric Policy skill

Translate governance intent into policy rules, explain their effective behavior, and manage the PolicySet item lifecycle across all currently documented Fabric policies, not a fixed list. The bundled snapshot describes **preview** policies and **beta** rule APIs, for evaluation/development and not recommended for production; verify current availability and contracts before presenting them as current.

> **CRITICAL NOTES** > 1. To find workspace details (including its ID) from a workspace name: list all workspaces, then use JMESPath filtering. Follow pagination and resolve ambiguous matches. > 2. To find item details (including its ID) from workspace ID, item type, and name: list all items of that type in the workspace, then use JMESPath filtering. > 3. A workspace storing the PolicySet is NOT its enforcement scope. Tenant or Capacity is chosen at creation and cannot be changed; targeted workspaces are rule conditions. > 4. Creating a policy set does NOT activate it. Explicit approval is required before activation, replacement, deactivation, deletion, or editing rules in an active set. > 5. Rules are OR alternatives, not ordered overrides. A broad Allow rule can defeat a narrower restriction.

Mode and reference selection

Read the relevant reference before mapping or reviewing a policy, constructing payloads, or executing commands. Load only the detail needed for the current request.

| Mode | Task | Read | |---|---|---| | Authoring | Map intent, discover objects/roles, construct and validate rules | [Policy capabilities](references/fabric-policies-overview.md), then [API reference](references/fabric-policies-api-reference.md) for discovery; [examples](references/EXAMPLES.md) as needed | | Consumption | Inspect policy sets, rules, or current activation without mutation | API reference above | | Operations | Create/manage items or rules; activate, deactivate, replace | API reference above |

Use the generated [policy knowledge inventory](references/policy-knowledge.json) as a discovery seed, not proof of API acceptance or a replacement for live checks.

For authentication, discovery, REST transport, pagination, retry and LRO handling, read [COMMON-CLI.md](../../common/COMMON-CLI.md) and [COMMON-CORE.md](../../common/COMMON-CORE.md). Do not reproduce shared setup guidance. Use `onelake-catalog-cli` for catalog posture audits/remediation, not this skill; KQL ingestion/retention policies belong to `eventhouse-cli`.

Discover current policy support

On each use, first check the latest official documentation using the live-discovery procedure in the policy capabilities reference. Enumerate the overview's supported policies and follow the relevant scenario and endpoint links; for an inventory request, cover every listed policy. Do not treat the table below as an allowlist. Include newly documented policies or changes once their semantics and contracts are verified, without requiring an update to this skill. If a documentation response is truncated, follow its pagination offsets until the supported-policy table and relevant REST enum are complete before reporting verification.

An explicitly offline request overrides live lookup. If offline or documentation is unavailable, use the dated bundled inventory/references, disclose that newer support is unverified, and do not claim a current inventory or infer absence from this table. Documentation lookup never authorizes tenant/API access or deployment.

Default scenario-to-approval flow

For a free-text request to build a policy, do the work rather than return a manual CLI tutorial: discover the policy, resolve existing objects and role requirements read-only, generate the exact configuration, and present one approval-ready proposal. Do not require the user to supply IDs that authorized discovery can resolve. Advice-only, file-only and offline requests remain non-executing.

The proposal includes resolved names/IDs, storage workspace, scope, actor groups, required operator and governed-user roles, complete rules and allow/block cases, existing active-set conflicts, exact intended API changes, and rollback. One explicit approval can authorize creation, configuration and activation together when all are named in that reviewed plan. Before approval, make no mutations. After approval, execute the exact plan using the APIs, read back each stage and confirm activation; do not ask for the same approval again. Changed scope/rules, new conflicts, unapproved replacement, permission grants or rollback require fresh approval. Ambiguous names, unresolved business choices and missing access are genuine blockers, not reasons to guess or silently broaden permissions.

Bundled policy snapshot

Offline baseline: inventory retrieved **2026-10-28**; contract references verified **2026-10-26**. These stored dates are available here even when separate file reads are forbidden; report them as baseline dates, not a live check. Neither the weekly refresh schedule nor a merge guarantees freshness or a maximum snapshot age.

| User intent | Policy | Scope | Support boundary | |---|---|---|---| | Restrict item creation by group, workspace, or item type | `ItemCreation` | Capacity | Verified beta rule contract | |