You are still sorting connectors into business and non-business buckets. Advanced Connector Policies for Copilot Studio and Power Platform went GA this week, and that sorting exercise is now the slow path. Plus four more things I noticed since the last newsletter, including a week of actually using Microsoft Scout.
TL;DR: Since the last newsletter, Advanced Connector Policies (ACP) went generally available with action-level allowlists, MCP server governance, and design-time enforcement. I have a week of actually using Microsoft Scout to share. The redesigned Copilot Studio agent editor showed up in my preview tenants. The February computer-using agent hardening post hits very differently after last week’s GA. And one item, Semantic Dataverse data understanding, is worth watching even though I cannot yet point to a Microsoft source. If you build or run Power Platform, these are the items to action this week. Catch up on last week’s edition (30 May to 5 June 2026) if you missed it. Last updated June 2026.
Let's explore
1. The one I think matters most: Advanced Connector Policies for Copilot Studio and Power Platform reach general availability

I have been waiting for this for a year. Microsoft made Advanced Connector Policies (ACP) generally available since the last newsletter (it surfaced in my feed via Rafsan Huseynov and Carsten Groth this week), and after reading both the Power Platform blog and the Microsoft Learn page back-to-back, I think this is the most consequential governance change of the year for any tenant running Copilot Studio at scale.
The headline shift is the mental model. Classic DLP asked you to sort every connector into business, non-business, and blocked, and to track several overlapping policies per environment. ACP collapses that into one rule: every environment has at most one policy in effect, inherited from an environment group or set directly on the environment. Default posture is deny. New connectors that show up on the platform are blocked until you decide. If you have ever stood in front of a screen full of overlapping DLP rules and tried to predict what would actually be enforced, you know why this matters.
Three details I think most people will miss on first read. First, ACP governs what classic DLP could not: connectors that were marked nonblockable can now be blocked on managed environments and environment groups. Second, the action-level filter shows which actions are deprecated, internal, or triggers right where you set the policy. Third, MCP servers are first-class targets. The reach-out surface that agents use to call external tools is now governed exactly the same way as any other connector or action.
What I would do this week if I were a Power Platform admin: pick one environment group, build the equivalent ACP policy as an allowlist, and run it in parallel for a week before flipping ACP-only mode. Pay attention to the deprecated and internal action filter. You will probably find connectors you allowed years ago and never revisited. Scope to know up front: ACP currently applies to certified connectors and MCP connectors only. Custom connectors, HTTP, and virtual connectors stay on classic DLP for now (Microsoft says a separate rule type is planned).
Read more: Advanced connector policies are generally available on the Power Platform blog, and Advanced connector policies on Microsoft Learn for the configuration walk-through.
2. What I learned actually using Microsoft Scout this week

I covered Microsoft Scout’s launch in last week’s newsletter (initial Build coverage from Steven Christensen and the official Microsoft 365 blog) and mentioned that I used it to rebuild iiu.dk over a weekend. A week later, with Scout in daily use, here are the two things that surprised me.
First, the identity model changes how I think about delegation. Scout has its own Entra identity, scoped credentials, and Purview policies enforced inline. When I ask it to do something on my behalf, the action shows up in audit logs as Scout, not as me, and that is exactly right. It is the first time an AI assistant has felt like a coworker I can hand work to rather than a tool I am operating. For a Power Platform developer, the implication is real: this is the same identity primitive that is now under Dataverse agent users in preview. Build for it now.
Second, “always-on” changes calendar dynamics more than I expected. Scout proactively blocks time for deliverables, flags upcoming meetings I have not prepared for, and surfaces stalled decisions. After a week, my calendar looks less like a list of meetings and more like a list of work-in-progress with meetings as checkpoints. That is a productivity shift, not a feature.
If you are in Frontier and on the fence about piloting Scout, do it. Read the original launch post for context: Introducing Microsoft Scout: your always-on personal agent. The full play-by-play of the weekend rebuild is in The work as we know it is gone: I rebuilt iiu.dk in a weekend with an agent.
3. The Copilot Studio agent editor rebuild I’m watching in preview

