Keeping Everything Forever Is Hurting Your Security and Your AI

Professional holding one neat folder amid towering stacks of old archive boxes

Most businesses I work with have the same retention policy, even if nobody wrote it down: keep everything, forever, just in case. Storage feels cheap, deleting feels risky, and nobody wants to be the person who threw out the one file the lawyers asked for.

I get it. But in a world of Copilot and constant breaches, “keep everything” isn’t the safe option anymore. It’s quietly making both your security and your AI worse.

More data, more risk

Every file you keep is a file someone can steal. An old client spreadsheet from 2014 does nothing for you today, but it’s just as damaging when it turns up in a breach. The bigger the pile, the bigger the attack surface and the more there is to lose.

Old data is also usually the worst-governed data. Sites from long-finished projects still have “Everyone” links. Ex-staff’s shares never got cleaned up. And if you ever end up in a dispute, everything you kept is potentially discoverable, including things you’d forgotten existed.

For Australian businesses there’s a legal angle too. Under APP 11.2, once you no longer need personal information for any permitted purpose, you must take reasonable steps to destroy or de-identify it (with limited exceptions). Hoarding isn’t neutral. It can be a compliance problem.

Why Copilot cares about your mess

Microsoft is clear that Copilot “only surfaces organizational data to which individual users have at least view permissions.” (Microsoft Learn). That’s good security design, but it means Copilot grounds its answers in everything a user can reach, rubbish included.

Picture asking Copilot for the current pricing policy. It finds five versions across SharePoint, Teams and someone’s OneDrive, including the 2019 draft that was never approved. Stale, duplicated and conflicting content produces confused answers, and users then decide “AI doesn’t work”.

Worse is oversharing. Copilot doesn’t create permission problems, it reveals them. The salary file that was technically open to everyone but buried six folders deep can suddenly appear in an answer. I wrote more about this in Data Governance Is the Real Copilot Readiness Test.

What good looks like: Microsoft’s tools for tidying up

The good news is Microsoft 365 already has the tools. Here’s where I’d start:

Retention policies and labels. Purview Data Lifecycle Management lets you retain-only, delete-only, or retain and then delete. Retain-then-delete is the one most businesses are missing.
Records management. For content you genuinely must keep, use Purview records management so it’s protected deliberately, not by accident.
Archive, don’t hoard. Microsoft 365 Archive provides cost-effective storage for inactive SharePoint sites and files.
Find dead sites. SharePoint site lifecycle management includes inactive site, site ownership and site attestation policies, part of SharePoint Advanced Management.
Buy time while you clean up. Restricted Content Discovery limits specific sites from appearing in organisation-wide search and Copilot responses while you review them.
Watch AI usage. Data Security Posture Management for AI is Purview’s front door to discover, secure and apply compliance controls to AI use.
Follow the blueprint. Microsoft’s secure and governed foundation for Copilot guide pulls these pieces together.

Tidy data is a competitive advantage

Deleting things feels scary. Keeping everything feels safe. The reality is the reverse. A smaller, well-governed data estate is easier to secure, cheaper to defend in a dispute, and gives Copilot something worth reasoning over.

If you’re an MSP, this is a conversation worth having with every client now. Start with retain-then-delete and inactive sites. Your clients’ security and their AI results will both thank you.

Who Owns the Agent When the Employee Walks Out the Door?

A professional leaving an office tower at dusk, glowing threads trailing from her briefcase back to the building

Here’s a question I don’t think many businesses have asked yet. When you hire your next person, will they be allowed to bring their own agents with them? And when someone leaves, will you let the agents they built in your business walk out the door too?

For years we’ve treated a worker’s toolkit as personal. Their know-how, their shortcuts, their way of working. Agents blur that line badly. An agent can hold skill, but it can also hold memory, data and relationships. That makes the answer far less obvious than it first appears.

The toolkit versus the tenant

I think the cleanest way to start is to split an agent into two parts.

The first part is the pattern. The prompts, the instructions, the way someone has learned to break a job down and hand it to AI. That’s skill. It lives in their head as much as anywhere, and I don’t believe a business can or should claim it. A good tech who has learned how to direct agents well will carry that ability to their next role, the same way they carry their troubleshooting instincts.

The second part is the data. An agent built in Copilot Studio inside your Microsoft 365 tenant, grounded on your SharePoint libraries and connected to your systems, belongs to the tenant. So does what Copilot remembers about how a person works. Microsoft stores Copilot memory in a hidden folder in the user’s Exchange mailbox, inside your tenant, and admins can find it with Purview eDiscovery. That’s a pretty strong hint about where ownership sits.

