Before You Buy Microsoft 365 Copilot, Clean Up Your Tenant First

image

One of the biggest mistakes I continue to see with Microsoft 365 Copilot is treating the licence purchase as the project.

It’s not.

The licence is the easy part. The hard part is making sure the information Copilot can access is actually worth finding.

Copilot doesn’t create information. It exposes what already exists.

If your tenant is messy, overshared and unmanaged, Copilot simply helps users find the mess faster.

What is Microsoft 365 Copilot readiness, really?

Most people think readiness is about licences, supported apps and technical prerequisites.

That’s not readiness. That’s procurement.

Real readiness means asking whether your Microsoft 365 environment contains information that is organised, secured and governed well enough for AI to work across it. Microsoft talks about defining your strategy, protecting sensitive data and checking readiness before rollout in its Microsoft 365 Copilot rollout guidance.

Copilot works across the data users already have access to. That should make every MSP pause.

Because if users already have access to content they shouldn’t, Copilot won’t politely ignore it. It will work with the permissions you’ve given it.

Step-by-Step: Review your tenant before assigning licences
Audit SharePoint permissions

Start with SharePoint.

This is where a lot of the Copilot value lives, and it’s also where many of the surprises hide.

Review high-value sites, external sharing, broad groups, anonymous links and old project workspaces. Microsoft has specific guidance around building a secure and governed data foundation for Copilot, including oversharing remediation and guardrails.

Notice what’s missing?

Most SMB tenants have never had a proper SharePoint permissions review.

Review OneDrive ownership

Every OneDrive is effectively a knowledge repository.

Look for departed staff, abandoned content, sensitive folders and business-critical files that only one person controls.

Copilot won’t know whether that file belongs in a managed SharePoint library instead. It will simply see information the user can access.

Clean up Teams sprawl

Open the Teams admin centre and look at inactive teams, duplicated teams and channels nobody owns.

If humans can’t tell which Team contains the source of truth, don’t expect Copilot to magically understand your operating model.

“We thought Copilot was giving bad answers.”

In many cases, the tenant was giving bad data.

Review sensitivity labels

If you use Microsoft Purview, check whether sensitivity labels exist, whether they’re published to the right users and whether people understand them.

Sensitivity labels are not decoration. They classify and can protect organisational data across Microsoft 365, as Microsoft explains in its sensitivity labels documentation.

Keep labels simple.

A label nobody understands is just another button nobody presses.

Check retention and stale content

Old content is not harmless just because storage is cheap.

Review retention policies, old libraries, archived Teams and documents that should no longer be active reference material.

Copilot can make stale content visible again.

That’s not intelligence. That’s exposure.

Validate identity and device controls

Before assigning Copilot licences, review MFA, Conditional Access, privileged accounts and device compliance.

This is where SMBs often underinvest.

They buy the AI licence, but the tenant still has weak identity hygiene and unmanaged devices.

That’s backwards.

Decide how you’ll measure usage

Don’t wait until renewal time to ask whether Copilot is working.

Set expectations early. The Microsoft 365 admin centre includes a Microsoft 365 Copilot usage report for adoption and usage metrics.

That matters because licence assignment is not adoption.

A user having Copilot and a user changing the way they work are two different things.

Why this actually changes behaviour

Here’s the real win.

A Copilot readiness review improves the tenant even before you assign the first paid licence.

Permissions get cleaned up.

Teams become easier to navigate.

Content ownership improves.

Old information gets archived.

Security conversations become practical instead of theoretical.

Copilot doesn’t get tired. Use that.

But don’t ask it to compensate for years of neglected governance.

The best Copilot deployments I’ve seen don’t start with a licence order. They start with a conversation about data, access and outcomes.

My recommendation?

Treat Copilot readiness as an MSP service, not a pre-sales checklist.

If you’re not showing clients what Copilot might expose before they pay for it, you’re leaving value on the table.

Microsoft 365 Copilot isn’t there to fix a messy tenant.

