What Microsoft actually shipped

Microsoft has put auto-generated Power Platform API command groups into public preview in the Power Platform CLI, shipping more than 200 commands across 15 command groups. The group names tell you how much ground that covers, from analytics and app-management through to governance, licensing, user-management and workflows-agent.

The post went up on September 17, 2026, bylined Lane Swenka, Principal Program Manager, and it describes the mechanism plainly. "API namespaces become top-level pac command groups, and API operations become discoverable commands with consistent help and inputs." That removes the hand-curation step for these groups. Whatever the specification says exists becomes something an engineer can type.

Microsoft frames this as an API-first strategy, with "One specification built monthly" driving the .NET SDK, the Python SDK, the Power Platform for Admins V2 connector and now the CLI. The post also adds a pac auth token command for admins who need to reach newly released APIs before they surface as CLI commands.

The admin center is no longer the only place this happens

For a platform owner, the interesting part is what moves out of the browser. Environment settings, governance configuration, user administration and tenant analytics have mostly meant clicking through the Power Platform admin center, or filing a support ticket when the portal did not expose the setting. Anything with a command group behind it now has a scriptable path.

The post does not enumerate which operations sit under each group, and that is the first thing we would ask about. There is a large difference between a governance group that reads policy state and one that writes and deletes tenant DLP policies, and the command count does not tell you which.

Our guess is most teams find their first useful script within a week, something that inventories every environment on a schedule and lives in the same repo as the rest of your environment strategy. Read-only inventory is the safest starting point, and the fastest way to learn what each group actually exposes.

Licensing and user management are the two groups to read twice

A licensing command group in a CLI means a loop. Once allocation or assignment is a command, someone can iterate across environments or users and change the tenant's licensing position in one run, with no form and no approval screen in the way.

The post does not say which licensing operations are exposed. If capacity or add-on allocation across environments is in scope, a mistyped environment ID turns into a capacity conversation with finance. User-management has the same problem. Bulk role changes are easy to reverse in theory and slow in practice, because reversal needs a record of the prior state and ad hoc scripts rarely capture one.

If your team has already worked through what an unused license actually costs, you know how long it takes to reconstruct who held what and when. Scripted change makes that reconstruction harder unless the script records the before state, and nothing in the tool will make anyone do that.

A documented API and a typed command carry different risk

Most of these APIs existed already, reachable from the .NET SDK or the Python SDK that Microsoft says the same specification drives. Calling an API takes a client, an auth flow, a request body, and usually a person who decided the work was worth doing at all.

A discoverable command with consistent help is a different proposition. Tab completion and a copied example get an engineer to a working invocation in a couple of minutes. The effort that used to sit in front of these operations was a control in its own right, even if nobody wrote it into the governance document. For these groups, that control is gone.

That is the Friday afternoon problem. Nobody sets out to change tenant governance at four in the afternoon. They set out to check something, find the command that checks it, notice the adjacent command that fixes it, and run that one too. The first thirty minutes of a platform incident get harder when the change came from a laptop rather than a pipeline with a run history.

Guardrails to agree on before this leaves preview

Start with the accounts. A CLI is only as dangerous as the identity it authenticates with, so ask how many people hold Power Platform Administrator and whether any of them hold it permanently. Just-in-time elevation matters more this month than last.

Then decide which command groups are allowed from an interactive session at all. Our view is that governance, licensing, user-management and authorization should run from a pipeline, with parameters logged and a change record attached, the same discipline you already apply to solution deployments in your ALM pipelines. The rest can stay with whoever needs it, written down in a governance model people actually follow.

Two questions the post does not answer, and we would want both settled before widening access. Does an action taken through pac land in the same audit trail as the same action taken in the admin center, with the same attribution? And is there a dry-run mode on the commands that write? Neither is addressed, which changes how much of your control has to sit in front of the tool rather than behind it.

The token command is the part we would watch

The pac auth token command is the quiet item in that post. It means the reach of the tool extends past those 200 commands to whatever the platform exposes at a given moment, which is sensible for an admin chasing a new capability.

It also means any policy written around a list of command names goes stale the moment a new API lands. Write the policy around the identity and the execution path instead.

Preview is the cheap moment to do this, while the number of people with the commands installed is small. The question for your next Center of Excellence meeting is direct enough: who on your team has already installed it, what have they run with it, and would you know if they had not mentioned it?