On 29 July 2026, Microsoft announced the Power Pages Security Agent preview, an AI assistant built into the Power Pages experience that can scan a site’s security configuration, diagnose access issues, and walk makers through hardening steps in plain language. It matters because Power Pages security settings are spread across authentication providers, table permissions, web roles, page permissions, site visibility, and WAF settings, and until now nothing sat on top of all of it to tell you what you actually exposed.
The Power Pages Security Agent Preview Puts Scans, Diagnosis, and Fixes in One Chat
Concretely, the agent does three things. You can ask it to run a security scan of the site and it inspects the live configuration: which tables are reachable, which table permissions apply, how web roles map to them, whether anonymous access is enabled anywhere it should not be. You can ask it diagnostic questions like why a specific user can see a specific record, and it traces the answer through the actual permission chain instead of you clicking through four different screens to reconstruct it manually. And you can ask it to help harden the site, where it proposes changes to things like authentication settings and access restrictions and explains what each one does before you apply it.
The important detail is that it reads your real site configuration. This is the same design decision that made the Dataverse plugin for coding agents useful: grounding in the actual environment instead of guessing from training data. A generic chatbot can tell you what table permissions are. This agent can tell you that your Contact table has a Global scope read permission attached to the Anonymous Users web role, on your site, right now.
Fragmented Settings Are Why Portals Leak, and This Targets the Real Cause
The model is not the interesting part here. The consolidation is.
Power Pages sites do not ship with exposed tables because makers are careless. They ship that way because the security surface is fragmented. Authentication lives in one place. Table permissions live in another. Web roles, page permissions, IP restrictions, and site visibility each have their own screen, and none of them gives you a single view of what an anonymous visitor can actually reach. I have watched experienced people get this wrong, because the feedback loop is invisible. You do not find out a table is exposed until someone crafts the right OData URL, and by then it is an incident, not a config review.
An agent that inspects the whole configuration and surfaces misconfigurations conversationally attacks that fragmentation directly. That is a better fix than another documentation page, because the problem was never that the security documentation is missing. The problem is that applying it requires holding six screens in your head at once. If you are building agents or automations alongside these portals, running a Power Platform licensing audit before you ship is the same class of discipline: catch the configuration gaps before they become incidents.
Now the honest caveat. This is a preview, and a security tool that gives a wrong answer confidently is worse than no tool at all. If the agent tells you a table is locked down and it is not, you have converted uncertainty into false confidence, which is the most dangerous state a portal can be in. Until this thing has a track record, I would treat every scan result as a guided audit, not a sign-off. Verify what it flags, and verify a sample of what it clears. I have been burned enough times by preview features behaving differently under edge cases to extend that trust slowly.
Inherited Sites and Anonymous-Access Audits Should Get Scanned First
Where this fits: the first candidates are inherited sites. Every enterprise has at least one portal built three years ago by someone who has since left, where nobody currently on the team can explain the web role setup. Pointing the agent at that site and asking what an anonymous user can access is worth doing on day one of the preview reaching your tenant. Not because the agent is infallible, but because the alternative is that nobody audits it at all.
The second candidate is any site with anonymous access enabled on purpose. Public-facing portals with self-registration are exactly where a Global scope permission accidentally attached to the wrong role does the most damage. A conversational audit lowers the cost of checking from an afternoon to ten minutes, and things that cost ten minutes actually get done.
Who benefits most is the maker in the middle: someone comfortable building the portal but not deep enough in the security model to trace a permission chain by hand. Pro devs who already know where every setting lives will use it as a faster lookup. Citizen devs building portals without understanding table permissions were the risk this feature exists to reduce. The broader pattern here connects to something worth keeping in mind: the model is the cheapest part of every enterprise AI agent, and this feature is a good example of that — the value is in the grounding and the consolidation, not the underlying AI capability itself.
Security tooling for low/no-code platforms is finally starting to assume the builder is not a security engineer, and that assumption is overdue.
Source: Announcing the Power Pages Security Agent (Preview): Your AI Partner for Site Security (Microsoft Power Platform Blog).
