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.

Scout, Now Autopilot: How Microsoft’s Always-On Agent Really Works

Cartoon of a woman standing on a stack of documents looking through binoculars and guiding her colleagues forward

Most workplace AI I use still sits there politely, waiting for me to type something. Microsoft Scout is different, and that’s exactly why I think MSPs and SMBs need to understand how it works before someone in the business goes looking for the download link.

Quick housekeeping first. Microsoft introduced Scout at Build in June 2026 as its first “Autopilot” agent. On 25 September it renamed the product itself to Autopilot, describing it as “previously called Scout”. Yes, same name as Windows Autopilot, the device provisioning service, which is entirely unrelated. The docs still say Scout, so I will too.

So what is it, really?

Scout is an agent that works on your behalf without being prompted every time. The current Frontier release is a desktop app for Windows 11 and macOS. You describe a task in a chat, Scout picks the tools it needs, works through the steps visibly, pauses for your approval on sensitive actions, then hands back the result or saves files to your workspace.

The tools are the interesting bit. Scout can read and write files in an approved workspace folder, run shell commands, drive a browser to fill in forms, and connect to Microsoft 365. That covers Outlook mail and calendar, Teams chats, meetings and transcripts, SharePoint Lists, and files in OneDrive, SharePoint and Teams. It creates Word, Excel and PowerPoint files, remembers your preferences and can spin up parallel sub-agents.

What makes it “always-on” are two background modes. Heartbeat runs check-in prompts every 15 to 120 minutes while you’re away, and Automations run on schedules or triggers you define. The September announcement goes further: Autopilot becomes cloud-hosted, with its own identity, memory and workspace inside your tenant, and you @mention it in Teams, Outlook and documents like a colleague.

Under the hood it’s built on open-source OpenClaw, with Microsoft adding Entra identity and access controls on top.

The permissions story is where you need to pay attention

Scout operates with the user’s existing Microsoft 365 permissions. It can’t see anything the user can’t. That sounds reassuring until you remember how many SMB tenants I see with broad sharing links scattered across SharePoint. An agent that tirelessly works through everything a user can reach will find your oversharing faster than any auditor.

There’s a finer detail buried in Microsoft’s own Responsible AI FAQ. In the Frontier desktop app, model interactions are processed through GitHub Copilot, under separate terms. When that happens, some Microsoft 365 protections, such as data residency, retention, sensitivity label enforcement and eDiscovery, don’t apply to that processing. That’s why admins must complete an attestation before anyone can use it. Read that page before you tick the box.

Getting access is deliberately fiddly. You need Frontier turned on in the Microsoft 365 admin centre, an Intune policy on devices, the attestation form, and a GitHub Copilot Business or Enterprise seat for each user. Miss any one of those and sign-in fails without a clear message, which will make for entertaining helpdesk tickets.

How I’d approach it

Treat this as a pilot for a handful of technically capable people, not a rollout. Clean up permissions and sharing first. Keep the approval prompts on and resist the temptation to click “Always allow”. Lock down heartbeat and automation permissions tightly, because those run when nobody is watching. And budget carefully: Microsoft says Autopilot runs on usage-based billing, not the fixed Copilot licence.

I genuinely think agents that follow through are where this is heading. But an assistant that acts is a very different beast from one that answers. The organisations that do well here will be the ones that realised their governance needed to be ready before the agent arrived, not after.

Sources: Microsoft Scout overview (Microsoft Learn), Responsible AI FAQ, Admin access overview, Introducing the new Copilot with Home, Code and Autopilot

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?”

New script: Check your Microsoft 365 tenants for ConnectWise SkyKick exposure

Security analyst reviewing a Microsoft 365 tenant exposure report in a dark operations room

I’ve just added a new script to my Office365 repository on GitHub: cw-skykick-exposure-check.ps1. It does a read-only check of Microsoft 365 and Entra tenants for signs of exposure to the ConnectWise Cloud Backup (formerly SkyKick) vendor-credential incident, and produces a report you can act on.

If you’re an MSP with ConnectWise or SkyKick apps consented in customer tenants, you want answers quickly and across every tenant, not one portal click at a time. That’s what this is for.