I wrote recently about the mystery of personal SharePoint skills, which end up stored in a user’s OneDrive. Personal in name, but still sitting in the company’s tenant. Expect a lot more of that.

Memory is where it gets messy

Picture a consultant who has spent two years working with an agent. It knows her clients, their quirks, which contracts are touchy and which projects ran late. Now she moves to a competitor. Should that memory go with her?

My view is no, and not because the business is being greedy. That memory is tangled up with client data, confidentiality obligations and, in many cases, data residency requirements. You can’t neatly pull “how she works” out of “what she knows about our customers”. Until the tools can genuinely separate the two, the memory has to stay.

Treat BYO agents like BYOD

Bringing your own agent in the other direction feels a lot like the early days of bring-your-own-device. The answer then wasn’t a flat yes or no. It was policy, identity and control. Agents need the same treatment. Whose identity does it run under? What data can it reach? Where does what it learns end up? If you can’t answer those, the agent shouldn’t touch your tenant.

What I’d do now

None of this is legal advice, and your lawyer will have views. But there are practical steps any SMB or MSP can take today:

Write a simple agent policy covering who can build, bring and share agents.
Keep an inventory of every agent, with a named human owner.
Add agents and AI memory to your offboarding checklist, right next to mailbox and device handover.
Update employment contracts to say what’s portable and what stays.
Decide upfront that skills and prompt patterns travel, while data and memory stay put.

The people who learn to work well with agents will be worth more wherever they go. That’s fine. Let them take the skill. Keep the data. Just make sure you’ve written down which is which before someone hands in their notice.

Pressing Record in Australia: Who Needs to Say Yes?

Cartoon of colleagues around a meeting table smiling and agreeing, with a closed laptop and a simple microphone on the table

The short version

Recording a meeting is useful. Minutes, a replay for whoever was on leave and an AI summary are all real benefits. But in most of Australia you can’t just press record, or let an AI note-taker into the room, without everyone’s consent. The rules differ by state and territory, and the penalties for getting it wrong can be serious. Even where the law lets a participant record, trust is the thing that gets damaged.

My recommendation is simple. Have one official recording, run by the organiser, with consent built into the booking or invite and announced at the start. No personal or third-party recorders, AI bots or wearables unless the organiser has agreed. Sample wording is further down.

This is general information, not legal advice. I’m not a lawyer. If it matters, get advice for your situation.

Why this is everyone’s problem now

AI note-takers have made recording effortless. Microsoft 365 Copilot in Teams, Otter, Fireflies, Zoom recording, phone voice memos and even AI wearables will happily capture a whole conversation and ship it off to a cloud service. In an MSP or small business that covers internal meetings, client calls and the awkward conversations about incidents and mistakes. If someone discovers a bot or a phone quietly recording, that trust goes.

What the law says, state by state

There’s no single national recording law. It’s mostly state and territory surveillance-device legislation, plus Commonwealth rules on telecommunications. Broadly, Victoria, Queensland and the NT let a participant record a private conversation without the others’ consent. SA and WA generally require everyone’s consent. NSW, Tasmania and the ACT generally require consent too, with a narrow exception for recording for your own personal use that isn’t shared. Consent can be express or implied.

Jurisdiction	Statute	Can a participant record without others’ consent?	Key exception	Penalty (where verified)
NSW	Surveillance Devices Act 2007 (s7)	Generally no	Personal use only (not communicated or published to non-parties), or reasonably necessary to protect lawful interests	Up to 100 penalty units or 5 years (individual); 500 penalty units (company)
Vic	Surveillance Devices Act 1999 (s6)	Yes – participant recording isn’t caught by s6	Communicating or publishing a private conversation is regulated separately (s11)	Not verified for publication
Qld	Invasion of Privacy Act 1971 (s43)	Yes – s43(2)(a) exempts a party	Publication is regulated separately (ss44-45)	40 penalty units or 2 years (using a device on a conversation you’re not part of)
SA	Surveillance Devices Act 2016 (s4)	No – all principal parties must consent, expressly or impliedly	Reasonably necessary to protect lawful interests; public interest	Up to $15,000 or 3 years (individual); $75,000 (body corporate)
WA	Surveillance Devices Act 1998 (s5)	No	Lawful interests and similar exceptions	Up to $5,000 or 12 months (individual); $50,000 (body corporate)
Tas	Listening Devices Act 1991 (s5)	Generally no (NSW-style)	Personal use only / lawful interests	40 penalty units or 2 years (secondary source, not verified)
ACT	Listening Devices Act 1992 (s4)	Generally no (NSW-style)	Personal use only / lawful interests	50 penalty units (secondary source, not verified)
NT	Surveillance Devices Act 2007 (s11)	Yes – offence only applies if you’re not a party	Publication is regulated separately (s15)	250 penalty units or 2 years (non-party recording)
Cth	Telecommunications (Interception and Access) Act 1979 (ss6-7)	Not an issue for a party recording at their own end, generally	Interception of a live communication over a telecoms system without the knowledge of the person making it is prohibited	Up to 2 years

