Category: AI

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.

CIA Brief 20260627

image

Security & Threat Intelligence
Microsoft Product Updates & Announcements
Cloud & AI
Sustainability

After hours

When a cyber attack took 100 hospitals offline – https://www.youtube.com/watch?v=WxY6aLRVgcI

Editorial

If you found this valuable, the I’d appreciate a ‘like’ or perhaps a donation at https://ko-fi.com/ciaops. This helps me know that people enjoy what I have created and provides resources to allow me to create more content. If you have any feedback or suggestions around this, I’m all ears. You can also find me via email director@ciaops.com and on X (Twitter) at https://www.twitter.com/directorcia.

If you want to be part of a dedicated Microsoft Cloud community with information and interactions daily, then consider becoming a CIAOPS Patron – www.ciaopspatron.com.

Watch out for the next CIA Brief next week

Before You Buy the Copilot Licence, Do This First

MAI_a705418914201c07

Everyone wants to know what Copilot can do. Almost nobody asks what Copilot will find.

That’s the question that actually matters. Copilot doesn’t create new access — it works entirely within your existing Microsoft 365 permissions. It can only surface what a user is already allowed to see.

Sounds safe. It’s not. Not if your SharePoint environment looks like most tenants I’ve walked through.

Sites shared with “Anyone with the link” since 2021. Files in folders with permissions no one’s reviewed in years. Ownerless sites stuffed with content nobody knows exists. When your finance manager asks Copilot to “summarise what we know about Project X,” it’ll pull from everything she can already access — including documents she’d have had to know to search for directly.

That’s not a Copilot problem. That’s the data governance problem you already had, just made visible.

My recommendation? Run the readiness assessment before you assign a single licence.

What is the Copilot Readiness Assessment, really?

Most people think readiness means “do you have the right licence and update channel.” The Copilot Readiness Report in the Microsoft 365 admin centre does tell you that — which users are technically eligible, which devices are on the right update channel, who your best pilot candidates are.

That’s the easy half.

The hard half is whether your data is in a state that Copilot should be let near. That check lives in a completely different place, and most readiness guides skip it entirely.

Notice what’s missing? Almost every “Copilot readiness checklist” you’ll find online focuses on licence eligibility. The data side is where the actual risk sits.

Step-by-Step: Running a Proper Readiness Check
Open the M365 Copilot Readiness Report

Go to the Microsoft 365 admin centre. In the left nav, select Reports > Usage, then choose Microsoft 365 Copilot and open the Copilot report. Click the Readiness tab.

You’ll see prerequisite licence counts, update channel eligibility, and a user table flagging suggested Copilot candidates. Export the list. It gives you a concrete starting point for a pilot conversation with your client.

Check for Oversharing in SharePoint

Open the SharePoint admin centre. Go to Reports > Data Access Governance. This is where you find the oversharing risk — sites with “Anyone” sharing links active, files broadly accessible across the tenant, high-member-count sites with no clear owner.

Work through the data access governance reports. Anything flagged here is content Copilot can reach on behalf of any user who has permission.

By default, SharePoint sharing is set to the most permissive option. Most tenants have never changed it.

Run the Content Management Assessment

Still in the SharePoint admin centre, go to Advanced Management > Content Management Assessment and select Start assessment. This surfaces inactive sites, ownerless sites, and sites that haven’t been attested by anyone recently.

SharePoint admin centre
  > Advanced Management
    > Content Management Assessment
      > Start assessment

Rerun it every 30 days. This isn’t a one-time exercise. It’s a recurring conversation starter with every client who has Copilot.

Review Your Sensitivity Labels

Open the Microsoft Purview compliance portal > Information protection > Labels. Check whether labels are deployed and whether content users will ask Copilot about is actually labelled.

Sensitivity labels travel with content. Copilot honours them at response time — it won’t surface content a user doesn’t have decrypt rights for. No labels means no enforceable control over what ends up in a Copilot response.

They’re not a Copilot feature. They’re the floor you build on.

Why This Actually Changes Behaviour

Here’s the real win.

Running this before you sell the licence gives you a different kind of client conversation. Not “here’s what Copilot can do” — but “here’s what your data looks like right now, and here’s what we need to fix before Copilot is safe to use.” That’s a trusted adviser conversation, not a licence upsell.

Microsoft’s Secure & Governed Data Foundation blueprint organises this into three pillars: remediate oversharing, set up guardrails, meet regulations. It’s worth reading before your next client review. Print it. Take it in.

If you’re not showing clients this work before you enable Copilot, you’re not protecting them — you’re just adding a powerful AI to a mess.

Copilot doesn’t create oversharing. It reveals it. Fix the foundation first, then turn on the power.