What happened

According to Huntress’s advisory, a Microsoft 365 credential belonging to ConnectWise Cloud Backup was compromised and used on 15 October 2026 (UTC) to obtain Microsoft Graph tokens in customer tenants. Huntress also reports that in at least one tenant a ConnectWise Cloud Management app granted itself Global Administrator and added new secrets to other applications to keep a foothold. ConnectWise has acknowledged the incident. Huntress’s guidance is to disable (not delete) the affected apps, review the credentials on all your applications, and check service principal sign-ins and audit logs.

That review is exactly what the script automates.

What the script checks

For each tenant it runs four checks, then gives a verdict:

ConnectWise/SkyKick service principals: matched by seven known app IDs, display name or the ConnectWise owner tenant, with enabled state, directory roles, OAuth2 grants and app role assignments. A match holding a highly privileged role is flagged.
Service principal sign-ins since 1 October 2026 for those apps and the published indicator IP addresses, flagging indicator IPs and Python or curl user agents. This needs Entra ID P1 or P2.
Directory audit events since 13 October 2026 (role additions, application updates and new service principal credentials), plus a scan of every app registration and service principal for secrets or certificates whose validity starts in that window.
Conditional Access exclusions that cover the ConnectWise apps.
Verdict: Suspicious, Present-no-activity, Not present, Unknown or Error, with recommended actions.

It is strictly read-only. Every Graph call goes through a wrapper that only issues GET requests, so it never creates, changes, disables or deletes anything. If a check can’t run because of licensing or permissions, it’s reported as Unavailable rather than crashing, and one tenant failing never stops the rest.

How to run it

You’ll need PowerShell 7.4 or later and the Microsoft.Graph.Authentication module, plus read permissions: Application.Read.All, Directory.Read.All, AuditLog.Read.All, RoleManagement.Read.Directory and Policy.Read.All. For a single tenant with an interactive sign-in:

./cw-skykick-exposure-check.ps1 -TenantId contoso.onmicrosoft.com -UseDeviceCode

For many tenants unattended, supply a CSV of TenantId, ClientId and a certificate thumbprint or PFX path, with the PFX password injected through an environment variable. It’s the same certificate-based, app-only approach I described in my recent post on headless connections.

./cw-skykick-exposure-check.ps1 -TenantCsv ./tenants.csv -OutputPath ./reports

Each run writes three reports: a CSV with one summary row per tenant, a detailed JSON file, and a readable HTML report with times in Sydney time.

Read the results carefully

This is an investigation aid, not a forensic verdict. Not present means the checks found none of the configured matches; it doesn’t prove a tenant was never touched. Graph doesn’t expose when a credential was actually created, only when it becomes valid, so confirm every flagged secret or certificate was added by your team. And review the indicators and date windows against the latest advisories before you rely on them.

Get the script

Script: cw-skykick-exposure-check.ps1
Documentation: ConnectWise SkyKick Exposure Check wiki

Run it against a test tenant first, then across your customers. If you find a bug, a missed indicator or a way to make it better, let me know. Feedback from people running it in the real world is what makes these scripts better for everyone.

New scripts: Headless SharePoint and Exchange Online connections on Linux, built for agents

Cartoon of a relaxed IT professional with a coffee while a laptop and small server work on their own

I’ve just added two new scripts to my Office365 repository on GitHub. One connects PowerShell to SharePoint Online using PnP PowerShell. The other connects to Exchange Online. Both run on Linux, and both use certificate-based, app-only authentication. There’s no browser, no typed password and no MFA prompt at connection time.

Why bother building Linux versions? Mostly because of agents.

Built for machines that nobody is sitting at

More and more of my admin work now gets done by autonomous agents like Grok Bot, running on a Linux computer that no person is logged into. An agent like that can write and run PowerShell happily enough. Where it gets stuck is sign-in. A pop-up browser window, a device code that someone has to type in, or an MFA approval on a phone all stop it in its tracks. Automation that needs a human to tap “approve” isn’t really automation.

