This piece keeps to Bastick's framework and tests the Microsoft side of it against Microsoft's own documentation. The comparison with ChatGPT, Claude and Gemini is his and is attributed to him. I haven't independently verified those vendors' plan limits or governance terms.
The three-question test
Bastick says the assistant is no longer a separate browser tab. It is embedded in documents, meetings and workflow systems, and that changes the risk. He asks:
- Where does it sit? Inside the documents, inbox, meetings and spreadsheets people already use, or somewhere separate that someone has to remember to open?
- What can it reach? Which systems and files, and whose permissions decide?
- How far does it run? Does it draft and wait, or take a goal, complete several steps and return with finished work?
His distinction is blunt. A tool that drafts a paragraph may embarrass you. A tool that can email a client, update a spreadsheet or trigger a workflow can compound a mistake at scale.
How he sizes up the four assistants
These are Bastick's characterisations. They aren't test results.
| Assistant | His positioning | His main governance caution |
|---|---|---|
| ChatGPT | Flexible general workbench with growing connectors | Define what data may be uploaded, which connectors are approved, and who may create shared agents |
| Claude | Long documents and polished deliverables, including Word tracked changes where supported | Decide which files it may access and which outputs it may edit directly |
| Gemini | Best where Google Workspace is home | Keep consumer and business features separate; avoid a personal subscription becoming a shadow system |
| Microsoft Copilot | Best where Microsoft 365 is the work operating system | It inherits the quality of your permissions, labels and file hygiene |
He also argues that the suite and the assistant are becoming separate choices. His examples are Claude's Microsoft 365 integrations, ChatGPT's business connectors, and model choice in Microsoft 365 Copilot Researcher. He adds that the Model Context Protocol lowers switching costs, so today's pick shouldn't be treated as permanent.
What Microsoft's documentation says about Copilot's permission boundary
Bastick's central Copilot claim is that it shouldn't surface anything a user couldn't already access. Microsoft's documentation supports that, and it also shows the limits of the claim.
- Microsoft Learn says Copilot only surfaces organizational data that a user has at least view permission to access. Microsoft tells admins to use Microsoft 365 permission models such as SharePoint's to make sure the right people have the right access. That includes access granted to outsiders through shared channels in Teams.
- Microsoft says prompts, responses and data accessed through Microsoft Graph aren't used to train the foundation LLMs behind Copilot. Stored interaction data includes the prompt, the response and citations, and it is encrypted at rest. Admins can use Content Search or Microsoft Purview to view it and set retention policies.
- Microsoft also says Copilot output isn't guaranteed to be 100% factual, and users should review it before sharing. That is the same point Bastick makes about review.
Bastick's "enterprise data protection by default" line is best read within those boundaries. Microsoft says third-party agents carry their own privacy statements and terms. Admins can see an agent's permissions and data access, and its terms and privacy statement, in the Integrated apps section of the Microsoft 365 admin center. Microsoft describes Work IQ as having built-in, permission-aware governance.
Why "clean the cupboard" is more than a quip
Bastick's line about cleaning the cupboard before installing a spotlight has independent support. Microsoft's own internal-adoption write-up describes a case where a sensitive document was reachable through a Copilot query. The root cause was a missing sensitivity label, not Work IQ, which honored what governance allowed. The same write-up notes the trade-off. Access through Work IQ means an agent can reason across everything the employee can access. That simplifies enablement, but it demands more confidence in your governance foundations.
For a finance team the practical implication is direct. Payroll files, draft board papers and M&A workbooks that were shared too widely years ago are now one natural-language question away.
Work IQ: what it is and how it is switched
Bastick lists Work IQ as organisational context. Microsoft Support adds detail he doesn't give:
- Work IQ is described as the intelligence layer that helps Copilot and agents understand your work. It draws on emails, files, chats, meetings, people, projects and connected business apps.
- Microsoft Support says it is available to users with a Microsoft Copilot add-on license. With that license it is on by default.
- Users switch it with the Work IQ button at the top left of the Chat screen in the Microsoft Copilot app.
- Work IQ on: Copilot can reference your Microsoft 365 work data alongside attached content and web information.
- Work IQ off: Copilot doesn't reference your work data. It still uses attached content, public web information, and your profile and personalization preferences.
Microsoft's developer documentation also describes Work IQ as available to custom agents. It says usage is independent of Microsoft 365 Copilot licensing and available through usage-based billing. That matters for budgeting. If a finance team's custom agents call Work IQ, the cost model may differ from the per-seat Copilot add-on. Check your own tenant's terms before committing.
Agent Builder or Copilot Studio?
Bastick says teams need to decide early how agents are approved and supervised before colleagues start building their own. Microsoft's guidance gives a practical split.
- Agent Builder: suits an individual or small team using natural language and existing content. It is managed mainly through the Microsoft 365 admin center. Microsoft says agents built there respect existing Microsoft 365 permissions and surface no content the user can't already see.
- Copilot Studio: suits a department, an organization or external audiences. It also suits multistep workflows, approvals, branching logic, custom integrations and finer deployment control. It includes lifecycle tools such as versioning and dev, test and production environments. It is managed through the Power Platform admin center.
- Moving between them: an Agent Builder agent can later be copied to Copilot Studio, preserving its core configuration and instructions.
- Licensing: both are included with a Microsoft 365 Copilot add-on license for authenticated users. Without that license, Copilot Credits or pay-as-you-go can be used. Agent Builder is free for agents grounded on web knowledge only.
A sensible finance pattern follows from this. An analyst can prototype a variance-commentary helper in Agent Builder. If it needs live ERP data or approvals, it graduates to Copilot Studio, where IT has real controls.
"How far does it run?" Admin visibility and its limits
Bastick says Copilot's delegated work features include checkpoints before actions such as sending emails. Microsoft's Agent 365 documentation shows the oversight side for Copilot Studio agents, and it is more nuanced than "every action is approved."
- Copilot Studio agents appear in an agent registry. Admins can see the agent name, description, publisher, connectors used and environment details.
- They automatically send telemetry on agent invocations and tool invocations, meaning connector usage. The data surfaces in the Microsoft 365 admin center, in Defender for security alerts, and in Purview for audit logs and DLP tracking.
- Admins can block an agent, reassign its owner, or delete it. Deleting an agent built within Copilot Studio requires a Power Platform environment admin.
- Agents are pre-approved through Power Platform admin center policies such as DLP and advanced connector policies. Additional approval applies to adding an agent to the tenant-wide catalog for Teams or Microsoft Copilot.
- Microsoft says this design allows company-wide agent development without per-agent admin approval.
That last point deserves attention. Policy sets the guardrails, and individual agents then roll out within them. If your DLP and connector policies are loose, the approval step does little. Don't read it as a human reviewing each agent action.
What can it reach? Two connector types, two risk profiles
Bastick's "what can it reach?" question maps onto a distinction in Microsoft's Copilot Studio documentation.
| Copilot connectors | Power Platform connectors | |
|---|---|---|
| Behaviour | Index external content into Microsoft Graph for search and grounding | Call APIs at runtime to read, write and trigger actions |
| Data movement | Yes, content is copied and indexed (source access controls are honored) | No replication for real-time knowledge, which is in preview |
| Best for | Documents, wikis, knowledge bases | Live facts and transactions such as creating or updating records |
| Control point | Microsoft 365 admin center | Power Platform data policies (DLP) |
Microsoft says many enterprises will mix them. Evergreen content such as policies goes through indexing, while workflows and transactions go through live connectors. For finance, a policy library suits the first. Anything that posts a journal or updates an order falls under the second, so it is where your approval design matters most.
A pilot plan that follows Bastick's advice
Bastick's suggested test is deliberately unglamorous. This is his proposal, not a reported experiment, and no results are claimed. Take last month's management accounts and ask the tool to:
- Identify the five largest budget variances.
- Draft commentary for each.
- List the evidence it relied on.
Then compare the output with the finance team's final pack. Check where it saved time, where it invented causality, and where it missed context buried in an email thread.
For a Microsoft 365 shop, add steps drawn from the documentation above:
- Audit access first. Review SharePoint and OneDrive permissions and sensitivity labels on the finance sites the pilot will touch.
- Decide on indexing or live access. That choice determines whether you need Copilot connectors or Power Platform connectors.
- Pick the build path. Use Agent Builder for a personal helper and Copilot Studio for anything departmental or action-taking.
- Set approvals. Decide which actions need a human, and write it down.
- Decide retention. Settle how prompts and outputs are kept, using Purview retention.
- Name an owner. Bastick's uncomfortable question is who is responsible when the tool is wrong, and it needs a named person as the answer.
Where the argument is thin
- It is a framework, not a benchmark. Bastick offers no measured performance data across tools. His vendor comparisons are editorial judgements.
- The author is Microsoft-adjacent. He is an Excel MVP appointed by Microsoft, which he discloses. His conclusion that no tool is inherently better is balanced, but readers should weigh that background.
- Availability varies. Much of the capability list is hedged with "where enabled" and "in eligible plans." Microsoft Support says the same: availability varies by license, subscription and admin settings, and IT can turn off some capabilities such as web content.
- Stack lock-in is partly real. MCP and cross-suite integrations lower switching costs. Permission-aware context is hard to replicate outside the suite that owns your permissions.
The bottom line
Bastick's practical message holds up against Microsoft's documentation. Copilot's value and its risk both come from the Microsoft 365 environment it sits in. It can't see what a user can't see, but it also can't fix permissions that were wrong already. Agents that act need decisions on connectors, deployment scope, monitoring and approvals. Start with one boring finance workflow, check the permissions, test against a human-produced result, and expand only when you understand where the tool fails.