Your Power Platform governance stops where your agents start

You may already have a default environment strategy. You may already have DLP (data loss prevention) policies. You may have Managed Environments, sharing limits, environment routing, maker onboarding, pipelines, and a Center of Excellence trying very hard to keep things sane.

But in a tenant that has agents touching your data and taking action for users, that discipline might only scratch the surface.

Agents add something the old model was not built to handle on its own.

They add identity.

They add runtime behaviour.

They add channels, tools, knowledge sources, and sometimes other agents.

And they do not all live inside the same admin centre.

So you have your Power Platform governed. Excellent. But do you have your agents governed?

The old model still matters

This is not a dramatic funeral for Power Platform governance.

The old model still matters.

You still need Power Platform environments. Copilot Studio agents are created and managed inside Power Platform environments, and those environments define boundaries for data, roles, data policies, and lifecycle separation.

You still need to control who can build. The Power Platform tenant setting for Copilot Studio authors lets admins select a security group that can use Copilot Studio with pay-as-you-go but it does not keep out makers with a Copilot license.

You still need data policies to govern how agents connect to data and services inside and outside the organisation.

You still need sharing controls to configure limits for how agents are shared.

So no, you don't need to throw away the platform controls.

Phew.

But you do need to stop pretending they are the whole governance model.

PPAC — the Power Platform admin center — can govern a lot but it cannot answer every question an agent creates.

Break 1: the agent is becoming an identity

Traditional Power Platform governance often starts with the maker.

• Who can create?
• Which environment are they in?
• Which connectors can they use?
• Who can they share with?

That still matters. But an agent is not only a thing a user built. It can also become an actor in the tenant.

Microsoft Entra Agent ID gives agents their own identity model. Agent identities can be viewed in Entra, where admins can assign them their own access packages, permissions and conditional access. Every agent built in Copilot Studio now gets an agent identity in the Entra tenant where authentication performed by these agents is logged as AI-agent activity.

It is no longer enough to ask who made the agent.

You also need to ask:

• What identity does the agent have?
• Who sponsors it?
• What permissions does it hold?
• What sign-ins or actions are being logged against it?
• What happens when the sponsor leaves?
• Who can disable it during an incident?

A maker can leave. A team can reorganise. A pilot can become useful. The agent identity can remain and turn from helpful experiment to orphaned actor.

Just assuming that “someone probably owns it” is not an operating model.

Sponsor is not the same as owner

In the old world, whoever built it, usually owned and maintained it and was considered responsible for it.

In the new agentic world, you need to make a clear distinction between who owns an agent and is responsible for technical operation and the sponsor, who is accountable for why the agent exists.

It’s the sponsor who decides whether the agent should still exist, whether its access still makes sense, and whether the business still accepts the risk. That’s an important job that needs a named person.

When the agent reads data, calls tools, or affects a process, the answer cannot be “the platform team owns it.” The platform team can operate the road. They should not own every car on it.

A business agent needs a business sponsor.

Otherwise the agent has access, but nobody has responsibility.

That is a bad trade.

Break 2: the agent may not live where PPAC looks

A lot of us still think of agent governance as Copilot Studio governance. That is understandable. Copilot Studio is where many low-code makers start.

But it is not the whole agent estate.

Agents are managed based on how they are built and some necessary controls are only available from other admin centres.

A Copilot Studio agent lives in a Power Platform environment. PPAC matters there.

A Microsoft 365 Agents Toolkit agent is packaged and managed like a Microsoft 365 app. That points you toward the Microsoft 365 admin centre and Integrated Apps.

A SharePoint agent is tied to a SharePoint site and its permissions. That is a different governance path again.

A Foundry agent is built in Microsoft Foundry Agent Service, a managed platform for building, deploying, and scaling AI agents using supported models, SDKs, REST APIs, or code-based hosted agents.

Same organisation.

Same AI strategy.

Different admin homes.

That is where the old mental model breaks.

If your inventory starts and ends in PPAC, you may have governed the agents built in PPAC.

You have not governed the agent estate.

A registry is not a decision model

Agent 365 helps with this gap.

It gives us a way to observe, govern, and secure agents and includes a centralised registry for visibility across the agentic environment.

That matters.