Certificate-based app-only authentication fixes that. You register an app in Entra, upload the public half of a certificate, keep the private key on the machine, and the script connects as the app. I’ve covered the Windows side before in Certificate-Based Authentication for SharePoint Online: The Bit Everyone Avoids and A Cleaner Way to Connect PowerShell to Exchange Online. These new scripts are the Linux counterparts, built so an agent’s computer can connect and get on with the job unattended.

What the scripts do

Both scripts work the same way and have two main modes:

-GenerateLocalCertificate creates an RSA-2048/SHA256 certificate, a public .cer file and an encrypted .pfx using .NET, so you don’t need OpenSSL.
-UseCertificateAuth connects with the encrypted PFX: PnP.PowerShell for SharePoint, ExchangeOnlineManagement for Exchange.
-ProvisionEntraApp (optional) creates or reuses an Entra app, uploads the public certificate, grants the required permissions and saves a connection profile. This setup step uses a one-off device-code sign-in by an administrator.

For true headless runs, use -noprompt (alias -Headless). Supply the PFX password through a SecureString parameter, or name an environment variable with -CertificatePasswordEnvironmentVariable. The scripts never print or save that password. Saved profiles mean that, once set up, an agent can connect with little more than -UseCertificateAuth -ProfileName Contoso -Headless.

You’ll need Linux and PowerShell 7.4 or later (7.4.6+ for the PnP script), plus PnP.PowerShell 3.0.0+ or ExchangeOnlineManagement 3.5.0+. Missing modules install for the current user, with no sudo needed. Use -noupdate to skip update checks.

A word on security

Unattended access is powerful, so treat it with respect. The SharePoint provisioning grants Sites.FullControl.All, which means full control of every site. The Exchange provisioning grants Exchange.ManageAsApp and adds the app to Organization Management, which means full Exchange administration. The scripts keep certificates and profiles in dedicated folders locked to mode 700, with files at mode 600, and they refuse symbolic links there. Even so, that .pfx is effectively an admin key. Guard it, keep its password in a vault or a protected environment variable, and only put it on machines you trust. If your scenario needs less, trim the app’s permissions.

Get the scripts

SharePoint (PnP): o365-connect-pnp-cert-linux.ps1, documentation
Exchange Online: o365-connect-exo-cert-linux.ps1, documentation

To me, this is where Microsoft 365 administration is heading. More of the routine work will be done by agents on machines that nobody watches, and the bottleneck is getting them connected securely without a human in the loop. Take the scripts, try them in a test tenant, and let me know how you go.

Your Skills Files Are Business IP

I keep seeing businesses get excited about building reusable prompts, agents, SOPs and skills.md files. Fair enough. That is where the real value starts to appear. Not in one clever prompt, but in documenting how the business works and making that repeatable.

But there is a quiet problem underneath it.

The better those files become, the more they stop being “documentation” and start becoming business intellectual property. A well-written skills.md file may contain how you scope jobs, respond to clients, handle exceptions, use Microsoft 365 Copilot, build proposals, or deliver a managed service consistently. That is not just a file. That is your operating model written down.

And yet, in many businesses, that content sits in a SharePoint library or Teams channel where almost everyone can read it, copy it, sync it, or forward it.

Convenient? Yes. Sensible? Not always.

The process library is now crown-jewel data

Businesses normally think about sensitive data as payroll files, contracts, financial spreadsheets and customer records. Those still matter. But AI changes the definition of what is valuable.

If your business has spent months refining reusable skills, prompts, checklists and delivery playbooks, then you have created a process asset. It explains how your business turns knowledge into outcomes. That deserves proper governance.

I am not saying every user should be locked out. The point of documenting processes is that people can use them. But there is a difference between “available to the team that needs it” and “available to anyone who inherited access from a Team created three years ago”.

That distinction matters when these files become grounding material for Copilot or custom agents. If Copilot can find the content, summarise it and reshape it quickly, then poor permissions become easier to exploit.

Copilot is not the leak. Oversharing is.

Access should match the work

The first control is boring and important: permissions.

Store these files in a dedicated SharePoint site or library. Do not scatter them across personal OneDrives, random Teams channels, email attachments and old project folders. Give the library an owner. Use Microsoft 365 groups or Entra ID security groups to control access. Review membership regularly.

