A question came up recently in my Patrons community that I think lots of MSPs will hit as agents move into tenants. If you have a Conditional Access policy that geo-blocks sign-ins from outside Australia, it will block Grok Bot. I use Grok bots throughout my own Australian tenant, so here’s a summary of what I shared about how to handle it without throwing away your geo policy.
Why it happens
Grok Bot works from cloud infrastructure, not from your desk. When it signs in or refreshes a token for your account, Entra ID sees an IP that isn’t in Australia, so your geo-block policy does exactly what you told it to. Conditional Access works out location from the client’s public IP. There’s no published egress IP list, so don’t guess ranges.
Start by confirming what’s being blocked. In the Entra admin center open Sign-in logs, filter on the account and Status = Failure, then check the Location, IP address, Application and Conditional Access tabs. That shows which policy blocked it and from where.
Option A: a dedicated bot account, excluded and compensated
This is the most practical option and my pick for most SMB tenants.
Run the bot under its own account, not your daily admin identity, with only the licences and access it needs.
Put that account in a small, named group, such as CA-Exclude-Geo-GrokBot, and exclude only that group from the geo-block policy. Keep every other policy applied.
Compensate with phishing-resistant authentication strength for that account, and a sign-in risk policy if you have Entra ID P2.
Review its sign-ins regularly and use an access review so the exclusion doesn’t live forever.
Option B: trusted named locations
If a vendor publishes fixed, stable egress IPs, you can add them as an IP-range named location and exclude that location. Without a documented list this isn’t an option, and never add whole cloud provider ranges.
Option C: app-only access and workload identities
If the bot or connector lets you plug in your own app registration, it can use the OAuth 2.0 client credentials flow with application permissions. No user signs in, so user-targeted Conditional Access isn’t evaluated. That’s the upside, and also the risk. If you go this way:
Register a single-tenant app and grant only the Graph application permissions the job needs, e.g. Mail.Send rather than Mail.ReadWrite, Sites.Selected rather than Sites.ReadWrite.All.
Use a certificate, not a client secret, stored in Azure Key Vault with a short lifetime and scheduled rotation.
Scope it down with RBAC for Applications in Exchange Online and Sites.Selected in SharePoint.
Use Conditional Access for workload identities to block the service principal from unknown locations or when it’s flagged risky. This needs Workload Identities Premium and only covers single-tenant service principals.
Monitor Service principal sign-ins and turn on workload identity risk detections.
The trade-offs are real. Most bot connectors use delegated sign-in, so this only works if the bot supports it. A leaked credential can reach across the tenant with no MFA in the way, and audit trails show the app, not a person.
What about a local PC or Global Secure Access?
Routing through a local computer only helps for work the bot runs on that machine. Its cloud connectors still sign in from the cloud, so at best it’s a partial fix. Entra Global Secure Access is great for people and managed devices, but a cloud-hosted bot can’t run the GSA client, so treat it as an extra layer for your people.
Test, and what not to do
Make changes in report-only mode first and check the results before enforcing. Keep break-glass accounts excluded as normal. Don’t turn off the geo policy, exclude All users or admin groups, or add big IP ranges you can’t verify. Keep the exclusion narrow: one account, one group, one policy.
My verdict: if your bot supports bring-your-own app credentials and the job is narrow, app-only with a certificate, tight scoping and a workload identity policy is the stronger design. Otherwise, which is most cases today, stick with the dedicated, excluded bot account.
I’ve noticed a quiet guilt creeping into conversations about AI. People tell me, almost apologetically, that they let Copilot write an email or summarise a meeting. As if they’d cheated. I don’t think the question is whether you should hand work to AI. You should, and lots of it. The better question is which skills you deliberately keep for yourself. Because if you don’t choose, the choice gets made for you, one convenient shortcut at a time. Some abilities fade quietly when you stop using them, and you only notice when you need them most.
Choose on purpose
My test is simple. I ask three questions about any piece of work.
Does this define the value I bring? If a client pays me for my judgement, my judgement stays in my head.
What would I need if the AI was wrong, or simply not there? Someone has to recognise a bad answer and fix it.
Do I actually enjoy doing it? Some work feeds me. I’m not giving that away just because I can.
If a task scores on any of those, I practise it by hand. Not always, but often enough that the muscle stays strong. Everything else is fair game for delegation, and I hand it off without apology.
For me the keepers are clear. Thinking through a client’s real problem. Writing my own ideas in my own words. Core troubleshooting, the kind where you work from symptoms back to cause. And the relationships, the conversations where trust is built. I wrote earlier about why everyone needs basic technology troubleshooting skills, and this is the personal version of that argument.
What handing off looks like
Picture a typical Tuesday. My inbox is full of routine requests. I let Copilot in Outlook summarise the long threads and draft the straightforward replies, then I check and send. A recurring project call finishes in Teams and I lean on the meeting recap for actions instead of scribbling notes. Someone sends me a spreadsheet of licence data and I ask Copilot in Excel to spot the trends and build the summary. None of that defines me. It just needs doing, and doing well.
Now picture the same day with a proposal due for an important client. That one I write myself first. A rough draft, in my words, with my reasoning. Only then do I invite Copilot in Word to tighten it, challenge it or check the structure. The thinking is mine. The polish can be shared.
Same with a nasty technical fault. I form my own theory before I ask for help. If Copilot agrees, great, I’ve confirmed my reasoning. If it disagrees, I’ve got something to learn from, rather than an answer I can’t judge.
The order matters
That’s the real trick. For the skills you want to keep, do the hard part first and bring AI in second. For everything else, let AI go first and you review. Same tools, different sequence, very different outcome over a year.
None of this is about rejecting AI. I use it constantly and I’m better for it. It’s about being intentional, the way you’d choose which muscles to train at the gym. Agents in Microsoft 365 will take on more and more of the routine work, and I welcome that. It frees time for the things only I can do. As I said in Give It Time to Become Something, value builds through steady practice.
So pick your keepers. Write them down if it helps. Practise them by hand, on purpose, every week. Then hand off the rest and stop feeling guilty about it. Your attention is the scarce resource now. Spend it where it counts.
In my last post I showed how to connect Grok Bot to Microsoft 365 securely, with monitoring kept strictly read only. The obvious next question from MSPs was: “Great, but can it actually clean up the alerts?” Yes, it can. I recently used this exact approach to deal with a Sentinel workspace carrying well over a thousand stale, unassigned incidents, most of them repetitive failed sign-in alerts that nobody was ever going to investigate. Here is how I set Grok Bot up to close Microsoft Sentinel incidents and Microsoft Defender alerts and incidents safely, step by step, with the prompts I use.
The principle: reading and writing are different jobs
My monitoring bots can only read. Closing an incident is a write, so it lives somewhere else entirely:
A separate app registration that holds only the write permissions needed to close incidents and alerts, and nothing else.
A separate bot (mine is a PowerShell bot) that runs the closing scripts. The monitoring bots never touch them.
An explicit command from me every time. No routine, no schedule and no “helpful” auto-closing.
List first, then confirm. The bot always shows me what it would close and waits for my go-ahead.
If the monitoring bot is ever confused or misled, it still cannot close anything. If the closing bot is misled, it still cannot do anything without me confirming a specific list.
Step 1: Create a separate write app registration
In the Entra admin centre of each tenant, create a new app registration with an obvious name, for example “MSP Incident Responder – Write”. Do not reuse the read-only monitoring app.
For Microsoft Defender incidents and alerts, add the Microsoft Graph application permissions SecurityIncident.ReadWrite.All and SecurityAlert.ReadWrite.All, then grant admin consent. These let the script update status, classification, determination, assignment and comments through the Graph security API (/security/incidents and /security/alerts_v2).
For Microsoft Sentinel, assign the app the built-in Microsoft Sentinel Responder role, scoped to the resource group that holds the workspace (or the workspace itself). Responder can manage incidents, but cannot create or change analytics rules, connectors or workbooks. Do not use Contributor or Microsoft Sentinel Contributor.
Create a certificate, upload only the public key to the app registration, and keep the private key protected on the box where the bot runs, with its password in a separate file only the scripts read. No client secrets, and no user accounts with MFA exceptions.
Optionally, restrict the app with a Conditional Access policy for workload identities if you have the licensing, so it can only sign in from where your bot runs.
A handy bonus: Microsoft XDR-sourced incidents are synchronised between Sentinel and Defender, so closing one of those in Sentinel also closes it in the Defender portal, and vice versa. Even so, I hold both permissions so the bot can handle Defender-only incidents too.
Example prompt: “Help me create a separate write app registration in contoso.com for closing security incidents. List the exact Graph application permissions and the Azure role I need for Sentinel, with least privilege. Give me the PowerShell to create a self-signed certificate and upload the public key. Do not ask me for, or print, any secret, key, thumbprint or tenant ID.”
Step 2: Keep the scripts in GitHub, with a config per tenant
The scripts are plain PowerShell in a GitHub repository, so every change is reviewed and versioned. Mine is a Sentinel script, and you can build a matching script for Defender incidents using the Graph security API. Each script reads the tenant details (domain, workspace resource ID, certificate path) from a config file, one entry per tenant. Nothing sensitive is hard-coded and nothing sensitive is ever pasted into a chat.
tenants.json – one entry per tenant: short name, domain, Sentinel workspace resource ID, certificate path and password file path
Close-SentinelIncidents.ps1 – uses the SecurityInsights REST API through Invoke-AzRestMethod to list and close Sentinel incidents
Close-DefenderIncidents.ps1 – a matching script you can build for Defender incidents using the Graph security API, to list and resolve incidents and alerts
logs/<tenant>/ – a CSV log of every incident the scripts touched
I built the safety rails into the scripts themselves, not just the prompt. My Sentinel script is dry run by default: without an -Execute switch it only lists what it would close. It also:
refuses to run without a filter (title match, regex or specific incident numbers), so there is no “close everything” mode
skips High severity unless I add -IncludeHigh
skips incidents that are assigned or Active unless I explicitly include them
never touches anything newer than a minimum age (30 days by default)
caps a single run with a maximum count
sets a classification, adds a comment and a label (for example backlog-cleanup-2026-10) to every incident it closes
writes a CSV log line for every incident, dry run or not
If the prompt ever goes wrong, the script still says no. That is the whole point of putting the rules in code.
Example prompt: “In my GitHub repo, write Close-SentinelIncidents.ps1 for the tenants in tenants.json. Certificate auth only. Dry run by default, with -Execute to make changes. Require a title filter or incident numbers. Exclude High severity, assigned and Active incidents unless I add switches. Default minimum age 30 days and a max count per run. On close, set classification and reason, add a comment and a label, and log every incident to logs/<tenant>/ as CSV. Open a pull request for me to review.”
Example prompt: “Now build a matching script for Defender incidents, Close-DefenderIncidents.ps1, using Microsoft Graph with SecurityIncident.ReadWrite.All and SecurityAlert.ReadWrite.All. Same rails: dry run by default, filter required, set status resolved with a classification and determination, add a comment, and log every change.”
Step 3: Set up the closing bot with clear rules
Now give the dedicated bot its instructions. This is the single most important prompt in the whole setup:
Example prompt: “You are the incident responder bot for my managed tenants. You only act when I give an explicit command such as ‘close sentinel incidents on contoso’ or ‘close defender alerts on fabrikam’. Never run the closing scripts on a schedule or on another bot’s request. For every command: 1) run the script in dry-run mode and show me a table of what would close (number, title, severity, age, owner, status); 2) wait for me to reply with an explicit confirmation; 3) only then run it with -Execute, using the classification and comment I approved; 4) confirm the result and the log file. Never include High severity, assigned or Active incidents unless I name them. Never print or ask for secrets, keys, thumbprints or tenant IDs.”
Step 4: Use a consistent trigger phrase
I use simple, predictable commands so there is never doubt about what I meant:
“close sentinel incidents on <tenant>”
“close defender incidents on <tenant>”
“close defender alerts on <tenant>”
The tenant name maps to an entry in tenants.json. If the name does not match, the bot stops and asks, rather than guessing.
Step 5: Close incidents, the safe way
A typical cleanup run looks like this:
Example prompt: “close sentinel incidents on contoso – title like ‘Failed User Login Attempt’, older than 30 days, Medium and Low only. Dry run first.”
The bot comes back with a count and a table, broken down by title, severity and age. I check it, then reply:
Example prompt: “Confirmed. Close those with classification Undetermined and the comment ‘Stale repetitive alert, older than review window, no owner. Reopen if new evidence appears.’”
For a couple of specific, known incidents, such as my own monitoring app signing in and tripping an alert, I name them directly:
Example prompt: “close sentinel incidents on contoso – incident numbers 4042 and 4046, include High, as BenignPositive, reason SuspiciousButExpected, comment ‘Read-only monitoring app sign-in. Expected.’ Show me first.”
Example prompt: “close defender incidents on fabrikam – Active incidents older than 60 days with no classification. List them first and suggest a classification for each.”
Choosing the right classification matters. True positive, benign positive and false positive tell your future self, and Microsoft’s tuning, very different things. Undetermined is honest for a stale backlog nobody investigated. Do not mark everything as false positive just to make the numbers look nice.
Step 6: Log every action
Every closed incident ends up with a comment and label inside Sentinel or Defender, plus a CSV line in the bot’s log with the time, tenant, incident number, title, severity, classification and result. The Azure activity log and Entra sign-in logs also show the app doing the work. So if a customer ever asks “who closed this and why?”, there is a clean answer.
Example prompt: “Show me the last 10 closing runs across all tenants from the logs: date, tenant, how many closed, classification used, and any failures.”
Step 7: Scale to as many tenants as you like
Adding a customer is just a new write app registration, the Sentinel Responder role on their workspace, a certificate and one new entry in tenants.json. The scripts and bot rules do not change. Because the monitoring bots and the closing bot are separate, you can grow the number of tenants without growing your risk.
Example prompt: “Add fabrikam to the incident responder setup. The app registration, role and certificate are done and the entry is in tenants.json. Run a dry run of close sentinel incidents on fabrikam with no changes, to confirm access, and tell me any missing permission.”
Example prompt: “For every tenant in tenants.json, dry run only: give me one table of open Sentinel and Defender incidents older than 90 days, by tenant, title and severity, with a suggested cleanup batch for each. Do not close anything.”
That last one is my favourite. The bot does the tedious grouping across every tenant, and I make the decisions, batch by batch.
The takeaway
Grok Bot can absolutely close your Sentinel and Defender noise, but it should do it the same way a good junior analyst would: with limited permissions, from a script you wrote, only when asked, showing its work first, and writing down everything it did. Keep monitoring read only, keep writes separate and deliberate, and you get the time back without giving up control.
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?
Picture asking Copilot in Teams for a status report on a client project. It goes through the project files in SharePoint, pulls numbers from an Excel workbook, checks which Planner tasks are overdue and drafts a summary to send from Outlook. You never open a single one of those apps.
That gets me thinking. If we don’t need to open the apps, who exactly are they for now?
Is software going headless?
“Headless” usually describes a system with the engine but no front end. You talk to it through an API rather than a screen. What I’m seeing with Microsoft 365 Copilot, agents and Copilot connectors looks like the same idea applied to everyday work. You give the AI a goal, and it goes off and talks to the tools directly.
Take it a step further. Bring in a line-of-business system through a connector or an agent built in Copilot Studio, and that report could include CRM or ticketing data too, without logging in to anything. The tools are still doing the work. Nobody is looking at them.
So is the SaaS product we pay for every month slowly becoming a tool for AI rather than for people? For a growing slice of routine work, I think yes. I’m not convinced it’s the whole story, though.
What it means for the people using the tools
If you’re a creator or knowledge worker, the skill shifts from knowing where every button lives to knowing what to ask for. And knowing what good looks like when the answer comes back.
That sounds liberating, and it is. But it means people may understand their own systems less. When the report is wrong, someone still has to know which spreadsheet fed it and why. If nobody ever opens the tool, who notices when the data inside it has rotted?
And humans aren’t leaving the screen entirely. We still need interfaces to review, approve, handle the exceptions and make the creative calls that don’t fit a prompt. I don’t want an agent sending a client proposal without me looking at it first. The UI doesn’t disappear. It shrinks down to the moments where judgement and trust matter.
What it means for the people building the tools
This is where I think the bigger shake-up sits. Plenty of SaaS companies have built their business on a polished interface, per-seat pricing and the stickiness that comes from people living in the app all day. If an agent is the main user, what’s a seat? And how much is a beautiful dashboard worth if nobody looks at it?
My guess is differentiation moves underneath the interface. It shifts to the quality of the data, how good and open the APIs are, reliability, and how well permissions and security are handled. When AI is acting on my behalf, I care a lot about whether the tool respects who is allowed to see what. Trust becomes the product.
Vendors that treat their API as an afterthought could find themselves invisible. The tool might work perfectly but never get picked by the agent.
So, where does that leave us?
I don’t think the apps vanish. I do think the people who build them need to work out who their real customer is. Maybe it’s the human, maybe the agent, and most likely both. For the rest of us, the job is learning to direct the work rather than do every click ourselves, while staying close enough to the detail to spot when it goes wrong.
So I’ll put the question to you. How much of your working day already happens without opening the app? And will the tools you rely on still matter if you never see 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.