It’s there to make a well-run tenant dramatically more useful.

Creating a Digital Twin of Your Business

image

When most people hear “digital twin”, they picture an engineer running a virtual copy of a jet engine, or watching a simulated factory floor hum along on a screen. It sounds like something built for heavy industry, a long way from a business that runs on email, spreadsheets and the occasional frantic search through old files. I’ve come to think the idea fits an ordinary organisation just as well — and that most of us are far closer to having one than we’d assume. The raw material is already sitting there. We’ve just never thought of it in those terms.

A digital twin of a business isn’t a 3D model. It’s a living representation of how your organisation actually thinks: the decisions it has made, the reasons behind them, the way a job quietly moves from one person to the next. That knowledge already exists. The problem is that it’s scattered. Some of it sits in SharePoint, some in a Teams thread nobody has opened in a year, some buried in a colleague’s sent items — and an uncomfortable amount lives only inside one person’s head.

You already own the knowledge

A while back I watched someone spend half a morning answering a question their business had already answered twice. The work existed. It simply couldn’t be found quickly enough, so they built it again from nothing. That’s the everyday cost of not having a twin you can talk to. You’re not short of information. You’re short of a way to ask your own business what it already knows.

This is where Copilot starts to shift things. Connected across your Microsoft 365 tenant, it lets you put a question in plain language and pulls the thread together for you. Ask why a particular client moved onto a different plan, and Copilot can surface the Outlook email where it was decided, the meeting where it was thrashed out, and the document that recorded the outcome. A new staff member can ask it how something is normally done and get an answer drawn from real history, not folklore. You stop hunting for a file and start interrogating your own past.

The twin is only as good as what you feed it

This is where most businesses come undone. If a decision gets made on a phone call and never written down, the twin can’t see it. If the reasoning lives only in someone’s memory, it isn’t in the model. So the habit worth building is unglamorous but powerful: put decisions somewhere Copilot can reach. Keep the Teams meeting recap instead of letting it disappear. Write the why into the document, not just the what. Treat a SharePoint page or a Loop component as the place your thinking genuinely lives, rather than a tidy-up job for later.

None of that is technical work. It’s a discipline — choosing to treat your own knowledge as something worth keeping, instead of something you’ll cobble back together under pressure when you next need it.

What it actually buys you

I don’t think the goal is a perfect replica. No model captures everything, and you wouldn’t want one that tried. But a business that can answer its own questions — one that remembers why it did things — moves faster and argues less. It brings new people up to speed sooner. It stops relitigating decisions that were settled months ago.

The pieces are already sitting in your tenant, waiting to be connected. What I’m watching now is which businesses bother to feed the twin, and which keep solving the same problem every Tuesday morning, none the wiser for having solved it before.

CIAOPS AI Dojo 14

image

What’s the session about?

This month we will be focusing on new Copilot Cowork features and updates as well as optimising AI for Small Business.

Who should attend?

This session is perfect for:

  • IT administrators and support staff
  • Business owners
  • People looking to get more done with Microsoft 365
  • Anyone looking to automate their daily grind

Save the Date

Date: Friday the 31st of July 2026

Time: 9:30 AM Sydney AU time

Location: Online (link will be provided upon registration)

Cost: $80 per attendee (free for Dojo subscribers)

Register Now

The AI Toolkit Monetization Strategy: Building Enterprise Value with Microsoft Technologies

image

I’ll start with something that won’t win me any friends at the next AI meetup: owning the cleverest AI tool in the room won’t make you a cent. Not the model, not the agent, not the prompt you spent a weekend perfecting. I’ve watched a lot of people fall in love with the technology and then wonder why the invoices aren’t getting any bigger. The uncomfortable truth is that nobody pays for tools. They pay for problems disappearing.