Check these before relying on them. Section numbers and penalties come from secondary sources that summarise the statutes. The Tasmanian and ACT penalties are unverified, and so are the Victorian, Queensland and NT penalties for publishing a recording. Check the current legislation before you rely on any of it.

Two more traps:

Publishing is a separate issue. Even where you can lawfully record, communicating or publishing the recording to others can be an offence or need consent. Sharing a recording or transcript on LinkedIn, in a Teams chat or with an AI vendor can be the real problem.
Mixed locations. If you’re in Victoria, someone’s in Perth and someone’s in Sydney, it’s not clear which law applies. The safest approach is to assume the strictest one applies, which means getting everyone’s consent.

In person, online and ‘private conversation’

The surveillance device laws are about ‘private conversations’. Broadly, a conversation isn’t private if all the parties ought reasonably to expect it might be overheard by someone else. A large open session might arguably fall on that side. A small team meeting or a client call almost certainly doesn’t. I wouldn’t rely on that argument. A court looks at the circumstances, and it’s untested for meetings like yours.

The rules apply equally to a phone on the table, a wearable and a bot that joins your Teams call. The device is a ‘listening device’ whatever it looks like.

Commonwealth: the TIA Act and the Privacy Act

TIA Act: it prohibits intercepting a live communication passing over a telecommunications system without the knowledge of the person making it. A participant recording at their own end isn’t usually treated as interception. Whether a bot that joins a call as a participant is different hasn’t been tested, as far as I know.
Privacy Act: it applies to ‘APP entities’, which are generally businesses with turnover over $3 million (plus some smaller ones, such as health providers) and government agencies. The small business exemption is still in force as at October 2026 according to secondary sources, though reform has been proposed. Many MSPs are under the threshold, but many of their clients and some vendors aren’t.
OAIC guidance: it says meeting recordings and AI transcripts are personal information. Collect only what’s reasonably necessary, tell people, consider opt-outs, and destroy or de-identify what wasn’t needed, such as a personal chat or confidential client details.
Statutory privacy tort: since 10 June 2025 there’s a tort for serious invasions of privacy. I haven’t verified how it applies to small operators or to recordings.

The AI note-taker problem

The recording is only half of it. An AI tool adds questions that an old-fashioned voice memo never did:

Third-party storage: your colleagues’ and clients’ words now sit on a vendor’s servers.
Training: does the vendor use the audio or transcripts to train its models? Some do, so check the terms.
Cross-border: the data is probably processed outside Australia.
Confidentiality: people discuss client names, incidents and commercial details, which may breach NDAs or client contracts.
Voiceprints: some tools build speaker profiles, which is biometric-style data.
Sharing: some tools email a summary to every attendee, or publish a link, automatically.

This is already in the courts overseas. In re Otter.AI Privacy Litigation in the US alleges Otter’s Notetaker recorded meetings without all participants’ consent and used the data for training. In August 2026 a federal court held Otter could plausibly be treated as a third-party eavesdropper because it keeps and uses recordings for its own purposes. That’s US law, not ours, but it shows the risk.

There are workplace consequences too. The Fair Work Commission has accepted covert recording as a valid reason for dismissal (Schwenke v Silcar [2013] FWC 4513). NSW also needs 14 days’ written notice for camera, computer or tracking surveillance of employees, and the ACT has a notice and consultation regime. If you run staff meetings through an AI recorder, check them.

A simple approach for MSPs and small business

The cleanest fix is to separate the organiser’s official recording from everyone else’s. The organiser decides, tells everyone, gets consent and controls where the recording lives and who sees it. An individual’s own recorder or bot has a separate vendor, separate retention and nobody else’s consent. In SA, WA and (mostly) NSW, Tasmania and the ACT that’s where someone can get into trouble, even if they only meant it as private notes.

Write a short recording policy. Plain English (sample below).
Get consent in the invite or booking. Say the meeting will be recorded, why, who sees it and how to opt out.
Announce it at the start. Silence after a clear announcement may amount to implied consent, but express consent, such as a ticked box or a Teams consent prompt, is better.
Make it visible and offer opt-outs. Use the recording indicator, say it out loud, and let people keep their camera off or ask in chat.
One official recording. The organiser shares the transcript or summary afterwards, so nobody needs their own recorder.
Set retention, deletion and access. Where it’s stored, how long it’s kept, who can view it, and how someone asks for deletion.
Control who joins. See the Teams notes below. Zoom shows participants a consent prompt when recording starts.
If you find an unauthorised recording, stay calm. Politely ask for it to be stopped, ask what’s been captured and where it’s stored, and ask for deletion and no sharing. Don’t confront anyone publicly or take their device. If it’s serious or has been shared, get advice.

