TL;DR: Power Platform governance is shifting from controlling connectors to controlling capabilities. As Copilot Studio agents and MCP-connected tools become more common, governance teams need to define not just which services can be used, but which actions and tools workloads are allowed to access. The future of governance is capability-level control guided by business purpose and least privilege principles.
Introduction
Advanced connector policies (ACP) are compelling because they strengthen connector governance, but the bigger story is what they reveal about the direction of Power Platform governance. If you haven’t read my previous blog on why ACP doesn’t replace DLP, I’d recommend starting there.
For years, governance discussions have largely focused on the connector level: Is this connector allowed?
Increasingly, that question is no longer granular enough. The question needs to become:
What should this workload actually be capable of doing?
That distinction becomes particularly important as Power Platform moves further into agents, generative orchestration and dynamically selected tools.
A trusted connector can still expose too much
Consider a connector that exposes 30 different operations. An application might only need two:
- retrieve a customer
- list their existing orders
But the connector might also expose actions that:
- create records
- modify records
- delete records
- trigger administrative operations
Even if the organisation trusts the service itself, that does not automatically mean every workload should have access to every capability the service exposes.
This is where connector-level governance alone becomes insufficient. The more useful question is: Which operations does this workload genuinely require?
That is a far closer expression of least privilege.
Action-level governance matters more as workloads become dynamic
There is an important distinction to make here. Action-level connector governance is not entirely new. Existing Power Platform data policies already introduced controls for certain individual connector actions.
ACP continues this broader shift towards more deliberate control over the connector capabilities available to a workload. This matters because the architecture of the workloads themselves is changing.
In a traditional application, the execution path is typically designed explicitly. A simplified model might look like:
User → Application → Defined Logic → Connector Action
A developer has intentionally chosen the operation that will run.
Agents introduce another layer. A Copilot Studio agent using generative orchestration can determine which available tool is appropriate for a particular request.
The model begins to look more like:
User → Agent → Reasoning → Tool Selection → Action
This changes the governance conversation. The software itself may increasingly participate in selecting the capability it uses.
Available tools become part of the security boundary
For agentic workloads, governance teams need to look beyond whether an agent technically has access to a connector. The more important question is which capabilities that access makes available.
Consider an agent connected to an enterprise system. Its approved capabilities should align with the agent’s defined purpose.
Capabilities the agent may require:
- search customer records
- retrieve order details
Capabilities the agent may not require:
- delete customers
- modify financial information
- trigger administrative processes
Approval of the underlying service does not automatically justify making every capability available to the agent.
For agentic workloads, least privilege increasingly needs to operate across the following layers:
Environment → Connector → Action → Agent → Tool
Each layer progressively narrows what the workload is capable of doing, from the environment in which it operates to the specific tools the agent can invoke. This layered approach is more precise and more secure than treating an approved connector as an all-or-nothing decision.
MCP makes this even more important
Model Context Protocol (MCP) introduces another dimension. MCP allows agents to interact with external systems through sets of exposed tools.
From a governance perspective, an MCP server may expose many capabilities behind a single integration point. Approving or blocking the server itself is useful. But the deeper governance question is: Which individual tools behind that server should this agent be allowed to use?
That distinction matters. An organisation may trust an MCP server while still deciding that a particular agent should have access to only three of the twenty tools it exposes. This is why agent governance cannot end with connector governance.
Your environment strategy now matters even more
ACP also reinforces a point that governance teams sometimes overlook: Environment architecture is part of the security model.
If an environment contains dozens of unrelated workloads, its policy has to support all of them. That naturally makes the allowlist broader.
By contrast, when an environment has a clearly defined purpose, its policy can be far more restrictive.
For example:
HR Production Environment
- Purpose: Employee lifecycle applications.
- Allowed services: Dataverse, Microsoft 365 and approved HR integrations.
- Permitted capabilities: Only the actions required by deployed HR applications and agents.
Compare that with an environment that’s purpose is simply: “Production.”
A generic environment will almost inevitably require broader permissions because every workload has different needs. ACP therefore does not reduce the importance of environment strategy. It increases it.
Governance should start with workload purpose
This points to a better way to design Power Platform governance. Instead of beginning with a connector catalogue, begin with the workload.
Ask:
- What business process does this workload support?
- Which systems genuinely need to participate in that process?
- Which operations does the workload need from those systems?
- Which of those capabilities should an agent be able to invoke autonomously?
- What is the approval process when new capabilities are required?
The resulting governance chain becomes:
Business purpose → Environment → Permitted services → Permitted actions → Agent tools → Business justification
That is a much more deliberate model.
Do not govern agents like traditional apps
One mistake organisations may make is applying the same governance model to agents that they use for traditional Power Apps.
There are similarities, but agents introduce additional considerations. A traditional application generally executes logic that has already been defined. An agent may have several tools available and determine which one to use based on the user’s request and its orchestration logic. The tools made available to an agent therefore deserve the same scrutiny as permissions granted to an application. Perhaps more.
The governance principle should be simple:
An agent should not have a tool merely because it might be useful someday.
If a tool is not required for the agent’s defined purpose, there should be a clear reason before it is introduced. That is least privilege applied to agentic architecture.
The direction of travel is clear
Power Platform governance is becoming progressively more granular. The evolution looks something like:
Broad data-boundary governance → Environment-specific governance → Connector governance → Action-level governance → Agent and tool governance
ACP is part of that evolution. But the destination is larger than ACP itself. As Power Platform becomes increasingly agentic, governance will need to define not only where data can move, but also what capabilities autonomous workloads are allowed to possess. That is the real shift.
The question for governance teams is no longer simply: “Can this connector be used?”
It is becoming: “What should this workload be capable of doing, and why?”
And that is probably the governance question we should have been asking all along.