Think about a carpenter for a moment. A carpenter doesn’t get wealthy selling you a single hammer off the back of the ute. They get paid because they walk onto a site, look at a house that needs building or a roof that’s letting the rain in, and they know exactly which tool to reach for and when. The hammer matters, but only because of the hand holding it and the job it’s pointed at. That’s the mindset I think anyone serious about AI needs to adopt — and if your organisation already lives inside the Microsoft cloud, you’ve quietly been handed a very good toolkit. Most people just haven’t worked out how to pick it up.

The hammer: Copilot and Azure OpenAI

The language model is your hammer. It’s the tool you swing by hand, and it’s genuinely powerful — but it does what you tell it, no more. In the Microsoft world that’s Microsoft Copilot sitting across your Outlook, Word and Teams, with Azure OpenAI underneath when you need to build something bespoke.

Here’s where most people get it wrong: they treat Copilot like a fancier search box. They type a vague half-question, get a vague half-answer, and conclude the whole thing is overhyped. The people getting real value approach it with a bit of discipline. The way I think about it is four steps — mission, ask, parameters, shape.

Start with the mission: the business outcome, not the chore. Don’t ask Copilot to “find me some leads.” Tell it you need thirty new enterprise clients this quarter to hit a revenue target. Then comes the ask — one sharp, specific request, like pulling together forty qualified IT directors in healthcare with their contact details. Then parameters — the context and the guardrails. This is where Copilot in Microsoft 365 earns its keep, because you can point it straight at the files in your SharePoint or OneDrive so it’s reasoning over your data, not a guess about the world. A tip I lean on constantly: dictate your context rather than typing it. The voice option in Copilot lets you talk through the background in thirty seconds, and you talk far faster than you type. Finally, shape — tell it the format you want. A clean table, a CSV you can drop into Excel, a tight bulleted summary. Stop reformatting things by hand like it’s 2015.

The screwdriver: Power Automate

A hammer needs a fresh swing every single time. The moment you find yourself doing the same AI-assisted task over and over, you’ve outgrown it. That’s when you reach for the screwdriver — automation — and in the Microsoft stack that’s Power Automate with AI Builder doing the heavy lifting.

The shift here is subtle but enormous. Instead of opening Copilot every morning to run the same prompt, you build a flow once and let it run on a schedule or off a trigger, quietly, in the cloud, forever.

Not everything deserves a flow, though, and this is where people burn weeks they’ll never get back. I run three quick tests before building anything. Is it repetitive — happening at least weekly, ideally daily? Is it rule-based, with predictable inputs and a predictable result? And does it actually pay back — does the time saved over a year dwarf the time spent building it? Don’t spend sixty hours constructing a flow that rescues someone two minutes a week. That’s not automation, that’s a hobby.

A example I like: a sales call recording lands in a Teams channel. Power Automate sees it, AI Builder pulls the transcript, reads the sentiment, drops the action items straight into Dynamics 365, and posts a tidy weekly summary back into the leadership channel in Teams. Nobody touched it. That’s the screwdriver doing its job.

The power drill: Copilot Studio

Then there are the jobs where you don’t want to define the steps at all — you just want the outcome. That’s the power drill, and Microsoft’s answer is Copilot Studio, where you build agents that handle whole processes on their own.

With the hammer and the screwdriver, you’re still drawing the map. With an agent, you describe the destination and let it find its own way through the subsystems. The trick to doing this without disaster is what I’d call staying on the loop rather than in it. Pick a genuinely meaty workflow — vendor onboarding end to end, say, from reading the invoice email, to cross-checking your Dataverse tables, to running compliance, to setting up billing. Then, and this is the hard part, don’t keep grabbing the wheel. Let it run.

Two habits make this safe. First, have agents check each other — a builder agent in Copilot Studio writes a script, and a separate reviewing agent picks it apart for security gaps before anything reaches a human. Second, watch for drift. An agent grinding away over hours or days can slowly lose the plot, so your role becomes the manager who inspects, resets the context when it wanders, and keeps it pointed at the goal.

The orchestrator gets paid

Here’s the part that actually moves the money. Owning these three tools doesn’t make you rich. Conducting them does. The orchestrator is the one who looks at a bleaking supply chain or a drowning support desk and reaches across the whole Microsoft AI toolkit — Copilot, Power Automate, Copilot Studio — to make the pain stop.