What Microsoft 365 gives you in Teams

If you manage the tenant, two Teams meeting policy settings are worth knowing. Both are admin-level policies, not per-meeting switches, and both match Microsoft Learn.

Manage external bots and their access to meetings. Teams detects external bots such as note-takers and holds them in the lobby until the organiser explicitly admits them. “When detected, require approval before joining” is the default. Microsoft says some bots may not be detected, so it doesn’t replace a policy. It also suggests letting only organisers and co-organisers admit people from the lobby.
Require participant agreement for recording and transcription. It’s off by default. Switch it on and, once recording or transcription starts, everyone else is muted with camera and sharing off until they answer Yes or No. A No means a view-only experience. The person who starts the recording is treated as having consented, and the choices appear in the attendance report. It’s the closest thing Teams has to a tick-the-box consent.

Sample wording

(a) Invite or booking notice

This meeting will be recorded (audio, video and chat) by the organiser so that people who can’t attend can catch up and so we can produce notes and an AI-generated summary. The recording is stored in [location], kept for [90 days], and available only to [who]. If you’d prefer not to be recorded, email [organiser] before the meeting and we’ll make arrangements, such as keeping your camera off or asking questions in chat. Please don’t use your own recording tools, AI note-takers or bots without the organiser’s agreement. By attending after reading this notice, you agree to be recorded.

(b) Start-of-meeting script

Before we start: this session is being recorded by us, the organisers, for notes and an AI summary that we’ll share afterwards. If you don’t want to be recorded, please say so now or message [organiser] in chat, and we’ll sort it out. Please don’t run your own recorder or AI note-taker. We’ll share the official transcript and summary. If anyone is uncomfortable at any point, we can pause the recording. Is everyone happy to proceed?

(c) Short recording policy

Only the organiser makes the official recording of a meeting.
Attendees must not record audio or video by any means (phone, laptop, wearable, AI note-taker or bot) without the organiser’s agreement and the consent of everyone present.
Attendees are told about the recording in the invite and at the start of the meeting, and can opt out.
The organiser shares the transcript or summary with attendees. It isn’t shared outside the meeting without the consent of the people in it.
Recordings are stored in [location], kept for [period], and deleted on request where practical.
Unapproved bots will be removed. If an unauthorised recording is found, the organiser will ask for it to be stopped and deleted.

What I haven’t verified

Section numbers and penalties come from secondary sources, not the statutes themselves.
The Tasmanian and ACT penalties are unverified.
The Victorian, Queensland and NT penalties for publishing a recording are unverified.
Whether a bot that joins a call counts as ‘interception’ under the TIA Act is untested, as far as I know.
I haven’t verified how the statutory privacy tort applies to small operators or to recordings.

Sources

General information only, not legal advice. Laws change and details vary by situation, so check the current legislation or get advice before relying on this.

ConnectWise Breach: Proving What an App Did with Microsoft Graph Activity Logs

IT security analyst tracing activity across glowing monitors in a dark operations room

The ConnectWise supply-chain attack on Microsoft 365 tenants has raised a question I keep hearing from MSPs: if an attacker’s app signed in to a tenant, how do you prove what it did, or didn’t, do?

The honest answer is that Microsoft doesn’t publish one definitive list of “Graph activity that isn’t in the UAL”. What it does document is which log records what. Put those side by side and the gaps become clear. I’ll cover what each log tells you, where the blind spots are, how to switch on Microsoft Graph activity logs, and how to scope the blast radius if you didn’t have them on.

What GCIT showed

Credit to Elliot and the team at GCIT, whose write-up of the ConnectWise Cloud Backup compromise is a model of how to be open about an incident. Their tenant had one successful service principal sign-in from the Cloud Backup app (15 Oct, 144.172.64.128, Python user agent). They proved nothing was done with that token by matching its identifier against 13,682 requests in their Microsoft Graph activity logs. The UAL on its own could never have proved that. They also note that Graph activity logs need Entra ID P1 and have to be switched on before the event.

The three logs and what each one tells you

