The app-builder skill is the line to read twice

Microsoft's September 2026 Power Platform feature update landed on September 17, and the easy story is the interface work. Six new Fluent 2 pattern-based canvas screen templates joined three that had already shipped. Bulk updating of eligible modern controls arrived, along with new avatar and spinner controls and a progress bar with Power Fx-driven values and accessible progress semantics. The model-driven app header and navigation refresh reached general availability. Good work, easy to demo. The line that should change your review process sits further down the post.

Two agentic authoring capabilities reached general availability. One is a canvas authoring agent plugin. The other is an app-builder skill for model-driven apps, and Microsoft's list of what it covers runs through tables, columns, relationships, forms, views, charts, generative pages, sitemap, JavaScript validation rules, security roles, business process flows and business rules. Read the end of that list again. An agent can now author the artifacts that decide who sees which records and what a process will permit.

The post is bylined Tiffany Treacy, Vice President of Product for Power Platform at Microsoft. It describes the canvas plugin as giving makers and developers "a new way to work with Power Apps canvas apps using agent-assisted development workflows" and as "helping accelerate common app-building tasks while keeping makers in control". That last phrase is the one your governance model now has to cash.

A generated security role is still a security role

Most review processes quietly assume a security role costs something to build. Somebody opened the editor, worked through table privileges one at a time, and got bored enough to ask whether the app really needed write access on that table. The friction was doing part of the governance work for you, and nobody ever wrote that down.

Drop that cost and the volume goes up. A maker asks for an expenses app, the skill generates the tables and the forms and a role to go with them, and the role arrives already written. The question is what your solution import approval actually inspects, because a role granting broader read than anyone intended looks identical in a solution file to one that doesn't.

If your ALM pipelines make approval a formality, this update raised the price of that formality. Our read is that security role changes now deserve their own gate, separate from the rest of the solution, with a named human who can explain what business reason produced each privilege.

Connector-backed pages reach past Dataverse

Generative pages gained connector support in public preview. Microsoft says they can reach data beyond Dataverse through connectors such as SharePoint, SQL or any other connected service, and that a generative page can be embedded in a model-driven app form section or tab.

So a page sitting inside a model-driven form can render data from a SQL instance next to Dataverse records whose security roles know nothing about that SQL instance. Dataverse row-level security stops at the Dataverse row. The connector runs under a connection with its own credentials and its own effective permissions, and those two permission models were never designed to agree.

We've argued before that a connector is not an integration, and the same gap turns up here with less warning, because the page sits inside the form rather than off in a flow somebody has to go looking for. The post doesn't say how DLP policy evaluation applies to connector-backed generative pages, and that's the first question we'd put to Microsoft. Our guess is that environment DLP still governs the connector, which puts weight on your environment strategy. Guessing is a poor basis for a data classification decision, so get it confirmed before somebody embeds a customer table in a form tab.

What evidence of control would look like

Keeping makers in control is a statement of design intent. An admin needs something inspectable. What we'd want inside a solution is a record of which components an agent generated, which ones a human edited afterwards, and what prompt produced the first version. We'd also want to know whether the app-builder skill can be scoped so it generates forms and views but never a security role. Plenty of organizations would switch that off tomorrow.

The post doesn't describe either capability. Absence from a feature post is not absence from the product, so put the question to your account team. But if agent-authored components land in a solution indistinguishable from hand-built ones, every control you have depends on a reviewer spotting something they have no signal to look for.

The same problem reaches business process flows and business rules. A business rule that makes a field required, or hides it from a role, is often a control somebody in finance asked for in writing two years ago. If an agent regenerates a form and the rule comes back subtly different, the person who owns that requirement finds out when the quarter closes wrong.

What a maker-built app should carry before it ships

Provenance, at minimum. A named owner for every security role in the solution, and not the maker's account by default. A written statement of which connectors the app touches and whose credentials they run under. The handoff between human and agent work has to be recorded somewhere a reviewer will actually see it, and right now that somewhere is probably a field on your intake form rather than anything the platform hands you.

Teams already running governance that keeps low-code moving have most of the machinery for this. What changes is the trigger. Screening apps by connector list and user count will miss the small, unremarkable app that carries a generated security role into a production environment because nothing about it looked interesting.

Microsoft points to Power Series, a set of 20 hands-on labs developed by the Power CAT team, and those are worth your makers' time. Add one lab of your own. Hand a maker the app-builder skill, let it generate a security role, then sit an admin in front of the solution file and ask them to explain why each privilege is there. Whatever they can't answer in that room is what your approval gate is currently waving through.