Your clients don’t lie awake wondering whether you used GPT-4o through Azure or a Copilot Studio agent. They lie awake about their costs. Solve that, and the technology underneath becomes a footnote. Problems are where the value lives.

So the real shift isn’t learning another tool. It’s moving from doing the work to directing it. Step back, find the problem worth solving, and orchestrate the kit you already own.

The Quiet Productivity Cost of Watching AI Work

image

I noticed something a few weeks back during a busy Friday afternoon. I’d asked Copilot in Word to pull together a draft summary of a long client document, and instead of moving on to the next thing on my list, I just sat there. Watching. Cursor blinking. Sentences slowly stitching themselves across the screen like I was waiting for a kettle to boil. It took me a good thirty seconds to realise I was, in effect, staring at a digital pot — and getting absolutely nothing else done while I did it.

That small moment has stuck with me. Because I don’t think I’m the only one doing it.

The watching trap

There’s a quiet productivity tax that nobody really warned us about with generative AI inside Microsoft 365. We’ve been told these tools save us hours. And they will — but only if we actually use those hours. The moment we anchor ourselves to the screen and watch Copilot draft a reply in Outlook, summarise a meeting recording in Teams, or build out a deck slide by slide in PowerPoint, we hand back every minute of the gain.

I think this happens because the output feels unfinished until it’s done. The brain treats it a bit like a conversation — and you don’t walk away from someone mid-sentence. But Copilot isn’t speaking to you. It’s working for you. And it doesn’t care whether you’re in the room.

The result is a strange new flavour of busywork. You look productive. You’re sitting at your desk, focused, eyes on the screen. But the actual output of your time is whatever Copilot was going to produce anyway. You’ve added nothing. You’ve just supervised a process that didn’t need supervising.

Why staring at it doesn’t help

The other problem with the watching habit is that it isn’t even useful. You can’t speed Copilot up by looking at it harder. You’re not catching errors in real time, because most of us don’t read carefully enough mid-generation to spot a problem — and you’ll review the final output once it’s done anyway. The watching is pure overhead.

Worse, it primes a passive mindset. When you sit and observe the machine doing the work, you start to mentally check out. The next task on your list feels heavier than it should. You lose the rhythm of context-switching that real knowledge work depends on. By the time the draft email or summary lands, you’ve already half-disengaged. So instead of pouncing on it, reviewing it sharply, and sending it on its way, you take another minute or two to gather yourself.

That’s two layers of cost. The time you spent watching, and the time it takes to mentally re-enter the work.

Treat Copilot like a colleague, not a performance

The shift I’ve had to make is treating Copilot the same way I’d treat anyone I’ve delegated something to. You don’t stand over a colleague’s shoulder while they write a document. You hand it off, you go do something else, and you come back to review when it’s ready.

So when I ask Copilot in Excel to analyse a dataset, I switch to my inbox and clear a few replies. When I have Copilot in Word drafting something substantial, I move into Teams and respond to chats. When a deck is being assembled in PowerPoint, I’m reviewing tomorrow’s calendar or skimming a SharePoint document I’d been putting off. The five or ten seconds of context-switch cost is well worth the two or three minutes I would have otherwise stared away.

The deeper habit, though, is queueing the work. I now line up several AI-assisted tasks at once. A summary running here, a draft being produced there, an analysis underway in another window. Copilot is happy to run in parallel across Microsoft 365. There’s no good reason to make those tasks sequential by tying each one to your eyeballs.

What I’m watching next

The thing I’m paying attention to from here is how teams handle this collectively. Because once AI is doing more of the small tasks across an organisation, the productivity ceiling stops being defined by what the tools can do and starts being defined by what their humans do while the tools work. The businesses that win the Copilot game won’t be the ones with the best prompts. They’ll be the ones whose people have stopped sitting and watching, and started filling that reclaimed time with thinking, deciding, and acting.

