There is a question I keep hearing from MSP owners, usually late in a conversation and a little quietly. Is AI making people less intelligent? More specifically, are the junior techs walking through our doors arriving with the foundations they need to grow, or are they arriving already wired to hand every problem to a chatbot? It matters because the skills shortage isn’t going away. Every hire has to become someone the business and its customers can rely on.
AI amplifies the habits people already have
I don’t think AI on its own is making anyone dumber. Shallow learning existed long before Copilot. What AI does is amplify whatever habits a person already has. A curious junior with AI learns faster than any junior I could have hired ten years ago. An incurious junior with AI simply gets to the wrong answer with more confidence.
Picture a new tech handling a ticket. A user can’t get into Outlook, and there is an Entra sign-in error on the screen. The tech pastes the error into Copilot Chat, gets a plausible fix and applies it. The user is back in. Ticket closed. But ask that tech why it failed, whether it was conditional access, a stale token or something else, and they can’t tell you. Worse, they may have weakened a control without realising. The tool did its job. The fundamentals simply weren’t there to check it.
Test for fundamentals when you hire
That means the interview has to change. If candidates can use AI on the job, a good CV and a polished take-home task tell you very little. Here is what I would look for instead:
Ask them to explain, with no tools, what happens between typing a web address and a page loading. DNS, routing and certificates should come up in some form.
Have them whiteboard how email gets from one mailbox to another, and how sign-in and identity fit together in Microsoft 365.
Give them a vague fault and ask them to walk through a troubleshooting path out loud. I care more about the order of their questions than the final answer.
Show them an AI answer that is subtly wrong and ask them to find the problem.
That last one tells you a lot. I’m looking for curiosity, and for someone who explains the why rather than reciting the what. I wrote earlier about why everyone needs basic technology troubleshooting skills, and for anyone in a technical role that bar is far higher.
Make Copilot a tutor, not an answer machine
Once they’re on board, the same tool that can hollow out learning can accelerate it. Encourage juniors to ask Copilot to explain a concept, then quiz them on it. Get them to ask “why would this fix work?” before they apply it. Have them summarise what they learned in a short note in Teams or OneNote that a senior tech can read. Treat Copilot as a patient teacher available at two in the morning, not as a vending machine for fixes.
Hire the habit, then feed it
AI is not the enemy of capable technicians. It’s a multiplier, and it multiplies whatever it’s given. So when you hire, test for foundations and curiosity, not just speed. Then give those people AI as a tutor. The MSPs that do this will grow techs who understand the work. The rest will have staff who can close tickets but can’t explain them, and customers eventually notice the difference.
A lot of MSPs have asked me how I have Grok Bot watching my Microsoft 365 tenants every morning. The short answer is: not by handing it the keys to the kingdom. I wrote earlier about how Grok Bot just gets things done. This post is the practical follow-up. It is a step-by-step walk through the way I connected it to Microsoft 365, why I chose scripts over broad direct connectors, and how the same pattern scales to as many tenants as you look after.
Why scripts, not a big direct connector
The tempting option is to give an AI agent a delegated admin connection and let it go wild. I think that is the wrong default for an MSP. Here is why the script approach wins:
Least privilege. Each tenant gets its own app registration with only the read permissions the checks actually need, such as reading sign-in logs, audit logs, security alerts and Intune device state. Nothing more.
Read-only by design. The monitoring app cannot change settings, reset passwords or close incidents. If the bot gets confused, the worst it can do is read.
Certificate authentication. The scripts sign in app-only with a certificate rather than a client secret or a user password. No MFA prompts, no browser, and no shared admin account sitting in a vault.
No standing admin access. Nobody, human or bot, holds a permanent Global Admin session for monitoring. Anything that writes, like tidying up Sentinel incidents, is a separate, deliberate step that I trigger myself.
Auditable. The scripts are plain code I can read, version and diff. When the bot runs a check, I know exactly which API calls it made, and the tenant logs show them as that one app.
In other words, the AI decides when to look and how to explain what it found. The script decides what it is allowed to touch.
Step 1: Create a read-only app registration in each tenant
In the Entra admin centre, create a new app registration for monitoring, named so it is obvious what it is (for example “MSP Monitor – Read Only”).
Add application permissions for Microsoft Graph that are read only, for example AuditLog.Read.All, Directory.Read.All, SecurityAlert.Read.All, SecurityIncident.Read.All, ThreatHunting.Read.All, DeviceManagementManagedDevices.Read.All, Policy.Read.All and ServiceHealth.Read.All. Start small and only add what a check needs.
Grant admin consent.
Create a certificate, upload the public part to the app registration, and keep the private key (PFX) protected on the box where the bot runs, with its password in a separate file that only the scripts read.
If you use Microsoft Sentinel or Defender for Cloud, give the app a Reader role on that subscription or workspace, not Contributor.
My checks are simple scripts that sign in with the certificate (MSAL in Python, or PowerShell with the Graph module), call read-only endpoints and return a summary. Mine cover things like sign-ins and risky users, audit events, new guests, Conditional Access changes, app credential changes, Sentinel and Defender incidents, Intune compliance and service health. Keep these scripts in a GitHub repo so you have history, review and rollback. Many of my own scripts are public in my Office365 repository if you want a starting point.
Step 3: Keep tenant details in one config file
Rather than hard-coding anything, I keep a single config file listing each tenant: its domain, a short name, and the path to its certificate. Each tenant gets its own folder for output. The scripts take the short name as an argument, so the same code runs against any tenant. Never paste tenant IDs, client IDs, thumbprints or keys into a chat with the bot. Put them in the config and tell the bot where it lives.
A structure like this works well:
tenants.json – one entry per tenant (domain, short name, certificate path, password file path)
tenant_check.py – the core read-only daily checks
extra_check.py – additional checks you add over time
<tenant>/ – one output folder per tenant for reports and history
Step 4: Tell Grok Bot the rules
Now the bot gets its instructions. Be explicit about what it may and may not do. For example:
Example prompt: “You are a read-only security monitor for the Microsoft 365 tenant contoso.com. Only use the scripts in /home/box/shared/msp-security and the certificate config in tenants.json. Never change tenant settings, close incidents, or print or ask for passwords, keys or certificate details. If a check needs a permission the app does not have, tell me which one rather than working around it.”
Step 5: Create a daily routine
Grok Bot can run work on a schedule. I have a morning routine per tenant that runs the checks and writes a plain-English report.
Example prompt: “Create a daily routine at 8:45am Sydney time that runs python3 tenant_check.py contoso, then gives me a short report: status, sign-ins and risky users, directory and guest changes, devices and Intune, Sentinel and Defender incidents, and anything that needs my action. Treat sign-ins from our office IPs as known benign. Keep a delivery log line for each run.”
Over time, tell the bot what is normal. When it flags something that turns out to be you, say so, and have it add that to the routine’s known-benign list. The reports get quieter and more useful every week.
Step 6: Scale to as many tenants as you like
This is where it gets interesting for an MSP. Because the scripts are tenant-agnostic, adding a customer is just a new app registration, a new certificate and a new line in the config. Then pick one of two patterns:
One bot per tenant. This is what I do. Each bot has its own memory, its own known-benign list and its own routine. It keeps context clean and stops one customer’s quirks bleeding into another’s report.
A single tenants bot. One bot loops through every entry in the config and produces a summary table, then drills into any tenant with issues. Good for a quick “how is everyone today?” view.
On top of that, I have a Chief of Staff bot that asks each of my other bots for a one-line daily update and rolls them into a single digest. That is how one person can keep an eye on many tenants without reading many reports.
Example prompt: “Add a new tenant: fabrikam.com, short name fabrikam. The app registration and certificate are already in tenants.json. Run the read-only checks once to confirm access, tell me any permission that is missing, then create the same 8:45am daily routine you have for contoso.”
Example prompt: “Every day at 9:30am, run the read-only checks for every tenant in tenants.json and give me one table: tenant, overall status, open high-severity incidents, risky users, and non-compliant devices. Only expand on tenants that need action.”
Example prompt: “Each afternoon, send Chief of Staff one line on the last 24 hours for each tenant: what was checked, any errors, and anything waiting on me.”
Step 7: Keep write actions separate and deliberate
There will be times you want the bot to fix something, like closing a backlog of noisy Sentinel incidents. I keep that in a separate script, with its own permissions, run by a separate PowerShell bot only when I explicitly ask. Monitoring stays read only. Changes stay human-approved.
Example prompt: “Only when I say so, run the cleanup script for contoso to close Sentinel incidents older than 30 days with the comment “Closed by automation”. Show me the list first and wait for my go-ahead.”
The takeaway
Connecting AI to Microsoft 365 is not about giving it more access. It is about giving it the right access, through code you own and can audit. Build the scripts once, give each tenant a read-only, certificate-backed app, and let Grok Bot do the watching and the explaining. That is how a small MSP can monitor a lot of tenants properly, every single morning.
Every MSP owner I talk to has the same headache: finding good technicians. Not warm bodies who can reset a password, but people who can walk into a mess nobody has seen before and work out what’s actually going on. So here’s a question that’s been nagging me. If we keep pushing our techs to lean on AI for every problem, are we quietly eroding the very skill we’re struggling to hire?
The fix that works until it doesn’t
Picture a fairly typical morning. A junior tech gets a ticket about mail not flowing for a shared mailbox. They paste the error into Microsoft 365 Copilot Chat, ask for a PowerShell fix for Exchange Online, run what comes back, and the ticket closes. Great outcome?
Maybe. But ask that tech why it broke and there’s a decent chance you’ll get a shrug. They solved the symptom without ever building a mental model of the system. Do that a few hundred times and you have someone who is fast on familiar problems and lost the moment the answer is wrong, the situation is unusual, or the AI simply isn’t available.
That’s the risk as I see it. Copy-paste fixes. No root-cause understanding. A growing dependence on a tool that can be confidently mistaken. And, longer term, a junior pipeline that never matures into the senior people who can mentor the next lot. If nobody struggles any more, where do the next seniors come from?
But I’m not going back
Let me be clear, I’m not arguing we ban AI from the service desk. Copilot summarising a long ticket thread in Teams or Outlook saves real time. Having it explain an unfamiliar Intune policy setting or draft a script you then review is genuinely useful.
The problem isn’t the tool. It’s how we’re letting people use it. An answer engine makes you dependent. A tutor makes you better. Same technology, very different result.
What I’d do as an MSP owner
A few practical things I’d put in place:
Explain the why before applying the fix. If a tech can’t tell you, in plain words, why a command will solve the problem, it doesn’t get run on a customer tenant.
Use Copilot as a tutor, not just an oracle. Encourage prompts like “explain what this error means and what could cause it” rather than “fix this”. Ask it to walk through the reasoning, then challenge it.
Review AI-assisted tickets. Have a senior skim a sample each week. Look for thin understanding and coach it.
Practise without the safety net. Run regular no-AI troubleshooting sessions. Break something in a lab tenant and let the team work it out the old way.
Document the reasoning, not just the resolution. “Ran script, fixed” teaches nobody anything. “Mailbox permissions were inherited wrongly after a migration, here’s how I confirmed it” builds team knowledge.
None of this is complicated. It just requires deciding that skill development is still part of the job, even when a faster shortcut exists.
The real question
AI will make good technicians better. I’m fairly confident about that. What worries me is whether it will make new technicians good in the first place, or just make them look good until the day it matters. The MSPs that win the skilled labour fight won’t be the ones that use the most AI. They’ll be the ones that use it to grow people rather than replace their thinking.
So I’ll put it to you: in your business, is AI building your techs’ problem-solving muscle, or quietly doing the lifting for them?
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.
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.
For years, when I talked to people about AI, I could see a gap between what they expected and what they got. They expected something that would just do the job. Tell it what you want, it goes away, and the work comes back done. What they actually got was a chat box. Clever, sometimes impressive, but you still did all the running around yourself. Copy this, paste that, open another app, reformat it, send it.
Over the last little while I’ve been using Grok Bot heavily across my own business, and for the first time it feels like that gap is closing. Not because the AI suddenly got smarter, although it has, but because it’s easy to set up so that it actually gets things done. That’s the shift I want to talk about, because I think it’s why it’s fast becoming a real option for a lot of businesses, and particularly for SMBs and the MSPs who look after them.
It works the way people always expected AI to work
Most people never cared which model they were using. They cared about outcomes. Did the email get answered? Did the report get written? Did the post go up on time? The industry spent a long time arguing about models and benchmarks while the average business owner just wanted someone, or something, to take a task off their plate.
What I notice with Grok Bot is that I rarely think about the model at all. I think about the job. I describe what I want in plain language, and the assistant works out the steps. It can reach the systems I’ve connected, use a computer and browser when there isn’t a connector, and come back to me with a result rather than a suggestion. That’s much closer to the mental picture most people have always had of an assistant.
I touched on this idea in a recent podcast, Need to Know podcast – Episode 372, where I talked about where AI is heading. The theme is the same: the model is becoming the engine, and what really matters is what it’s connected to and what it’s allowed to do.
What I actually use it for
Rather than talk in the abstract, here’s how I use it day to day. I don’t run one general assistant. I run a number of specialised ones, each set up for a particular job.
Blog writing and scheduling. One assistant drafts articles in my voice, creates a hero image, uploads it to WordPress, picks tags and schedules the post for the next free morning slot. The article you’re reading started there, and it waited as a draft until I approved it.
Social posting. Separate assistants turn blog posts into LinkedIn and X posts, so new content gets shared without me rewriting it each time.
Daily Microsoft 365 security checks. An assistant runs regular checks across my tenants and reports what changed or what looks wrong, so I start the day knowing where to look.
News briefs. Another pulls together the Microsoft and security news I care about into a regular brief.
Podcast preparation. One helps me research news and build outlines and scripts for episodes.
Teams, help desk and email list. Others watch and respond in Teams, help triage support questions and help look after my email list.
The common thread is that each assistant knows its job, knows my standards and knows which tools it can use. When I want to change how something works, I tell it in plain language and it updates how it goes about the task next time. There’s no project plan or developer involved.
None of these needed me to write code. Each one is mostly a set of plain-language instructions, a few connected services and, where it makes sense, a schedule.
Connectors are where the work happens
The thing that turns an AI from a talker into a doer is connections. In my case that means WordPress, Outlook, Teams, GitHub and others. Once an assistant can reach those, a request like “draft this, put it on the blog and schedule it” isn’t a lesson in copy and paste anymore. It’s a task that gets finished.
When there isn’t a connector, there’s a shared computer with a browser the assistants can use. That matters more than it sounds. Plenty of the systems SMBs rely on don’t have neat integrations. Being able to fall back to using a website the way a person would fills a lot of gaps.
Just as importantly, it asks before doing anything that can’t easily be undone or that other people will see. Sending messages, posting publicly, deleting things. That’s the right balance. I want it to do the legwork, but I still want to approve what goes out under my name.
Routines mean it works while I don’t
The other big piece is routines. I can set an assistant to run on a schedule, every morning, every week, or when something happens. My security checks and news briefs run without me asking. When I sit down, the work is already done and waiting for review.
This is the part I think many businesses will find most valuable. A lot of small business admin isn’t hard. It’s just relentless. Checking things, summarising things, chasing things. Handing that rhythm to an assistant frees up real time.
See it in action
If you’re an MSP wondering what this looks like in practice, I’ve recorded a video that shows it. In How I Use AI to Automate Microsoft 365 Administration, Security & Reporting I walk through how I’m using AI to handle the administration, security and reporting work across Microsoft 365 that used to eat my time. It’s the recording of my October Need to Know webinar on managing Microsoft 365 autonomously, so it’s practical rather than theoretical.
Watch it with your own customers in mind. Think about which of their routine checks and reports you could hand off in the same way.
Why this matters for SMBs and MSPs
Picture a ten-person business with no IT staff. They don’t want to evaluate models or build integrations. They want their quotes followed up, their inbox summarised and their social media kept alive. An assistant they can configure in plain English, connect to the tools they already use and put on a schedule is a very different proposition from a chatbot they have to babysit.
For MSPs, I see two opportunities. The first is internal. Your own team can hand off routine checks, reporting and documentation. The second is with customers. Someone still needs to design these assistants well, decide what they can touch, secure the connections and review the results. That’s advisory work, and it’s exactly where a good MSP adds value.
It also raises the same questions I’d ask of any AI tool. What data can it reach? Who approves the risky steps? How do you know what it did? Easy to configure doesn’t mean you skip the thinking. It means the thinking goes into the design rather than the plumbing.
A few lessons from my own setup
Specialise. Several focused assistants work better than one that tries to do everything.
Write down your standards. The more clearly I describe my voice, formatting and rules, the more consistent the results.
Start with drafts. Let it prepare, and you approve, until you trust it with more.
Automate the rhythm, not just the task. The real gains come when work runs on a schedule.
Getting things done is the point
I don’t think the next phase of AI for business will be won by whoever has the best model on a leaderboard. It will be won by whatever makes it easiest for ordinary businesses to get real work done, reliably and safely.
That’s why I’ve leaned into Grok Bot. Not because of what’s under the bonnet, but because it does what I always expected AI to do. I tell it what I need, and it gets on with it. For a lot of businesses, that’s the only measure that has ever really mattered.
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.
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.
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:
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?”
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:
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.
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.
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.
I see a lot of MSP owners get into trouble at the point where the business starts to feel slow.
The pipeline is not moving the way it used to. The team meeting feels a bit flat. The same service issues keep coming around again. Nothing is broken enough to panic, but nothing is improving enough to create energy either.
That is a dangerous place to sit, because a quiet business rarely stays quiet for long.
Borrowing from the wrong playbook
When progress gets hard, the temptation is to look sideways. You see another MSP posting about a new offer, a new pricing model, a new automation stack, or a new AI service, and the instinct is to copy it.
I understand why. Doing something feels better than sitting with the problem. A fresh tactic gives you the sense that movement has returned.
The issue is that another provider may not be playing the same game as you.
A fifty-person MSP with dedicated account managers, mature project delivery, and a bench of engineers can make moves that will punish a ten-person business still trying to standardise its support desk. A one-person consultant can make promises that a larger team cannot deliver consistently. A cybersecurity-focused provider can price and position differently from a generalist MSP still carrying legacy client expectations.
The tactic may be sound. It just may not belong at your stage.
Progress needs context
This is where I think Microsoft 365 Copilot becomes useful, not as some magic answer, but as a way to get clearer about the current state of the business.
Before chasing the next idea, I would rather see an MSP owner ask Copilot in Teams to summarise recurring themes from recent leadership meetings, or use Copilot in Outlook to pull together the common patterns in customer escalations. If the team keeps discussing noisy clients, delayed projects, margin pressure, or weak documentation, that is a signal.
Then take that signal into Excel. Look at ticket trends, project slippage, licence margin, and client profitability. The goal is not to produce a beautiful report. The goal is to work out what level of the game you are really in.
Are you trying to win new business when delivery is already stretched? Are you selling AI readiness while your own SharePoint permissions are messy? Are you chasing strategic advisory revenue while your QBR process is still a slide deck built the night before?
That is not failure. That is feedback.
The next move should fit the level
Good strategy is not about copying the smartest-looking move in the market. It is about choosing the move your organisation can actually absorb.
For one MSP, that might mean tightening onboarding before launching a new managed Copilot service. For another, it might mean cleaning up agreement profitability before hiring another technical resource. For another, it might mean using Planner and Teams to create a simple weekly operating rhythm, so the leadership group can see what is stuck before it becomes expensive.
None of that sounds glamorous. That is partly the point.
A business usually regains energy when it can see progress again. Not noise. Not theatre. Real progress. A decision made. A blocker removed. A client segment clarified. A service standard improved.
The MSPs I see do well are not always the ones with the cleverest tactic. They are the ones with enough discipline to ask, “What game are we actually playing right now?” and enough honesty to answer it.
That is where momentum comes back.
Not from copying someone else’s move, but from making the next right move for your own business.