The test I like is simple. If someone left tomorrow and joined a competitor, what could they still download today?

That question cuts through wishful thinking.

Some people need edit rights. Most only need read rights. Some only need access to the process area they work in. If everyone has everything, you do not have knowledge management. You have a shared filing cabinet with the front door open.

Labels and DLP are not decorations

This is where Microsoft Purview matters.

Apply sensitivity labels to the process library. A label like Confidential – Internal Process can make the handling expectation clear and drive protection such as encryption and access restrictions where appropriate.

Then add Data Loss Prevention policies around the same content. If someone tries to email a bundle of process files externally, copy them into chat with an outside party, or move them into unmanaged locations, you want friction, warning, logging, or blocking depending on the risk.

This is not about distrusting staff. It is about recognising that staff move on, mistakes happen, and valuable business knowledge should not be one drag-and-drop away from leaving the organisation.

Offboarding is too late

Many businesses only think about this when someone resigns. By then, the files may already be synced locally, copied into another tool, or forwarded elsewhere.

The right time to protect process IP is when the library is created. Classify it. Restrict it. Monitor it. Review it. Make access part of onboarding and removal part of offboarding.

If you are building AI skills for your business, treat them as assets, not notes.

The future advantage will not belong to the business with the most prompts. It will belong to the business that protects, improves and governs the way it works.

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.

The Login Screen Looks Simple. The Decision Behind It Is Not.

I worry that sign-in security is still treated like a mystery box in too many Microsoft 365 environments.

A user enters a password. Something happens behind the scenes. Maybe MFA appears. Maybe Conditional Access blocks the request. Maybe the sign-in works because the policy did not apply as expected. Then, when something goes wrong, the first question is usually, “Why did Microsoft let that happen?”

That is the wrong question.

The better question is: did we understand the path that sign-in actually took?

That is why I like simple visual tools such as the Microsoft 365 login simulator. Not because they replace proper testing in Entra. They do not. I like them because they make the invisible visible. They let people walk through authentication logic without starting inside a dense admin portal.

Authentication is where theory meets reality

Most businesses think they have secure login because they have MFA turned on. That is a start, but it is not the full story.

In the real world, sign-in decisions are messy. A user might be on a managed device, a personal laptop, or public Wi-Fi. They might be coming from a known location, a strange location, or through a service that does not behave like a normal browser session.

This is where Microsoft Entra ID, Conditional Access, MFA, device compliance and sign-in risk start to matter. They are not isolated controls. They are a decision chain.

For an MSP, that chain needs to be explainable.

I have sat in enough client conversations to know that saying “we enabled MFA” does not always land. A business owner wants to know what happens when an account is attacked. A help desk person wants to know whether the issue is identity, device, location, policy, licensing or behaviour.

A simulator gives you a conversation starter. It turns the abstract into something you can point at.

Copilot still depends on identity hygiene

Microsoft 365 Copilot does not remove the need for clean identity controls. If anything, it raises the stakes. When someone asks Copilot in Teams to summarise a channel, or uses Copilot in Word to draft from files in SharePoint, the experience depends on the access that user already has.

That means sign-in is not just a security event. It is the front door to organisational knowledge.

If a compromised account gets through that front door, the issue is no longer just email. It may include documents, chats, meetings and shared files. For an SMB, that is a business risk, not a technical footnote.

So when I look at a login simulation, I am thinking about what the user can reach after access is granted.

Use the simulator to teach judgement

The best use of a tool like this is not to frighten people. It is to build judgement.

Run through a few scenarios with a client or your own team. What should happen for a global administrator? What should happen for a user on an unmanaged device? What should happen for a login from a location the organisation never normally uses? Where does the policy catch the risk?

Then compare that ideal path with what your tenant is configured to do.

That gap is where the work is.

For MSPs, this is a better advisory conversation. You are not just selling another security setting. You are helping the client understand how identity, access and data exposure connect. That moves the discussion away from checkbox compliance and towards resilience.

My view is simple. If you cannot explain the sign-in path, you probably do not control it as well as you think.

The login screen looks simple. The decision behind it is anything but.