The technology is doing its part. The next move is ours.

Where Do Your Uploaded Documents Actually Go in Copilot Notebooks?

image

One of the questions I get asked most often about Microsoft 365 Copilot Notebooks is deceptively simple: when I upload a document into a notebook, where does it actually live? It’s a fair question. If you’re an MSP, an administrator, or anyone responsible for governance, “it’s in the cloud somewhere” isn’t a good enough answer. You need to know exactly where that data sits, who can reach it, and what compliance controls apply. The answer turns out to be more interesting than most people expect, and it hinges on a relatively new piece of the Microsoft 365 storage platform called SharePoint Embedded.

The short answer: SharePoint Embedded

When you upload a document into a Copilot Notebook, it does not land in your OneDrive, and it doesn’t go into a regular SharePoint site or document library that you can browse to. Instead, it’s stored in SharePoint Embedded — specifically inside a user-owned container.

Here’s the part that surprises people. Copilot Notebooks, Copilot Pages, and Loop’s “My workspace” all share the same single user-owned container per user. You don’t get a separate container for each. The first time you need any one of those experiences, Microsoft provisions one container and reuses it for all three. Even the container’s name depends on which app you opened first: it’s called “Pages” if you visited the Microsoft 365 Copilot app first, or “My workspace” (localised to your Loop language) if you opened Loop first.

There’s a governance wrinkle worth committing to memory: in the SharePoint admin center, in PowerShell, and in Purview audit data, this container’s application name always shows as “Loop” — even when it only holds Copilot Notebooks. There is no separate “Copilot Notebooks” application filter. So if you go hunting for Copilot content in your audit logs and only search for “Copilot”, you’ll come up empty. Look for Loop.

So what is SharePoint Embedded?

SharePoint Embedded is an API-only file and document management system built on the same proven Microsoft 365 storage platform that powers SharePoint and OneDrive. The key word is API-only. Unlike a normal SharePoint site, there’s no friendly web UI you can navigate to. When an application uses SharePoint Embedded, it creates a separate storage partition inside your Microsoft 365 tenant, and the documents in that partition are only accessible through Microsoft Graph APIs — and only to the owning application.

Within that partition, the application stores content in entities called File Storage Containers. Think of a container as an API-only document library: it can hold any file type, supports folders, versioning, search, and co-authoring, but it’s dedicated to and reachable by just the one app that owns it. That isolation is the whole point. The files your Copilot Notebook depends on are walled off from other applications, yet they still benefit from the full richness of the Office stack — you can open an uploaded Word or Excel file in Office for the web straight from the experience.

This is the same architecture Microsoft uses under the hood for Loop and Designer. Copilot Notebooks is simply another first-party consumer of the platform.

The detail that matters most: your data stays in your tenant

This is the line I always emphasise with clients. The storage partition that SharePoint Embedded creates lives inside your own Microsoft 365 tenant. Your uploaded documents do not leave your tenant boundary. That means everything your existing Microsoft Purview controls already do, they continue to do here:

  • eDiscovery — content is discoverable

  • Auditing — actions are logged (remember: under the “Loop” application name)

  • Data Loss Prevention (DLP)
  • Retention policies and sensitivity labels
  • Conditional access

So while the storage mechanism is new, the compliance posture is reassuringly familiar. The data is yours, it’s in your tenant, and your governance tooling applies.

Quotas, limits, and a billing nuance

Here’s a distinction that trips people up. The general, developer-facing SharePoint Embedded model bills storage separately through an Azure pay-as-you-go subscription, and that storage does not count against your SharePoint quota. But Microsoft’s first-party use of it for Copilot Pages and Copilot Notebooks works differently. Copilot Pages and Copilot Notebooks content counts against your organisation’s existing SharePoint storage quota — there’s no separate Azure bill for it. The user-owned container has a hard ceiling of 25 TB, which can’t be raised or lowered.

Lifecycle: tied to the user, with sharp edges