Microsoft’s Ricardo Calejo posted a demo this week of a ground-up rebuild of the Copilot Studio agent editor. The shape is a single-page editor that puts model selection, Tools, Knowledge, and Connected agents on one canvas, replacing the tab-based authoring surface most makers use today.
I tried the preview in a sandbox tenant. The cognitive load drops sharply when everything an agent needs is on one screen. Fewer trips between tabs, fewer “wait, where did I configure that?” moments. For a Power Platform developer who builds and operates more than a couple of agents a week, this is a meaningful productivity shift, not a cosmetic refresh.
The hedge: no Microsoft Learn page or formal Copilot Studio blog post for the redesigned editor yet, so the exact shape can still shift. I would not refactor production agents on this preview surface, but I would absolutely run it in a sandbox so you have an opinion when the formal release lands.
Read more: track the Microsoft Copilot Studio blog for the formal release post, and the May 2026 release blog for the surrounding authoring changes already shipped.
4. The February computer-using agent hardening post hits differently after last week’s GA

After covering the CUA general availability story in last week’s newsletter, I went back and re-read the February post on CUA hardening. The second reading hit very differently. The features that looked like nice-to-haves earlier this year now look like the actual blueprint for production.
Three things stood out the second time. The model picker now exposes both OpenAI’s Computer-Using Agent and Anthropic’s Claude Sonnet 4.5, which means you can match the model to the interface (multi-step flows vs dense, dynamic dashboards) instead of forcing every agent through a single foundation model. The credentials story is the real unlock for unattended runs: stored credentials in either internal storage (encrypted in Power Platform) or Azure Key Vault for enterprise-grade secret management, reusable across agents, encrypted, and never exposed to the AI model. And the observability layer (session replay with screenshots, step-by-step action logs with coordinates and timestamps, run summaries, resource tracking, offline export) is the audit trail your security and compliance team will ask for before they sign off on production CUAs.
What I would action: if you have CUAs running with hard-coded passwords or shared connection references, the Azure Key Vault path is now native. Migrate one critical automation, validate the audit trail in session replay, and use that as the template for the rest. Combined with the agent-node primitive from the new workflows designer, the production pattern is clear: deterministic workflow as the spine, agent or CUA at the ambiguous step, full session replay if anyone asks why.
Read more: Computer-using agents now deliver more secure UI automation at scale.
5. One thing I cannot yet verify but am tracking
One item I keep seeing in my feed that does not yet have a Microsoft primary source. Including it here as a forward-looking signal, not as news.
Semantic data understanding in Dataverse, dated June 2, 2026. Multiple community posts (notably from Carsten Groth) describe a public preview of a semantic layer in Dataverse that automatically helps AI agents and Copilot interpret business data with richer context. If true, this would meaningfully change how custom agents ground in Dataverse without prompt-engineering the schema. I could not find a Microsoft blog post or Learn page confirming the feature or the date, so treat this as a watch-item until one appears. If you have early access, I would love to hear what you are seeing.
I will follow up in a future newsletter if and when a Microsoft primary source appears.
What every Power Platform developer and admin should action this week
- Admins: plan your move from classic DLP to ACP. Pick one environment group, build the equivalent ACP policy as an allowlist, and run it in parallel for a week before flipping ACP-only mode. Use the deprecated and internal action filter as a free audit of your tenant’s connector hygiene.
- Admins: inventory MCP servers behind your agents. ACP can now block them at the same level as any connector. List every MCP server your tenant calls, decide which ones belong in your governance posture, and set the policy. Do not let new MCP servers ship into production without an explicit allow.
- Developers and admins: move computer-using agent credentials off scripts and into Azure Key Vault. If you have CUAs running with hard-coded passwords or shared connection references, the Key Vault path is now native. Migrate one critical automation, validate the audit trail in session replay, and use that as the template for the rest.
- Developers: try the redesigned Copilot Studio agent editor preview in a sandbox. If your tenant has it, build one non-production agent end-to-end on the new surface. Do not rebuild production agents on a preview surface, but form an opinion before the formal release.


Leave a Reply