Your clients are building AI agents right now. Nobody’s watching.

A client rings you. “One of the team built a little AI helper that answers questions from our SharePoint. It’s started giving odd answers. Can you take a look?”

So you go looking. There’s no record of it. No owner listed. No idea what data it reaches into. And while you’re in there, you find eleven more — built by people who left months ago, quietly wired up to who-knows-what.

That’s not innovation. That’s debt.

Here’s what nobody mentions when an SMB switches Copilot on: everyone in that tenant can already build agents. Not eventually. Today. The moment Copilot Studio and Agent Builder light up, every staff member can spin up an AI agent, point it at company data, and share it around.

And by default, all of it lands in one place — the default Power Platform environment — which you can’t delete and can’t fully lock down.

Notice what’s missing? Any decision about who’s allowed, what they can touch, or who cleans up afterwards.

What is agent lifecycle governance, really?

Strip the jargon and it’s three decisions you make before the agents arrive: where they’re allowed to live, what data they’re allowed to touch, and who’s on the hook when one misbehaves.

Microsoft hands you three levers for exactly that.

Environments are the containers agents live in. Data policies decide which connectors an agent can talk to. Maker controls decide who’s even allowed to build in the first place.

Get those three right and the eleven mystery agents never happen. Get them wrong and you’re the one explaining to a client why their customer list ended up somewhere it shouldn’t.

This isn’t about saying no to AI. It’s about drawing the lines once, so everyone can say yes safely.

Step-by-Step: putting guardrails up before the sprawl

You don’t need a six-month project. You need an afternoon in the Power Platform admin centre.

Lock down who can create environments

Tenant settings first. Stop every user being able to spin up new environments on a whim. Restrict environment creation to admins, so a new space is a decision — not an accident.

Treat the default environment as hostile

You can’t delete it, so assume the worst will land there. This is where ungoverned agents breed. Keep nothing sensitive in it, and route anything serious somewhere else.

Give real agents a real home

For anything a client actually depends on, follow the dev-test-prod pattern Microsoft recommends: build in a development environment, validate in test, publish to production. Lock each one to an Entra security group so only the right people get in. Build in production and you’re editing live, in front of users, with no safety net.

Set a data loss prevention policy

This is the big one. In the admin centre, create a data policy and sort your connectors into groups:

Business     — SharePoint, Dataverse, Outlook, Teams
Non-Business — everything else, by default
Blocked      — public HTTP, personal email, social, FTP

An agent can’t combine data across the Business and Non-Business groups. So a bot reading your client’s SharePoint physically cannot also push that data to some random web endpoint.

Notice what’s missing? You didn’t write a line of code. You drew a line, and the platform enforces it for every agent, forever.

Turn on Managed Environments where it counts

For your production spaces, switch on Managed Environments. That gets you sharing limits, weekly usage insights, and an actual record of what’s being built — the visibility that turns “eleven mystery agents” into a list you can read on a Monday morning.

Why this actually changes behaviour

Most MSPs treat this as a clean-up job. Something you’ll get to after the agents pile up.

Wrong order. Governance is cheap before the sprawl and brutal afterwards. Every agent you let breed in the default environment is one you’ll eventually have to find, decode, and either rescue or retire — usually under pressure, usually after the person who built it has gone.

“But my clients are tiny — three agents, not three hundred.” Sure. Govern the three now and the thirtieth looks after itself. Skip it, and you’ll meet the thirtieth as an incident.

Here’s the real win. When the guardrails go up first, makers still build. They just build inside lines you drew. Innovation doesn’t stop — it stops being a liability.

And for you as the MSP, that’s a conversation worth having. “We make sure your team’s AI agents are governed, owned and safe” is a service. A monthly line item. Not a favour you do at 11pm when one breaks.

Copilot agents don’t get tired, and they don’t ask permission. Govern them like staff, not like features.

My recommendation? Do the afternoon in the admin centre before your client’s first agent — not after their twelfth.

Agent governance isn’t there to slow your clients down. It’s there to make sure the thing someone built on Tuesday isn’t the thing you’re explaining to their lawyer on Friday.