Is Copilot safe for confidential client information?

This is the question professional firms ask me most, and it usually arrives in a shape that can't be answered. Safe for what? On which plan, with which files, measured against which obligation? Narrow the question and the answer gets useful in a hurry: for a lot of everyday work Copilot is a reasonable choice, and there is a short list of work where it isn't. This is general information rather than legal advice, so treat the specifics of your own obligations as a conversation for your lawyer or professional body.

Which Copilot, on which account

Copilot is a brand stretched across several products. There is a free consumer chat you reach with a personal Microsoft account. There is Copilot Chat, which Microsoft folded into the base Microsoft 365 commercial plans from 1 July 2026. There is the paid Microsoft 365 Copilot add-on, still sold separately at about A$31 per user a month on an annual plan, which is the one that reaches into your mail, your files and your meetings. GitHub Copilot and Security Copilot are different products again.

The protections you care about attach to the licence and the account signed in, not to the name on the button. That distinction does a lot of work. A staff member who opens the free consumer version in the same browser, with a personal account and the same familiar icon, is using something governed by other terms. A careful policy gets bypassed that way without anyone intending it.

The paid work-account product is sold with commercial data protection. The pitch, in short form, is that what your staff type stays within your tenant and isn't used to improve the underlying models. Take that seriously, and then go and read the version attached to your own licence rather than anyone's summary of it, this article included. Vendor terms are dated documents. They get revised, and the revision that matters is the one in force for your tenant on the day you rely on it.

Being fair to Microsoft here matters, because the enterprise tiers across this whole industry genuinely are where the contractual commitments live. Two well-documented examples from other vendors are covered in our guide on what AI data settings actually do, and in both of them the business tiers were carved out of the change while the consumer plans were not.

Residency is not sovereignty

These two words get used as though they mean the same thing, and a lot of procurement questionnaires accept one as an answer to the other. Residency tells you where the file physically sits. Sovereignty tells you whose courts can compel it to be produced. Choosing an Australian region settles the first question and leaves the second one open.

The Australia-United States CLOUD Act Agreement took effect on 31 January 2026. It formalises how the two governments make requests of each other, which is a genuine improvement on the ad hoc arrangements before it. Be precise about what it doesn't do: it doesn't put a private Australian business beyond the reach of US legal process where the provider itself sits under US jurisdiction. Jurisdiction attaches to the company, not to the hard drive.

If that sounds abstract, there is a concrete case. In May 2025 a US court ordered OpenAI to preserve output log data that would otherwise have been deleted, overriding user deletion requests, in a copyright dispute no Australian small business had any part in. The order ran for months before it was lifted. Nobody was dishonest in that story. The vendor complied with a court, and the customers found out that their delete button was a request rather than a guarantee.

For general office work you can look at that exposure and reasonably decide to live with it. For legally privileged material, or client information you're obliged to keep from third parties without permission, it stops being background risk and becomes the actual question.

EchoLeak, and why a trustworthy vendor isn't the whole question

In June 2025 a vulnerability in Microsoft 365 Copilot Chat was disclosed and assigned CVE-2025-32711, nicknamed EchoLeak. It was a zero-click prompt injection: the attack used the Microsoft Graph connector to leak SharePoint content without the user clicking anything at all.

The mechanism is worth understanding, because it isn't a Microsoft problem so much as a category problem. An assistant that reads your documents and email on your behalf will also read any instructions hidden inside them. Indirect prompt injection is the term for it. A single poisoned PDF sitting in a document library is the attack. Supplier invoices, inbound email, tender documents and anything else arriving from outside your organisation are all candidate carriers.

So "do you trust Microsoft" is a fair question and an incomplete one. The other half is "what happens when something the assistant reads is hostile". That specific bug was reported and closed, which is the system working as intended. The class of problem it belongs to is not closed, and it's the reason a serious deployment treats externally sourced content as untrusted input rather than as instructions, scopes what the assistant can reach, and doesn't let a document tell the assistant what to do.

Copilot inherits your permissions, including the forgotten ones

Copilot surfaces what the signed-in person can already open. That reads like a safeguard, and it is one, right up to the moment you look honestly at what your people can already open.

Most SharePoint estates of any age have accumulated over-sharing: links set to "anyone in the organisation" for one urgent afternoon in 2021, a site opened up for a project that ended, a folder that inherited permissions nobody has reviewed since. That latent exposure was mostly harmless while nobody went looking, because search is a poor discovery tool. An assistant that will happily answer "what did we agree to pay the Melbourne supplier, and who signed off on it" is an excellent one.

The documented failure pattern in systems like this is permissions enforced at the interface while the retrieval layer knows nothing about them. The rule that prevents it is unglamorous: filter before retrieval, never after generation. Once content the user shouldn't see has entered the prompt, redacting the answer isn't access control, it's tidying up after a breach.

An honest planning note, since it affects budgets. On private document assistant builds, permissions is routinely the longest and riskiest phase, well ahead of the infrastructure. If someone has quoted you a fortnight for a company-wide knowledge assistant, permissions is the part they haven't scoped.

So where is Copilot fine, and where isn't it

Fine, in my view, for the bulk of general office work: drafting internal documents, summarising your own meetings, tidying up writing, wrestling with spreadsheets, producing first versions of things a human then reads properly. That covers most of what most staff do most days, and the productivity is real.

Here is the work I'd want a written decision about before it goes anywhere near a general cloud assistant:

• Legally privileged material. Privilege is easier to lose than to defend, and the argument you'd have to run is not one you want to be having.
• Client information you need permission to disclose to a third party. Tax practitioners have a specific and recently clarified obligation here, covered in our guide on AI and client confidentiality for accountants.
• Health records and other sensitive information. The OAIC recommends against entering personal information, and especially sensitive information, into publicly available generative AI tools.
• Anything covered by a contract clause restricting AI processing. These clauses are turning up in supplier agreements because standard confidentiality wording may not cover AI processing. Read your MSAs before assuming you're clear.
• Automated decisions about people. From 10 December 2026 there is a new privacy policy disclosure obligation attached to these. Our guide on what actually starts in December sets out the detail, including a widely repeated claim about the small business exemption that isn't right.

Where the honest answer is that no general cloud assistant fits the work, the alternative is running the model on hardware you control. That isn't a fringe view: the OAIC's own guidance on commercially available AI products says deploying AI systems locally is "likely to be more privacy-preserving as it limits the risks of third party access to the data". That's the regulator describing the architecture, not a vendor selling it. How that looks in practice is set out on our local and private AI page.

What I wouldn't do is tell a firm to abandon the Microsoft stack. Nobody does that, and advice nobody acts on is worthless. The workable shape for most firms is general work on Copilot with the permissions cleaned up, plus a narrow private setup for the slice of work that genuinely can't leave the building.