Sign-in logs (service principal and managed identity sign-ins are kept separately from interactive sign-ins) tell you that a token was issued, and from where. They don’t tell you what was done with it. One sign-in can mean hundreds of API calls, or none at all, as GCIT found. Retention is 7 days on Entra ID Free and 30 days on P1/P2, so export them. https://learn.microsoft.com/en-us/entra/identity/monitoring-health/reference-reports-data-retention
The unified audit log records audited actions in each workload. It isn’t a record of every API request. A good example is mail: MailItemsAccessed covers all protocols, including REST/Graph and EWS, but it’s only on by default for E3/E5 users. Check your mailbox audit configuration everywhere else. Bind accesses are also aggregated and de-duplicated. https://learn.microsoft.com/en-us/purview/audit-log-investigate-accounts
Microsoft Graph activity logs (MicrosoftGraphActivityLogs) record every HTTP request Graph processes for your tenant: app ID, service principal, IP, request URI, method, response size, and the token and sign-in identifiers. That’s what lets you join requests to sign-ins. They need Entra ID P1 or P2 and a diagnostic setting that sends them to Log Analytics, Storage or Event Hub. They aren’t retroactive, and delivery usually takes up to 30 minutes, occasionally 2 hours. https://learn.microsoft.com/en-us/graph/microsoft-graph-activity-logs-overview

So where are the blind spots?

Anything read through Graph that the workload doesn’t audit as an action, such as directory and user reads, will only show up in Graph activity logs. And full_access_as_app over EWS isn’t Graph at all, so it won’t appear in Graph activity logs. It would only appear in mailbox auditing. If you don’t have Graph activity logs turned on, “sign-in but no UAL entries” doesn’t prove nothing happened. It means you can’t tell.

On audit retention: Audit Standard is 180 days. Audit Premium (E5) keeps Exchange, SharePoint, OneDrive and Entra records for one year, and up to 10 years with the add-on. https://learn.microsoft.com/en-us/purview/audit-log-retention-policies

What an attacker could do without Graph activity logs

The short answer is anything the app’s granted permissions allow. Without Graph activity logs, most read-only activity leaves no trace at all.

Likely to leave no trace (reads)

Directory reconnaissance: listing users, groups, admin role holders, devices, apps, Conditional Access policies and licences (Directory.Read.All, Policy.Read.All). Reads like these aren’t recorded in the UAL, which makes them perfect for mapping a tenant before a bigger attack.
Org intel: org charts, managers, phone numbers and email addresses, all useful for phishing and business email compromise.
Teams/chat and calendar reads, and some file reads, depending on permissions and audit coverage. SharePoint and OneDrive FileAccessed events usually do appear in the UAL, but bulk reads by an app can be patchy.

Probably visible, if auditing was on

Mail reads (Mail.Read): these show as MailItemsAccessed, but only if mailbox auditing records that action for the affected mailboxes. If it doesn’t, they’re invisible.
Writes and changes: sending mail, creating inbox rules, adding app credentials or owners, consenting to new apps, creating users or changing roles, and changing CA policies. These normally appear in the Entra audit log or the UAL, because they’re audited actions rather than reads.

What actually determines the blast radius

The app’s application permissions. Check Enterprise applications > the app > Permissions. Something like Mail.Read or Files.Read.All is tenant-wide.
The service principal sign-ins: times, IP addresses and how many tokens were issued.
The Entra audit log: look for any new credentials, owners or consents on that or other apps, which would show persistence.

The honest bottom line is that without Graph activity logs, a sign-in followed by no UAL entries means you can’t prove what was read. Treat anything that app could read as potentially exposed, rotate its secrets, and remove or scope down its permissions. Then turn on Graph activity logs so next time you can prove it either way.

How to turn on Microsoft Graph activity logs

It takes about 10 minutes per tenant.

Before you start

Licensing: Microsoft Entra ID P1 or P2 in the tenant (Business Premium includes P1).
Role: Security Administrator is the least privileged Entra role Microsoft supports for creating diagnostic settings. You also need Azure rights on the destination.
An Azure subscription with a destination that already exists: a Log Analytics workspace (best for querying), a storage account (cheap long-term archive) or an Event Hub (to stream to a third-party SIEM).
Cost: P1 doesn’t cover the Azure side, so you pay for what you ingest and store. Microsoft’s rough guide is about 15 GiB a month into Log Analytics per 1,000 users, but it varies a lot with the apps in the tenant. Check the Azure Monitor pricing page and consider a workspace transformation or the Basic table plan to cut costs.
The logs are NOT retroactive. You only see activity from the moment you switch them on, so do it before you need them.

Step 1: Create a Log Analytics workspace

In the Azure portal, go to Log Analytics workspaces > Create.
Pick the subscription, a resource group, a name and a region, then Review + Create.

Step 2: Turn on the diagnostic setting (GUI)