The container’s lifecycle is bound to its owner. Content is private by default, much like OneDrive — there’s no forced sharing. When the owning user’s account is deleted, the container is scheduled for deletion and follows the same lifecycle as OneDrive, including a manual handoff step at departure and the option to permanently reassign the container to a new owner.

One critical warning for anyone planning their data protection strategy: there is no end-user recycle bin for Copilot Notebooks. If a notebook is deleted, neither the user nor an administrator can recover it. That’s a meaningful gap compared to the recycle-bin safety net we take for granted in SharePoint and OneDrive, and it’s worth flagging to end users before they start relying on Notebooks for anything important.

Why this matters

Copilot Notebooks feel lightweight and personal, but underneath sits real enterprise-grade storage that you already know how to govern — just wearing a new name. Knowing it’s SharePoint Embedded, that it surfaces as “Loop” in your admin tools, that it counts against SharePoint quota, and that it has no recycle bin turns “somewhere in the cloud” into something you can actually manage.

Copilot Notebooks storage & governance

SharePoint Embedded platform

The MSP Skills Gap Nobody Is Talking About Yet

image

I had a conversation with an MSP owner last week that has been rattling around in my head ever since. He was telling me, proudly, about how his team had just finished a big project hardening a client’s endpoint stack. Patching, EDR, conditional access, the lot. Then almost as an afterthought he mentioned the same client had quietly turned on Copilot for sixty users and was already building their first agent in Copilot Studio. He had no plan for any of it. No policy, no review process, no clear idea who in his team would actually own it. And here is the uncomfortable part. He is not unusual. He is the rule.

The growth in AI agents inside SMB environments is going to be the steepest curve we have seen in years, and most MSPs are walking into it carrying the wrong toolkit. The skills that built a successful managed services business over the last decade are not the skills that will keep customers safe and productive over the next one. That gap is widening every week, and very few MSP owners I speak to have noticed.

Agents are not endpoints

For twenty years MSPs have been organised around things. Devices, servers, mailboxes, firewalls. You patch them, monitor them, back them up, replace them. The whole MSP operating model — RMM, PSA, ticketing, SLAs — assumes a world of static assets that misbehave in fairly predictable ways.

An AI agent is none of those things. It is not an endpoint. It does not sit still. It reads documents in SharePoint, drafts replies in Outlook, pulls data from line-of-business systems, and acts on behalf of a user across surfaces the MSP has never had to think about as a single connected thing. When a Copilot agent fetches the wrong document and pastes confidential numbers into an external chat, no RMM alert is going to fire. The questions are different too. Not “is it patched?” but “what did it do today, and why?” That is a governance and behaviour problem, not an infrastructure one.

The new skill set is governance, data and prompts

Managing agents well leans on a set of muscles most MSPs have never had to build. Understanding identity scope in Entra so an agent cannot reach data it has no business touching. Configuring sensitivity labels and DLP in Purview so a chatty agent does not quietly become a leak. Reviewing prompt design and grounding sources in Copilot Studio before an agent is let near real users. Watching audit logs in the Microsoft 365 admin centre for patterns of agent behaviour that look off.

This is closer to the work of a data steward or a security analyst than a traditional systems engineer. It is slower, more interpretive, and more about judgement than ticket throughput. It rewards curiosity and writing skills as much as PowerShell. The MSP business model has not been built for that kind of work, and the hiring pipeline certainly has not.

The retraining window is now

Here is the bit that worries me. Customers are going to assume their MSP has this covered. They will turn on Copilot, build agents in Copilot Studio, plug them into their CRM, and look across the table expecting the same calm competence they get for backups. When something goes wrong — a leaked document, an agent that quietly emails the wrong list, a workflow that has drifted off purpose — they will ring their MSP. And most will not be able to help.

The MSPs that get ahead of this will start small and start now. Pick one client, one agent, and learn it end to end. Read the audit logs. Write the policy. Build the review cadence. The technical hardening skills will still matter. They are just no longer enough on their own.

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

image

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.