You cannot govern what you cannot see.

But a registry does not magically decide who is responsible.

It does not tell you who approves a new tool. It does not tell you who accepts a risky data source. It does not tell you who gets called when Defender raises an alert. It does not tell you whether the business sponsor still wants the agent alive three months after the pilot.

Visibility is the start.

Governance begins when somebody knows what to do with what they see.

Break 3: the agent keeps changing after publish

Old governance often has one big moment: approval before production.

That made sense for apps and flows that were mostly deterministic. You checked the solution, reviewed the connectors, approved the release, and moved on to support.

Agents do not sit still in the same way.

The data they read changes.

The tools they can call change.

The audience changes.

The risk changes when a personal assistant becomes a team dependency.

The risk changes again when a team dependency gets shared broadly.

And the risk changes a lot when the agent moves from answering questions to taking action.

This is why “approved once” is too thin.

Agents need review points, not because every agent is dangerous but because every useful agent is alive enough to drift.

That drift can be boring: a stale knowledge source, a missing owner., a connector that is no longer needed.

Or it can be serious: a broader audience, a more sensitive data source, a write action added as “a small change.”

This is where the EU AI Act is useful as a pattern, even when a normal internal productivity agent is not automatically a high-risk AI system.

For high-risk AI systems, the Act puts weight on human oversight, monitoring, logs, and using systems according to instructions.

That is good discipline for agent operations too.

Know who owns the outcome, keep enough trace to understand what happened and review the agent when the risk changes.

Do not wait for a mess to prove you needed a lifecycle.

The missing piece is the responsibility map

The fix is not another giant policy document but rather a responsibility map.

A plain one.

For every agent type you allow, write down who owns which decision.

For example:

This does not need to be beautiful.

It just needs to exist.

Because without it, everyone assumes someone else has the uncomfortable part.

The platform team assumes the business owns the outcome.

The business assumes IT has checked the risk.

Security assumes the platform team can block the agent.

The maker assumes approval means someone will tell them when anything changes.

Gaps and holes in your governance survive, not because people are careless but because the handoff was never designed.

A simple diagnostic for your own tenant

Pick three agents:

• One built in Copilot Studio.
• One created through Microsoft 365 or SharePoint.
• One pro-code or Foundry-style agent, if you have that path.

Now answer these questions without calling a meeting:

1. Where was it created?
2. Which admin centre shows it?
3. Does it have an Entra Agent ID?
4. Who is the sponsor?
5. What data sources does it use?
6. What tools or connectors can it call?
7. Who can block, reassign, or retire it?
8. Where would audit, security, and data-risk signals appear?
9. What would trigger a review?

If you cannot answer, that is not a maker problem.

It’s a gap in your governance model. And as agents become easier to create, that gap will only widen. The easier it is to build, the clearer the operating model must be.

What I would do first

I would not start by trying to govern every possible agent pattern.

Start with one table.

Call it your agent governance map.

Use columns like these:

Do not treat this as the final answer.

It’s just a first picture. Use the gaps you find to decide what to build next.

Maybe you need an authoring group before anything else.

Maybe you need Agent 365 inventory.

Maybe you need an Entra Agent ID review process.

Maybe you need a production-agent incident path before the next pilot goes live.

Maybe you need to stop calling everything “Copilot governance” because half the estate is not Copilot Studio.

The table will tell you where the next conversation belongs.

Governance has to follow the agent

PPAC is still one of the most important tools in the Microsoft low-code governance toolbox.

It gives you environments, data policies, sharing rules, routing, maker controls, and a practical way to create safe lanes for low-code agents.

But an agent can cross the line where PPAC stops.

Into Entra, because it has identity.

Into Microsoft 365, because it is packaged and distributed as an app.

Into Foundry, because developers build agents there too.

Into Purview, because data risk does not care which tool created the agent.

Into Defender, because runtime behaviour becomes a security signal.

The job is to connect the controls people already have into one operating model.

This week, pick one agent your organisation already has and follow it end to end. Understand, really understand, not just where it was built, but where it is governed, where it is logged, where it can be stopped, and who owns the outcome.

If the answers live in five different places, that is the map you needed to draw.

Your existing governance is not wasted. It is the first layer. Agents need the rest of the architecture.