Sign in to the Microsoft Entra admin centre as at least a Security Administrator.
Browse to Entra ID > Monitoring & health > Diagnostic settings.
Select Add diagnostic setting and give it a name.
Tick MicrosoftGraphActivityLogs. While you’re there, also tick ServicePrincipalSignInLogs, SignInLogs and AuditLogs, so you can correlate them.
Tick Send to Log Analytics workspace and choose your subscription and workspace.
Save.

Step 2 (alternative): PowerShell

There’s no dedicated Entra cmdlet for this. New-AzDiagnosticSetting targets Azure resources, not the tenant. Instead, you PUT to the Azure Resource Manager endpoint for microsoft.aadiam/diagnosticSettings with Invoke-AzRestMethod:

			
Connect-AzAccount
$ws = "/subscriptions/<SUB-ID>/resourceGroups/<RG>/providers/Microsoft.OperationalInsights/workspaces/<WORKSPACE>"
$body = @{
  properties = @{
    workspaceId = $ws
    logs = @(
      @{ category = "MicrosoftGraphActivityLogs"; enabled = $true },
      @{ category = "ServicePrincipalSignInLogs"; enabled = $true }
    )
  }
} | ConvertTo-Json -Depth 5
Invoke-AzRestMethod -Method PUT -Payload $body `
  -Uri "https://management.azure.com/providers/microsoft.aadiam/diagnosticSettings/GraphActivity?api-version=2017-04-01"

		

The Azure CLI equivalent is az rest --method put --url "<same URL>" --body @body.json.

Step 3: Check it’s working

Microsoft says delivery is usually within 30 minutes, but allow time for the table to first appear (Entra’s docs allow up to three days). Then run:

			
MicrosoftGraphActivityLogs
| where TimeGenerated > ago(1d)
| summarize Requests = count() by AppId, ServicePrincipalId
| sort by Requests desc

To tie Graph calls back to a service principal sign-in, which is exactly the GCIT approach:

			
MicrosoftGraphActivityLogs
| where TimeGenerated > ago(7d)
| join kind=leftouter (AADServicePrincipalSignInLogs | where TimeGenerated > ago(7d))
    on $left.SignInActivityId == $right.UniqueTokenIdentifier
| project TimeGenerated, AppId, ServicePrincipalName, IPAddress, RequestMethod, RequestUri, ResponseStatusCode

		

Tips

Set retention on the workspace (or per table) to suit your incident response needs. If you need it for years, also archive to storage.
Do this per customer tenant. A Graph activity log only covers the resource tenant, so you won’t see a multitenant app’s activity in other tenants.
Diagnostic settings can’t filter Graph logs. Use a workspace transformation if volume is an issue.

References: Graph activity logs overview and Configure Entra diagnostic settings.

What I’d do today, with the tools we have

Turn on Graph activity logs now in every tenant with P1 (Business Premium has it). It’s cheap insurance.
Export sign-in logs, including service principal sign-ins, beyond 30 days.
Confirm MailItemsAccessed is being audited on every mailbox.
Cut app permissions down. Use Exchange RBAC for Applications and Sites.Selected instead of tenant-wide Mail.* and Sites.* grants. https://learn.microsoft.com/en-us/exchange/permissions-exo/application-rbac
Use Defender for Cloud Apps app governance where you have it, so you get alerts on unusual app behaviour. https://learn.microsoft.com/en-us/defender-cloud-apps/app-governance-manage-app-governance

Shared responsibility

This is the shared responsibility point again. The vendor protects its credential, Microsoft provides the logs, and we as MSPs own the decision to let that app in, which means having the logging on before we need it. My cw-skykick-exposure-check.ps1 script will help you with the exposure side. Graph activity logs are what answer “what did it actually touch?”

Security Keeps the Bad Guys Out. Compliance Stops the Good Guys Doing the Wrong Thing.

One of the biggest mistakes I see when talking to organisations about Microsoft 365 is that they treat security and compliance as the same thing.

They’re not.

In fact, I often explain it this way: security is largely about protecting your data from people who shouldn’t have access to it, while compliance is about making sure people who do have access don’t misuse it.

Both matter. Both are essential. But they solve completely different problems.

The Security Mindset

When most people think about protecting information, their mind immediately goes to external threats.

Hackers trying to steal credentials.

Phishing emails landing in inboxes.

Ransomware attempting to encrypt files.

Business email compromise targeting finance teams.

That’s the world of security. The goal is to prevent unauthorised access and stop attackers before they can do damage.

This is where tools like Microsoft Defender, Conditional Access, Entra ID, multifactor authentication and device management come into play. They create barriers around your data and make it harder for outsiders to gain access.

The challenge is that many organisations stop there.

They invest heavily in security controls, get comfortable that their tenant is well protected, and assume the job is done.

It isn’t.

Because once someone is legitimately inside the organisation, security has largely done its job.

That’s where compliance starts.

The Compliance Challenge

Imagine an employee has access to customer records as part of their daily role.

They’re not a hacker.

They’re not bypassing security controls.

They’re simply using information they have permission to access.

Now imagine they accidentally email a spreadsheet containing sensitive customer information to the wrong person.

Or upload confidential financial data to an unauthorised location.

Or paste company information into an AI tool that hasn’t been approved by the organisation.

Security didn’t fail here.

The employee had legitimate access.

The issue is what happened after access was granted.

That’s a compliance problem.

Compliance is about governing how information is used, shared, stored and protected after someone is authorised to see it.

Why Copilot Makes This More Important

The rise of Microsoft 365 Copilot makes this distinction even more critical.

Copilot operates using the permissions that already exist within your Microsoft 365 environment. If a user has access to information in SharePoint, OneDrive, Teams or Exchange Online, Copilot can help them work with that data.

That’s why I continually tell organisations that Copilot readiness isn’t just about licensing. It’s about information governance.

I’ve seen organisations excited about deploying Copilot only to discover that sensitive documents are stored in locations where far too many people have access. The problem isn’t Copilot. The problem is that existing permissions and governance weaknesses become much more visible once AI enters the picture.

If your data is overshared, Copilot can expose that reality very quickly.

Security and Compliance Need Equal Attention

The best organisations understand that security and compliance are two sides of the same coin.

Security asks:

“Who should be allowed in?”

Compliance asks:

“What should they be allowed to do once they’re inside?”

In Microsoft 365, that means combining strong security controls with technologies such as Microsoft Purview, sensitivity labels, data loss prevention policies, retention controls and information protection.

One protects the front door.

The other governs what happens in the rooms beyond it.

Ignore either one and you’re leaving your organisation exposed.

Final Thoughts

I think many businesses are still more comfortable talking about security than compliance because security threats are easier to visualise. We can picture a hacker attacking our systems.

What’s harder to visualise is an employee accidentally sharing the wrong file, retaining information for too long, or exposing sensitive data through everyday work practices.

Yet those risks can be just as damaging.

As AI becomes more deeply woven into Microsoft 365, the organisations that succeed won’t simply have the strongest security. They’ll also have the maturity to govern their information properly.

Security protects your organisation from outsiders.

Compliance protects your organisation from itself.

And increasingly, you need both.

AI Governance Starts Before Copilot Does

Most AI conversations with business owners start in the wrong place. They ask whether Microsoft 365 Copilot is worth buying. I think the better question is whether the business is ready for what Copilot will reveal.

I have seen the same pattern often enough now. A client gets excited about Copilot in Outlook, Teams, Word and Excel. Someone wants meeting summaries. Someone else wants faster proposals. The owner wants staff to stop using random public AI tools with company data. All fair enough. But then we look underneath and find the real issue: years of loose permissions, old Teams, forgotten SharePoint sites, stale guests and no clear policy on what staff should or should not ask an AI system to do.

That is where AI governance starts.

Governance is not a document no one reads

A policy is useful, but only if it changes behaviour. If the policy says “use AI responsibly” and nothing else, it has failed before it starts.

For Copilot, I want plain rules. What data can be used? What data must not be used? When does a human need to review the answer? Who owns the final output? What happens if Copilot surfaces something the user did not expect to see?

That last question matters. Copilot does not need to break into your tenant to create a problem. If a user already has access to a file, Copilot may be able to use that file as part of an answer. The silent risk is not Copilot ignoring permissions. The risk is that the permissions were never cleaned up in the first place.

The technology follows the tenant

This is why I keep coming back to the Microsoft 365 basics. Entra ID, MFA, Conditional Access, SharePoint permissions, Teams lifecycle, Purview sensitivity labels and Data Loss Prevention are not side issues. They are the foundation.

If identity is weak, every AI answer sits on a weak account. If SharePoint is overshared, Copilot can make that oversharing easier to discover. If labels do not exist, users have no clear signal that a document is sensitive. If DLP is sitting in test mode forever, the business has a policy theatre problem, not a protection model.

I would rather see a small, controlled Copilot pilot in a tidy tenant than a broad deployment in a messy one. Start with a few users. Pick real scenarios. Meeting follow-ups in Teams. Draft replies in Outlook. Summaries from known SharePoint libraries. Then watch what happens. What worked? What surprised people? What data did Copilot find that no one expected?

Guardrails should be practical

The best guardrails are boring. That is a compliment.

Require MFA. Tighten external sharing. Review old guests. Publish simple sensitivity labels. Apply DLP where it matters. Use Restricted SharePoint Search where the content estate needs time to be cleaned up. Train users to verify answers before sending anything to a client. Make it normal to say, “Copilot drafted this, but I approved it.”

That is not anti-AI. That is responsible adoption.

The businesses that do this well will not be the ones with the flashiest prompts. They will be the ones that treat Copilot as part of their operating model. Policy, security, people and process all moving together.

My view is simple. Do not start with the licence. Start with the trust model. If you can trust the identity, the data, the permissions and the controls, then Copilot becomes much easier to use with confidence.

AI governance is not there to slow the business down. It is there so the business can move without pretending the risks are someone else’s problem.

The MSP Skills Gap Nobody Is Talking About Yet

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.

Retention Policies vs Retention Labels: The One Rule That Governs Both

Most Microsoft 365 tenants I look at have both retention policies and retention labels configured. Usually set up by different people at different times, with something like “applied for legal” in the ticket notes. Nobody documented which one wins.

That’s a governance problem. When your client’s solicitor asks why a document that should have been kept for seven years was deleted after three, “we had both configured” isn’t an answer.

Here’s what cuts through all of it: preserve always beats delete.

If any retention setting — policy or label — says retain, the content stays. A delete-only cleanup policy cannot overrule a retain policy. That’s the first principle of retention in Microsoft Purview, and it’s the one rule worth tattooing on your brain before you touch anything else.

What a retention policy does and what a label does, really

A retention policy is a net cast over an entire location. All Exchange mailboxes. All SharePoint sites. All Teams messages. You configure it once and it runs silently in the background. Users don’t see it and can’t override it.

A retention label is a tag applied to a specific item — a document, a folder, an email thread. Item-level control, which means exceptions. A label can be applied manually by a user, or automatically via content inspection rules.

They’re not competing tools. They’re two layers of the same system.

Microsoft’s overview puts it plainly: use a policy when everything in a location should be treated the same, use a label when you need item-level exceptions. Most mature tenants use both — a policy as the floor, labels as the ceiling.

Step-by-Step: Creating and publishing a retention label

Setting up a retention policy is straightforward: Purview portal > Solutions > Data Lifecycle Management > Policies > Retention policies > New. Labels take a few more steps because you create them first, then publish them separately.

Open the Purview portal and navigate to Labels

Go to Solutions > Data Lifecycle Management > Labels and select Create a label.

Name it and set the retention action

Give it a meaningful name — Contracts – Retain 7 Years is better than Label 3. Set the retention period and what happens at the end: retain only, delete after retention, or retain then delete. If the item needs to be declared a record, tick that here — it adds immutability.

Publish via a label policy

Labels don’t apply themselves. Go to Label policies > Publish labels, choose your label, and set the locations (SharePoint, OneDrive, Exchange). This makes the label available for users to apply manually in those apps.

Set up auto-apply

For most SMB clients, relying on users to apply labels manually doesn’t work. They won’t. Back in Label policies, choose Auto-apply a label, set your content condition — keywords, sensitive information types, or a trainable classifier — select the label, and let Purview do the tagging.

Allow up to seven days for labels to propagate to SharePoint and OneDrive. Don’t test immediately and assume it’s broken.

What actually happens when a policy and a label disagree

Say you have an org-wide Exchange retention policy that keeps email for three years and then deletes. And a specific retention label on a contract thread that says retain for seven years.

Which wins?

The label wins. Because it specifies the longer retention period (Principle 2: longest retention wins), and because a label is explicit — a deliberate decision about a specific item, not a blanket setting over a location (Principle 3: explicit beats implicit).

The old thinking: “We have a seven-year legal hold… somewhere. I think.”
The new reality: You can show exactly which items carry which label, when they expire, and prove it via the Purview content explorer.

A delete-only policy can only affect content that has no retain setting at all. It cannot shorten a label’s retention period. It cannot override a retain policy. Preserve always wins.

The MSP angle: adaptive scopes

Adaptive scopes are the part of retention most MSPs haven’t touched — and they make multi-tenant governance dramatically simpler.

Instead of pointing a policy at a static list of sites or mailboxes, you write a query. The scope dynamically targets whoever matches it, updated daily. A client with Finance retaining for ten years and Sales retaining for five no longer needs two separately maintained group memberships. You build two adaptive scopes off the Department attribute in Entra ID, and the policy follows the org chart automatically.

My recommendation? Start with an org-wide retention policy as your baseline. Add labels for the high-value exceptions — contracts, HR records, anything with a different period or a record declaration. Then look at adaptive scopes when you’re ready to stop maintaining static lists across every client tenant.

If you’re not showing clients that their data governance is this deliberate and this auditable, you’re leaving a genuine service conversation on the table.

Retention policies set the floor. Retention labels set the ceiling. Preserve always wins.